Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
A short time ago I was working with an agile coach. He was quite experienced and well known in the agile community. He also held a wide variety of certifications.
We were working together on a project that had, if I were to be honest, quite a few cultural and organizational challenges.
There was one specific individual who always seemed to be the most challenging. My coaching colleague and I were talking about them one day and he was grousing (complaining) about them to me.
In several previous posts,
I’ve explored agile metrics as a set of 4 KPI areas that are typically monitored in agile instances. In this particular post, I want to drill into team health or “happiness” as a viable and important agile metric area. In fact, I might argue that it’s your core metric.
Let’s look at a couple of approaches.
I’ve occasionally shared blog posts related to questions from my good friend Lee Copeland. Lee will occasionally send me an email asking a question related to an article or talk idea that he has. In this case, he asked me about – “bad things that Scrum typically exposes”?
He sent me this list to illustrate the sorts of things he was looking for:
I thought about it for a couple of days, as I didn’t necessarily resonate with his short list. In fact, my initial reply to Lee was that – Scrum exposes EVERYTHING; so making a list could be a long effort. But upon reflection, I’ve created a “Top 10” Baker’s Dozen of things (challenges, dysfunctions, problems, etc.) that I typically see when organizations transform to Scrum.
It’s not intended to be exhaustive, but I hope you find it thought provoking…
I remember it was approximately 2008-2009 when I read a blog post, then article/paper about this idea. At the time Jeff Sutherland mentioned it, but the leading voice behind the idea was Scott Downey who worked at MySpace at the time.
Part of the reason I was intrigued was that agile coaches were really struggling to find their hand or balance when it came to “spinning up” Scrum teams at this time. Quite often the approaches were really soft and non-prescriptive. The coaches often hinted at a combination of practices, perhaps giving the team a link to a basic reference (the Scrum Guide), and then the teams were left to fend for themselves.
Often the results were horrible. The teams picked the practices they were comfortable with and left behind the rest. Often they picked such a trivial combination, that the results were hardly agile and hardly effective. This was also the time when Ken Schwaber coined the term Scrum Butt and the Nokia Test was being used as a litmus test to see if you were really doing Scrum or not.
Of course it’s going to happen. No matter how good an agile team is, eventually they’ll have a tough sprint and something bad will happen. They’ll miss the work they committed to in the sprint and some of it will need to carryover to the next sprint.
Mike Cohn had this to say about demonstrating that work in the current sprint in his December 10, 2015 newsletter:
A standard rule in sprint reviews is that the team should show only work that has been completed. This rule prevents a team from feeling that they've made more progress than they really have. Additionally, it avoids any risk that attendees leave a review confused about what has really been completed.
And so, teams are told they cannot show slides or partially finished work.
This is a great rule. But, just like my daughter tells me about her curfew, some rules are meant to be broken.
And so I sometimes break the rule about only showing finished work. A sprint review often brings together important stakeholders who are rarely together otherwise. That is a wonderful opportunity to ask them collectively, "What do you think of this screen [or other work] that is in process?"
It would be a shame to forego this opportunity just because of a Scrum rule.
Mike echoed my own advice for teams. But I usually adopt a harsher, no review posture, and Mike’s newsletter forced me to reconsider that advice.
I want to explore several aspects of sprint work that weren’t all covered in his newsletter.
I used to think that there were basically three forms of agile transformation. They were and are:
and I used to say the most effective strategy for a true transformation is…all three!
I still basically coach that as an effective strategy. But as time has passed, and I’ve gained more and more experience, I realize that there is a fourth option that intersects all of these.
It’s:
And it doesn’t apply to the organization at all. It applies to the individuals within the organization. Let me explain.
I once worked as a coach at a large financial firm that had been “going Agile” for quite awhile. They were one of the worlds largest firms, so the teams and the projects were often distributed.
They had invested in a relationship with a Ukrainian firm to outsource a significant part of their software. This had been going on for a while, so there was integration between internal and outsourced agile team members.
I was pulled in to help the outsourced teams with their understanding of agile practices. You see, even though they “said” they were agile, their behaviors were really suspect and more indicated cowboy and self-centered development.
I just watched a video by Mishkin Berteig where he clarified that the concept of a Sprint #0 is NOT part of Scrum.
A few weeks ago, a colleague of mine tweeted about the concept of Hardening Sprints. If you’re aware, the Scaled Agile Framework has “dabbled” with hardening sprints and other “extensions” to Scrum. Ron Jeffrey’s strongly, clearly, and repeatedly responded that hardening sprints are NOT part of Scrum. It became physically painful as Ron pounded his point over and over again in tweets.
I’m an insider (a CEC) to the Scrum Alliance CST & CEC discussion group. Some of the most heated discussions I’ve ever seen there revolved around the definition of Core Scrum in the Agile Atlas. This was before the Scrum Alliance centered on the Scrum Guide as the clear definition of Scrum.
I was watching an NHL game the other evening. The team was playing a hockey game without a goalie.
Apparently the team had decided that their goalie was too expensive. So they traded him away to another team.
Then the backup goalie was sick. And his equipment didn’t fit anyone on the team, so they decided to “go without”.
In a pre-game interview with the General Manager, he said that it was strictly a financial decision. They felt that the team could fill in the goalie role by sharing it amongst themselves.
If it worked out as he expected, then they might consider this change as a permanent part of their hockey team structure.
At the very end of the interview, he wondered –
What does a Goalie do anyway? For 90% of the game they’re idle. What a waste of money. Why not get the team to “pitch in” and fill that role? It just makes good sense…
A month or so ago I was invited to do a podcast with my good friend Cory Bryan. The podcast is Deliver It and I highly recommend listening into what Cory has to say. Cory said something during the podcast that has been running around my brain ever since. He said:
I sort of like it when leadership can’t make decisions. I’ll tell them if you can’t decide, then I’ll decide for you.
The implication was that he would drive all decision-making as the Product Owner – even decisions that senior leadership should be making. He was quite firm in his tone, seeming confident of his ability to step in and drive.
