Presently it seems that organizations can adopt four product delivery patterns: Not doing Scrum and not being Agile, doing Scrum and not being Agile, not doing Scrum and being Agile and doing Scrum and being Agile. Which is yours?
There is a core difference between the goals of Agile and Scrum. Agile strives to get the right products that our users want quickly. Scrum is a process consisting of ceremonies and artifacts for managing product development. Nevertheless, for many, Scrum rituals became a goal and they fail to enjoy the benefits of being Agile.
Product development is complex. Achieving agility requires discerning right from wrong in order to adapt to changing circumstances while focusing on the goal. Scrum can surely help; however, too much Scrum might lead us to the dark side of the force.
As Yoda would have said; …”to the team listen you must…, the team behaviors observe, the language they are using notice”…– and ask yourself- are we just going through the motions of Scrum? Or are we directing ourselves to the goal of being Agile?
Over the years I have noticed that companies achieve four possible patterns on their Agile and Scrum transformation:
- Not doing Scrum and not being Agile
- Doing Scrum and not being Agile
- Not doing Scrum and being Agile
- Doing Scrum and being Agile
Which one are you???
Which one do you want to be?
Let’s further discuss the four patterns:
1. Not doing Scrum and not being Agile is rather straight forward; there is no intent on being Agile and Scrum is just a word people sometimes use. The project management organization employs a top down managerial approach coupled with a waterfall phase gate methodology. There is abundant use of templates, registries, project documents, processes, tools and techniques. Usually this means that the project managers succeed in spite of an overarching, often encumbering and wasteful project management methodology. Project managers do deliver projects by maintaining a three level reporting structure: In the first, they conjure reports using the mandated templates for phase gate approval. In the second, they apply green traffic-light status for PMO and executive management control, using the software tools in place (Microsoft Project anyone?). In the third, they issue tracked spreadsheets to REALLY manage projects.
Probably in the near future this type of organizations will consider implementation of Agile approaches in order to remain competitive.
Understanding the differences between the three other options is therefore important for organization leadership.
2. Doing Scrum and not being Agile is more challenging to discern. It occurs in organizations adopting Scrum as their preferred Agile approach. The astute observer will notice team behavioral patterns that suggest mechanical adoption rather than assimilation. The psychological pattern is that of introjection – similar to chewing on a mouthful of dry biscuits not being able to swallow.
Similar to other managerial process, it is easy to adopt the Scrum ceremonies rather than their intent. We have seen it occur previously with Six Sigma, Total Quality Control, and other managerial processes. Achieving the intent requires a cultural change; cultural change requires organizational change; organizational change requires buy in from key stakeholders which in turn requires people championing the new process across the organization. Without the cultural change adoption easily falls into doing Scrum rather than being Agile.
3. Not doing Scrum and being Agile is the best result organizations should target. If you think about it: Scrum is a method to achieve a goal rather than the goal itself. Being Agile is a mindset prevailing in the organization. Agile organizations follow the Agile Manifesto as a set of values and principles that identify what Agile is supposed to be. They implement fast feedback for value delivery, shorten development cycle time, innovate the process and the product and involve and collaborate with stakeholders.
4. Doing Scrum and being Agile – is the holy grail of companies setting out on their Agile transformation. They embrace team Scrum as a starting point however; in order to become agile they implement technical practices on the team level, as Scrum doesn’t suggest delivery practices. In addition they impact the organization on levels beyond the team level Scrum. These organizations understand that Scrum is a part of a successful agile transformation; a starting point rather than a constant state.
Where is that Holy Grail? How do we become Agile?? The first important step would be to understand the core difference between the goals of Agile and Scrum.
What is the goal of Agile?
Get the right products that our users want quickly, using fast feedback loops employing continuous removal of waste. In other words, faster throughput, less work in process, more aligned with what our users want based on their feedback to actual features we provide. Jim Highsmith has a good definition of agility:
“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment” http://jimhighsmith.com/what-is-agility/
What is the goal of Scrum?
Depends who you ask and what you want to hear.
If you consult the Scrum.org you will find the following definition:
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.
Or you can consult the Scrum Alliance:
Scrum is an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.
There are elements within Scrum that when embraced properly lead to an Agile mindset: Time boxed planning session, collaborative team process and retro are highly effective elements in the Scrum framework that when guided well, lead to an Agile mindset.
Unfortunately, a dogmatic use of Scrum can lead to results that are not Agile at all. During agile coaching engagements I have noticed that when teams focus too much on the Scrum process they receive unwanted results. To give some examples:
- A team is spending its first five Sprints discussing the proper way to size stories;
- A Scrum Master too intent and prescriptive on all team members’ participation in the retrospective which resulted in alienating himself from the team and later asked to move to a different one;
- A team that “fired” their product owner for making a suggestion during a stand up, because she irked team members while resolving an issue;
- A team that continued arguing about backlog refinement timing, whether to include it in Sprint planning or rather schedule it to the previous week;
- A team that wanted to speed the refinement process and had stories pre-refined by two members, only to be snubbed by the Scrum master for not having everyone participate.
- A team that was going through retro touching all the process points however failing to follow the improvement mindset
For many teams following the rituals perfectly has become a goal. It is seductive, focusing on the rituals and completing them precisely as prescribed; since it’s enticing to follow them exactly as they were meant to be. It is what many blind religious followers (Zealots) practice. It is Scrum dogma, focusing on the rituals, rather than embracing the intent.
Organizations that practice Scrum zealotry have failed to enjoy the benefits of being Agile. I assume that this is how the term: going through the motions in regards to Scrum was coined.
Maybe it is no coincidence since when we consult the Scrum guide it is difficult to identify what exists apart from the motions, the ceremonies, and the artifacts. This makes adopting the ceremonies rather than the intent easier. Thus teams cling to the rituals like dear life, and in the process lose being Agile.
Some of the zealotry of doing Scrum without being Agile emerges from the Shu, Ha, Ri – levels of mastery; Scrum evangelists inform us that to achieve mastery, to become Agile, we need to repeat the motions many times (Shu) in order for them to become a habit (Ha) and then we can achieve mastery (Ri) and become truly Agile. Jeff Sutherland relies on the same Shu-Ha-Ri philosophy when he expounds "You enter the dojo and do what the Sensei (teacher) says. You repeat exercises over and over until it is part of muscle memory. Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others." See: Shu Ha Ri – What Makes a Great ScrumMaster?.
But, can Agile Jedi mastery flow from repetitive Scrum practice? I think not. Rather it is a fine balance between following ceremonies on the one hand and discussing merits and embracing a pragmatic process approach on the other. Remember that a Jedi is above all a master of political compromise rather than a blind follower. Moreover, product development is not Karate and Scrum is not an undertaking performed by separate individuals. See more: Shu-Ha-Ri Considered Harmful?.
Teams developing products are more than a group of individuals practicing kicks together; they actually produce sophisticated results rather than draw blood. Their interactions and respected team dynamics resemble more a well-tuned Jazz band, than individuals in a martial art Dojo. See more: Everything I Needed to Know About Scrum, I Learned from Jazz.
The latest addition to the battle field state-of-mind of Scrum can be found in the Sutherlands book – Scrum: The Art of Doing Twice the Work in Half the Time.
Sutherland, relates Scrum origins to his experiences in the military. The Long Gray Line” p.45 Scrum: The Art of Doing Twice the Work in Half the Time
Personally, I find making a parallel between how teams interact in a business environment and how soldiers form teams in a totalitarian military regime, offending. Using the metaphor of a military company marching at a parade as an example of team transcendence is missing the point – repetition can sometimes lead to greatness however more often it leads to mindless compliance and horrendous results. Yes we want this behavior in the military, no – we don’t want to have it in business and democratic environments.
There must be something else to guide us, to move us away from the motions to the intent. How can we master the force?
Agile Jedi’s do train. Moreover they also listen to their hearts – what is right and what is wrong – in order to adapt to changing circumstances. They also listen to the team’s heartbeat and rhythm, which is different than the training of individuals. Great teams are more than the sum of their parts, moving towards mastery. Read here for more.
Being Agile rather than doing Scrum – it is important to focus on what we want to achieve - getting the right products that our users want quickly yet in the required quality, using fast feedback loops, employing continuous removal of waste. In other words, faster throughput, less work in process, more aligned with what our users want, based on their feedback to actual features we provide. Scrum can surely help, however too much Scrum might lead us to the dark side of the force.
And as Yoda might have said ..”to the team listen you must…, the team behaviors observe, the language they are using notice”…– and ask yourself- are they just going through the motions of Scrum without directing themselves to the goal of being Agile?
Maybe you can start your next retro with a discussion about:
There are four options for companies embracing Agile and Scrum -
- Not doing Scrum and not being Agile
- Doing Scrum and not being Agile
- Not doing Scrum and being Agile
- Doing Scrum and being Agile
And may the force be with you…
About the Author
Michael Nir - M.Sc. Engineering, SPC, PMP, PMI-ACP, president of Sapir Consulting, is a management consultant, Agile coach, speaker, and best-selling author. He has been helping organizations overcome business challenges and deliver value for over sixteen years.
He is passionate about Gestalt theory and practice, which complements his civil and industrial engineering background and contributes to his understanding of individual and team dynamics in the business setting and elsewhere.
