A couple of weeks ago I was sorting through some books left to me by an uncle in the early '90s when I came across a copy of The U.S. Armed Forces Survival Manual, published in 1980. Leafing through I found all sorts of advice such as how to build a shelter, find direction, trap and prepare food, and how to protect yourself from natural hazards. It was this last topic that caught my attention, particularly the section about poisonous snakes of the world. Who knew there were so many ways to die?...Read More
Notes from the field...
When I tell someone I am an agile coach, I sometimes receive a puzzled response.
"Oh? What sport?"... or
"Is that the thing where you train a dog to run an obstacle course?"
When I explain that I coach people and teams that create innovative products and services, they get even more confused.
"Why do they need a coach? Aren't they professionals? Don't they know their stuff? Shouldn't we reasonably expect that they can get the job done?"...Read More
In 1993, the first Scrum team introduced a new role — the ScrumMaster. This person was explicitly “not a manager — more of a servant-leader, something between a team captain and a coach.”¹ Instead of managing the team or the team’s process, the ScrumMaster:
- Facilitates the team’s meetings, fostering collaboration and enabling focus.
- Ensures that the process and its effects are visible to everyone.
- Helps the team figure out what is in their way of being an better, more effective team at delivering what their customers actually need.
- Champions improvements that the team is unable to make for themselves, influencing those with the power to enact change.
Fundamentally, the ScrumMaster role is about developing people... and the teams they form, helping both individuals and teams realize their potential. A good ScrumMaster accelerates the rate of improvement while enriching the experience for all involved.
¹Jeff Sutherland, Scrum, (New York, NY: Crown Business, 2014) p. 62
Where you want to get to matters, unless, like Alice, you are on an adventure and you are just trying to get back to where you started. In my work with organizations, the general intent is to get to somewhere different, somewhere better. As an Agile coach with 20+ years helping others develop proficiency in Agile, I've found effective "where you want to get to" strategies tend to fall into one of 4 contexts -- team, skills, customer, or flow.
These contexts establish frames for selecting specific agile practices and choosing goals for measuring progress towards proficiency in those practices. For example, the "skills" frame might lead to the use of practices such as coding standards, paired programming, and continuous integration. A reduction in production defects would indicate an increase in skills proficiency.
Of course, Agile practices are not restricted to just one frame. Paired programming would be an equally valid practice in the "team" frame. The frames might be viewed in a venn diagram with some practices such as retrospectives living in all 4 frames. Likewise, a measure of progress, like team satisfaction, could span more than one frame.
The main benefit of frames is focus. You don't need to, nor should you try to, do all Agile practices at once, right out of the gate. Just like incremental product development, you should adopt agile practices incrementally, respecting your organization's capacity to absorb change in process and practice, and keeping an eye on your goal -- where you want to get to.
It's been said that Scrum is "what we already do when our back is against the wall." That should make it easy, but reality is that it can be hard to admit that we're in a tough spot. Absent a "fight or flight" stimulus, it can be hard to get traction, and without traction, success may be just a mirage. A first step in getting started with Scrum successfully is the existence of a problem. The problem provides the fuel or energy that will sustain us when the going gets hard.
In addition to the problem, there needs to be someone who authentically owns the problem. Feeling responsible for solving the problem is not enough. The problem needs an authentic owner who cares about solving the problem.
When I'm brought in to coach a team in the use of Scrum, I start by asking 2 questions:
- What is the problem you are trying to solve?
- Who owns the problem?
The picture to the left shows a progressive model to discover answers to these questions. Starting at the bottom is the problem. Next, there's the admitting that the problem exists. This step is non-trivial. Too often, I find teams adopting Scrum as a solution in search of a problem. Have no doubt, Scrum will surface problems; but we want to start with the main problem we're trying to solve.
After admitting that there is a problem, further discussion and analysis may be required to identify the "real" problem. Often, the expressed problem is just a symptom, or worse, a solution dressed up as a problem. Some root cause analysis such as the five whys technique developed by Sakichi Toyoda can be helpful in uncovering the real problem.
Once the problem has been identified, the client decides if the problem is worth solving. There is always a cost with solving a problem. We want to make sure the benefit of solving the problem will outweigh its cost and that it is the right and timely thing to do.
Next, does the scope of the problem fall within the client's sphere of control or influence. Is the client empowered to solve the problem?
Finally, the key question: Do you think we can solve the problem? If we've progressed up this model and the answer to the last question is yes, then we proceed. Along the way, we have built up trust and understanding, both of which will serve us well on the journey ahead. Knowing the problem we are trying to solve and that we have the problem owner onboard are the first steps to success.