Shu Ha Ri

I attended an interesting session at Agile 2011 this year, about applying Shu Ha Ri at the leadership level.  The talk was given by Bob Galen and talked about how it can be useful to take a look at an organization’s leaders, assess where they are in terms of Agile maturity, and consider this information when looking at implementing agile processes, or later to see how parts of the organization are performing.

Shu Ha Ri is a martial arts concepts, used to describe the stages of learning to mastery.  It translates roughly to ‘Learn, Detatch, Transcend’.  Basically, when practicing to mastery, you first learn techniques (or kata in martial arts) by the book, until you have that down. Then you are able to break from tradition, introducing your own alterations to the traditional techniques, in a way that still works.  Finally, once you have mastered that level, you are able to completely transcend, perhaps breaking new ground, able to teach others to mastery.

Applying this to Agile, Shu Ha Ri can be used to describe how teams learn to use agile processes, and how coaches master the ability to teach others to use agile.  First, we teach teams by the book.   Once they master that level, they can introduce alternatives to their process, in ways that still work, because at the level of mastery they have obtained in ‘Shu’, they understand the underlying principles and ‘why’ we do what we do.  When they have obtained the ability to think about what is truly working for them and what isn’t, and making tweaks to their process in a way that still embodies agile values, they have moved on to ‘Ha’.

Finally, once a person or team has mastered ‘Ha’, and becomes expert enough to consciously use the agile values framework in decision making, and perhaps has the ability to coach and teach others, they will have moved into ‘Ri’.

Bob Galen’s talk suggested that it could be valuable to see where your organization’s leaders are on the Shu Ha Ri spectrum, since it can be useful to have at least one ‘Ri’ in every group.   With my current company, the Product Development organization functions basically as one unit, under the direction of one Director of Engineering and one VP, and we have several people at the high ‘Ha’ and ‘Ri’ levels.  But in my last company, which had several major development groups each led by a different VP, with several Directors under each, I think it would have been useful to ensure we had one ‘Ri’ in each VP’s group to mentor the group in agile practices.

For those who are interested, here is a link to Bob’s presentation from the conference: SHU-HA-RI Applied to Agile Leadership.

I myself consider my own level to be somewhere between ‘Ha’ and ‘Ri’. I am able to modify the process to suit the situation while still adhering to agile principles and not ignoring the tough bits.  I am also able to teach others.  But I feel I still have a journey in front of me of teaching others and deepening my experience to the point where I feel comfortable calling myself a ‘Ri’.   It’s good to have a goal!

Do Scrum, Not Scrumbut

In my experience, there are two different types of Scrum implementations: full Scrum, and what Ken Schwaber and Jeff Sutherland and others have called ‘Scrumbut’. The former makes full use of the Scrum framework, and the latter is what you see when a team adopts only pieces of the framework, as in “We are using Scrum, BUT we don’t really don’t do sprint reviews or retrospectives.” Or, “We use Scrum but we do all of our testing in the next sprint.” If you are not using the whole Scrum Framework, you may be employing an Agile, iterative process, but you are not really doing Scrum. Scrum is at it’s most potent and effective when you actually use all the elements of the framework, which were designed to address the core Scrum pillars of transparency, inspection, and adaptation. Half-stepping on your Scrum implementation can throttle the value and return on investment teams and companies will get out of using Scrum in the mildest case, and actually be dangerous in the worst. The danger exists that done poorly, your development process will churn more and cost more, quality will suffer, and people will burn out. Additionally, the implementation will be at risk of failing to achieve the success people expect, and they may not recognize that Scrumbut is to blame but may instead conclude that Scrum doesn’t work – leading to potential failure of the implementation.

Scrum is lightweight, easy to learn, but difficult to do really well. Teams have to commit to practicing it to do it well, understand that continuous improvement is a journey that never ends, and work thoughtfully towards mastery.

So how can you tell if you are doing Scrum or Scrumbut?

First, you need to have a robust understanding of the elements of the Scrum framework and how they are used. In a nutshell, Scrum is made up of roles, events, artifacts, and the rules that bind them together. Your process should include all of these to be considered a solid Scrum implementation:

Roles

Product Owner – owns product backlog, provides direction on ‘what’ should be built, constantly considers value to the customer

ScrumMaster – owns the Scrum process, coaching the team how to make the most and best use of it

Development Team – owns ‘how’ to accomplish the sprint goals, cross-functional team enabled to self-organize on developing the product. Note that in Scrum, the term ‘Development Team’ includes every role whether coder, tester, technical writer, UX expert etc)

Events

Sprint – container which holds all other events, between 1 and 4 weeks long

Sprint Planning – timeboxed session with the entire Scrum Team during which backlog items are discussed and understood, and a plan for the sprint is created on how to deliver working increment of product. The team is given a sprint goal, which could be a milestone along the product roadmap, and decides how to accomplish that goal. This could involve breaking backlog items down into smaller chunks called tasks

Daily Standup – 15 minute timeboxed daily session during which the team plans the day, synchronizes their work, and updates each other; this preferably takes place in front of the team’s task board and in person. This meeting is for the team, not management, and answers the questions 1) What I did since last time 2) What I plan to do before next time 3) What’s in my way

Sprint Review – the team reviews what they completed vs what they forecast and demonstrates completed work for final acceptance by the product owner and for feedback from stakeholders

Sprint Retrospective – the team inspects themselves and how they worked together during the last sprint, creating an ordered list of what went well and what needs to be improved. Items to be improved are included in the next sprint planning or added to an improvement backlog.

Artifacts

Product Backlog – an ordered list of features or items to be worked on along the product vision and/or roadmap.

Sprint Backlog – the set of backlog items to be worked on during a sprint plus the plan on how to complete them.

Backlog Item – a single item to be worked on. Many teams use User Stories as their backlog items (borrowed from XP).

Definition of Done – this is a team defined list of everything that must be in place for a backlog item to be considered done. This might include code checked in to source control, functional and performance testing complete, documentation written or updated, acceptance criteria met, etc and will depend on what the team needs to deliver a potentially shippable increment.

Understanding all of these roles, events, and artifacts is important, and more details about the basics can be found in the Scrum Guide.  The other thing that can help you identify whether you have a real, robust Scrum implementation is to consider some examples and causes of the Scrumbut anti-patterns so that you can learn to recognize them on your team or within your organization. Scrum.org has a list of potential causes here. Additionally, here are some examples I have seen:

• no real Product Owner or ScrumMaster, or the roles are filled by the same person
• team doesn’t really do daily standups
• team doesn’t conduct a review or demonstrate working software to stakeholders at the end of the sprint
• team doesn’t retrospect on how the sprint went or how to improve their use of Scrum, the product, or how to work better as a team
• no real product backlog or understanding of the priority or business value to be delivered
• team (sometimes or always) does not deliver working software at the end of the sprint

So, are you doing Scrum, or Scrumbut?

Updates to the Scrum Guide

Ken Schwaber and Jeff Sutherland have posted an update to the Scrum Guide this year. Here is a link to the summary of the changes. In case you prefer, here is a summary of the changes:

1. The team doing the work is now called the ‘Development Team‘, and all members of the team are called Developers whether their expertise is in programming, testing, UX design, technical writing, etc. This is to emphasize that the team works together to ‘develop’ the software.
2. The team no longer ‘commits‘ to accomplishing the sprint goals, they ‘forecast‘ what they will complete and the expectation is that the plan will adapt as they learn more. The main reason for this is at times stakeholders have engaged in committment bashing, penalizing the team for breaking commitments even when the circumstances were beyond the team’s control. This is an acknowledgement that it’s nearly impossible to predict a 100% accurate plan until the team has enough information – which is usually when they are doing the actual work. We can, however, forecast accurately enough to make a plan with flexibility baked in.
3. Scrum doesn’t require use of a burndown chart specifically, only that the amount of work remaining in a sprint is summed and known daily, and trending towards completion is maintained throughout the sprint.
4. Release planning is valuable but isn’t required; it depends on your circumstances.
5. The Sprint Backlog is the Product Backlog items selected for the sprint plus the plan for delivering those. Here is a diagram from scrum.org which illustrates what is considered the sprint backlog:

6. The product backlog is now ‘ordered‘ instead of ‘prioritized‘; this is to emphasize that there are many factors that go into the order of the backlog including ROI but also logical order, dependencies, gaining knowledge, and other factors unique to the situation.

Edit: Here is a link to the Scrum Guide

The 90 Day Mark

Well, today marks my 3 month anniversary of my new job at kCura. It’s been great so far, and I thought I’d share my experiences getting integrated into my new role.

When I joined, kCura already had Scrum in place. We do three month releases (recently up from two) but we do two week sprints – so six of those per release. We currently have nine teams – eight using Scrum and one using Kanban. Our teams are co-located and cross-functional; we use physical task boards. We use index cards for user stories and color-coded sticky notes for tasks. We plan releases using points and sprints using capacity in hours (eventually we will use points). We have release and sprint planning, daily standups, sprint reviews and retrospectives. When I joined as an Agile Coach and ScrumMaster, the Scrum framework was already in place and being used robustly.

That has made integrating into this company really easy. I joined during the second sprint of the last release, so I shadowed the other Agile Coach (and my manager) Jeff Steinberg, who put all of this in place. I learned how he was interacting with the teams, what he provided for them, how he coached them, and how he saw the role. Then, at the end of the release, I was able to take over as ScrumMaster for three of the teams.

Once I was with the teams, I took over just as he had, following the same procedures and flow. With a new person on their teams, they didn’t need me to come in and make big changes. I just observed, followed the process, and helped. I was able to coach one team that was struggling to complete their stories, to be able to complete their work within the sprint (they just needed some guidance on being more realistic about their commitment). I spent the next whole release in this mode – still learning, getting to know people, learning more about how the release process works, the software, etc.

Now we are gearing up for the next release, and I feel very good about the next three months. I am ready to do more coaching – encouraging teams to think about the agile principles behind the practices, cultivating even more of a culture of continuous improvement, and encouraging them to become ever higher performing – releasing the highest value software with very high quality – each and every sprint. My goal is to post again about this at the end of each release. Cheers!

Golden Circle of Agile Transformation

Today at Agile 2011 I attended a session with Jean Tabaka, an Agile Fellow at Rally, entitled ‘The Golden Circles of Agile Transformation’. I really enjoyed this session. In it, Jean challenged us to think beyond the individual practices we are doing with our teams – standups and sprint reviews in Scrum, pair programming and continuous integration with XP, etc. She led us through determining what our ‘book of guidelines’ is: what are the guiding principles that we use to tell whether the practices we are using are effective and when we need to add, modify, or remove any of them. The Golden Circle refers to concentric circles with ‘What’ (the practices), ‘How’ (how we know whether they are working and when to change them) and the ‘Why’ of using Agile.

I have been thinking a lot about this lately as well. I feel that it is so critical to really develop high performing teams and high performing organizations, to go beyond doing Agile practices by rote and to use them because they support principles and values that matter to us.

At first, I thought perhaps she was referring just to the 12 Agile Principles behind the Agile Manifesto. Instead, in addition to those she suggested considering guidelines from Lean as well:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

Also, from Systems Thinking, Design Thinking, Complexity Theory, Cynefin. This gave me a few new avenues to research and absorb. The point is, we want to continuously improve and adapt, and the guidelines offer areas for us to consider in making choices about what improvements will either help solve the problem at hand, or make us even more high performing and satisfied in our work.

During the last bit, Jean challenged us to answer the question of ‘Why’ we do Agile. As she said, the ‘Why’ should a BHAG – a Big Hairy Audacious Goal, or a Social Purpose, that kind of thing. Interestingly, it was very very difficult for most people to come up with a good answer to that question, and she gave us several minutes to reflect on it. I admit that I struggled with this question as well. I was reminded of a talk that Globant CTO Guibert Englebienne gave while I was at Orbitz, where he said that in his experience, technologists need to feel that what they are doing serves some purpose higher than making money (which is mostly for someone else anyway). I can relate to that. Interestingly, Rally’s higher purpose is to transform the software industry into a zero carbon footprint industry, starting with themselves. Go Rally.

3-2-1 Blastoff

What a packed day. Today was the first full day of the Agile 2011 conference. I attended sessions on how to use Non-violent communication which was very interesting. This session provided some basic tools to think about the basic needs that all humans have, and how to take a coaching problem and use the analysis of what we need as humans to understand it from different angles. It also taught us how to separate observation from (often negative) evaluation, and how to apply that back to people’s feelings. If you can understand that, you can often unlock potential means of more effective coaching. Lastly, we did some exercises to consider what our own needs are as coaches – that tends to get lost in the day-to-day work of servant leadership to our teams but it is important to know and ground ourselves in order to be effective coaches for them.

In the afternoon, I attended Christopher Avery’s session called “Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership” where he taught research on the Responsibility Process and how to practice it. That was pretty interesting from a psychological standpoint, but I feel like I need to read more about it to be able to really absorb it. Luckily, Christopher has more about this on his website at www.christopheravery.com.

Those two sessions took up the bulk of the day. At 5pm, they held a ‘Reunion’ session for the creation of the Agile Manifesto, which was basically a Q&A session to 15 of the 17 original authors. The session was humorous and pretty interesting as the authors basically recalled the meeting they had here in Salt Lake City 10 years ago where they drafted the manifesto.

Finally, the night ended with a reception – dinner, drinks and socializing. It’s been fun so far, I’m really looking forward to tomorrow and the rest of the week.

Acceptance Tests – The Writing’s on the Wall

I came across this photo on Tom Perry’s Agile Testing Blog.

The thing I like about it is the additional column for “Tests Spec’d” before progress on the tasks begins.

I think it would be cool to have a checkbox to mark that the acceptance tests had been written as an indicator that development can begin.

Agile 2011 Here I Come

I am ridiculously excited about the Agile 2011 conference in Salt Lake City next week. The last time I was able to attend was in Toronto in 2008. At that time, I was a newly converted amateur Agilista, having just earned my SCM the previous year, and doing some experimentation with my then-team, before the company I was working for had even given much thought to using an Agile framework like Scrum.

Now, things are a bit different. I’m working professionally as an ScrumMaster and Agile Coach, and feeling really excited to be able to use the next week to learn, contribute, and network among peers as a professional Agilista. Woohoo!!!

My plan is to post updates, notes and photos here on my blog, so stay tuned.

Physical Task Boards are the Bomb

In Scrum and other flavors of Agile, the task board represents the team’s plan for the sprint. Where I work, we have a rolling whiteboard for each team. They use one side for their task board, and one side for the release backlog and other artifacts. The board is an amazing information radiator. It contains the team’s stories, broken down into tasks. It has their written Definition of Done. It has their Sprint Burndown chart, showing the task hours remaining on each day of the sprint. It has a place to note unavoidable distractions, so that the team can make them transparent and management can detect patterns and potentially make changes to better insulate the team.

The ScrumMaster

Occasionally, I get asked what a ScrumMaster does.  Sometimes people wonder what else a ScrumMaster does beyond facilitating the daily standup and other Scrum meetings.  Actually, there is quite a lot that a ScrumMaster can do to help an Agile Team reach its full potential.  A ScrumMaster continually looks for ways to set the stage for teams to continually improve.