DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. By-the-book Agile Is No Longer Agile

By-the-book Agile Is No Longer Agile

Anders Abel user avatar by
Anders Abel
·
Sep. 18, 13 · Interview
Like (0)
Save
Tweet
Share
6.42K Views

Join the DZone community and get the full member experience.

Join For Free

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.



agile scrum

Published at DZone with permission of Anders Abel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Unlock the Power of Terragrunt’s Hierarchy
  • 5 Common Firewall Misconfigurations and How to Address Them
  • How To Set Up and Run Cypress Test Cases in CI/CD TeamCity
  • A Gentle Introduction to Kubernetes

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: