Agile Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

By-the-book Agile Is No Longer Agile

09.18.2013
| 4891 views |
  • submit to reddit

A friend of mine told me about an organization in trouble: It was too firmly attached to its processes to improve when needed. The strict process that was followed? Agile (Scrum to be specific).

I’m sorry if I just caused some of you to swallow your coffee down the wrong pipe, but it’s true: Using an agile process the wrong way can give exactly the same problems that the agile movement tried to extinguish.

The reason that this occurs is that most articles teaching agile practices (including my own) are very prescriptive. Do this! Don’t do that!

For beginners that’s great and that’s what they need, but for teams that have some experience it is time to bend the rules when needed. The best way to describe this that I’ve found is Shu Ha Ri. The term originates from Aikido, but is frequently used within the Agile community to describe the different phases of Agile adoption.

Shu – Beginner

Shu is the beginner level. For someone starting out on the Agile journey without experience, the first goal must be to get the Agile process running. To do that, a variety of practices are required. For Scrum (my favorite Agile methodology), this means running sprints through sprint planning, daily standups, review and retrospective with a backlog to keep track of the requirements. It means appointing a product owner, a Scrum master and a development team.

In the Scrum projects I have run that have been successful, all these parts have been present. When talking to other people who just can’t really get Scrum working, a deeper discussion often reveals that they are only following half of the practices. When learning a method the first time, I think that it’s important to go all in, to follow the method by the book to properly understand it.

In Scrum, each of the events, artifacts and rules makes sense on their own, but the true power of them is only realized when they are combined. For a beginner, it is important to go deep enough into the method to experience how the whole is greater than the sum of the parts.

That’s the Shu (beginner) level. That’s where many teams get stuck and that’s the level that most of the material available on Scrum and other Agile methods focuses on. Unfortunately, it’s much less obvious how to move on to the next – Ha – level.

Ha – Expert

The Shu level focuses on following the prescriptive rules, just to get started. On the Ha level it’s time for a deeper understanding of the rules. It is now time to look critically at the process and see if all of the parts make sense. Maybe the daily standups are not considered efficient, as the team has come to a state where they are talking continuously during the day. Then ditch the standups. They are not needed. Or maybe they are – the only way to know is to try. Ditch them for a sprint and follow up with the effects in the sprint retrospective.

The rule book is not meant to be followed. It is meant to be broken, but only once you’ve learned the value of each rule. The Ha phase is also the right one to start experimenting with alternative approaches. If you’re running Scrum – try some Kanban or XP for a change.

When coaching a team it is a very important balance to find the point where the team transitions from Shu to Ha. For a team at the Shu level, it is a warning sign if they are breaking the rules. For a team at the Ha level, it is a warning sign if they are not breaking any of the rules.

When a team says that they are breaking the rules, further discussion often makes it very clear if they are a struggling Shu, or an experienced Ha. Just listen to how they describe it. If they are abandoning something because it was hard, took too much time, or people ignored it (such as not showing up to a standup), they are Shu. They need help to enforce the rules. If they are abandoning something because they’ve found a better alternative, or because they found the practice redundant (they do the three Qs on the standup, but everyone already knew what everyone else would say) they are Aa and should be encouraged to experiment and find their own way.

Ri – Master

I’ve yet to experience the pleasure of working with a Ha team making the leap to mastery. I can only imagine what it would be like, but I suppose it would involve deep discussions and understanding of the process. The team would continuously inspect and adapt until their process is their own and no longer follows any rule book. By not only breaking the rules, but rather leaving them behind, going beyond the limitations of the rules, they would achieve mastery.

Stepping up from Shu

Without knowing the details of the organization my friend told me about, my guess is that they struggle with making the leap from Shu to Ha. Sticking to the rules is comfortable – human beings in general dislike change. It might be that they just need some rest after a stressful period of Agile adoption. It might be that they have stopped improving and grown comfortable.

In any case, I’d put my bet on one practice that they are not following, the one practice that is the most important once the basic rules of the Shu level are followed: the retrospectives. They are the key to moving on. They are the places for critical discussion of the process and finding out how to take the next step on the road to mastery.



Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)