Why Scrum doesn't make you agile

How to make the most of Scrum on your agile journey

Just like reading a book doesn’t guarantee you are able to use the knowledge contained within it, so too following the rules of Scrum doesn’t guarantee that you are able to live the manifesto for agile software development.

Scrum might indeed be the golden bullet you have been looking for, but it’s of little use without the gun and knowing how to use the gun. This post is intended to help you find the gun to load the golden bullet. It contains a few reasons why Scrum is not enough to make you agile, followed by how to get the most out of it and how to use it in order for it to be the golden bullet you hoped it would be when you embarked on your agile transformation.

Disclaimer. This is not intended to be a criticism of Scrum (for my opinion on why Scrum works, read this), but rather a call for people to realize that there might be life after Scrum and to invite them to look at alternatives outside of the Scrum framework.

Reason # 1 — It’s a static recipe.

Scrum is a pre-defined process containing a set of fixed rituals and roles that remain unchanged throughout its implementation. Inherently, this is un-agile, with the first line of the agile manifesto being

“We are uncovering better ways of developing software...”

…implying that there is constant change underlying an agile organization.

Agile in its essence is about cultivating a learning mindset that is able to perceive changes in the environment that might influence the business and adapting to these changes faster than your competitors. By sticking to Scrum as it is without adapting the process, teams, sprints and even the rituals as the founders suggest, it is subliminally teaching you not to find better ways to do the work. It’s teaching you to be obedient and follow the rules and not question what authorities think is the best for you.

Solution #1 —Keep curious. Keep moving.

View it for what it is — a framework — not a methodology. An empty shell that needs to be filled in with the details by each organization or team.

The Scrum rituals can be a great starting point for your agile journey, but it is only the first step of going agile as I explained in more detail in a previous post.

All teams I have worked with naturally adapted their standard Scrum board to a more Kanban like board to depict the actual workflow rather than simply using it as a task board.

A Scrum board is an excellent starting point for an agile transition but it will soon not be adequate to reflect the bottlenecks stopping the team from achieving their goals and it should be adapted.

Other than Kanban boards, there are many agile techniques out there that is not covered in Scrum at all. XP contains a bunch of useful and more practical techniques, including pair programming and TDD (test driven development). Then there is a selection of ideas and methods contained within the Lean Startup Methodology which can be applied, Lean Manufacturing is another rich source of methods and my favorite is gamestorming — a selection of tried and tested low-tech techniques to improve collaboration and creativity within a group.

Don’t stop with Scrum. It’s just a framework. Keep looking for more useful ways to do things and fill in the blanks. Keep reading blogs of fellow agile enthusiasts to gain insights and ideas to take your agile transformation to the next level.

Reason # 2 — It values following a plan over responding to change.

The goal of agility is to do more with less resources, faster. Productivity and agility goes hand in hand and the only way to achieve this is by adapting to change in order to meet the goal.

The Scrum guide suggests that the sprint, for example, is time-boxed and should have consistent durations throughout development, valuing the plan over responding to change.

Although the intention of this approach has merit, in real life, shit happens. Sometimes you really need just one more day. Sometimes you finish earlier and it doesn’t make sense picking the next story. Sometimes there’s an earthquake. Or Easter holidays. Or simply just too many non-sprint required tasks that keeps you from being productive.

Following Scrum blindly teaches you to follow the plan over responding to change. Being agile is about trying out different options, failing fast, and adapting quickly in an aim to deliver working software. Above everything, it is the results that matter, not the process.

Solution #2 —Start with the end in mind.

Too much change is as bad as no change at all, which is why it is good to standardize things that do work. For the founders of Scrum, a set sprint duration worked. That doesn’t mean that it is going to work for you, especially when you are still finding your rhythm, though and it is valuable advice to attempt to level out the effort in a repeatable rhythm.

Use the Scrum Guide as a tried-and-tested recipe, but focus on the end-goal rather than the process, and take it with a pinch of salt. Don’t be a blind follower of Scrum, try it, change it, see what works and what doesn’t and find your own recipe.

Constantly re-evaluate whether what used to work before is still the best way to do things, with the understanding that you know more each sprint and each sprint has different goals, requiring different strategies.

Do it because it makes sense and it works. Not because the Scrum Guide says so.

Reason #3 — Velocity is just a number.

There’s a saying in Quality Management that “What gets measured gets done”.

This is in fact the key to getting results that you want as any good Quality Manager would know. By focusing on the measure you want to see you, you inevitably reach those targets. The one thing to understand however is that once you’ve reached these targets, they should be reviewed and changed as the problem invariably has shifted for it to remain valuable.

Quality is about remaining in equilibrium throughout the organization. There is little use in developing fast but not able to release. So too there is little value in being able to deliver fast but not getting good quality code to release. It’s a false sense of improvement.

The point I’m trying to make is that a measure is only as good as long as it’s valuable and it only remains valuable for as long as it reflects the bottleneck or weakest link in the system.

Viewing velocity as a reflection of relative productivity of the team is setting you up for failure. When each sprint the velocity goes up, most probably all it reflects is that the team is getting more cunning at hacking the system. Most probably estimations will get higher, stories will get smaller and bugs moved to another sprint rather than more work being done.

Solution #3 — Measure what makes sense.

In reality, a team has an optimal productivity rate and it is unrealistic to expect them each sprint to get faster and faster. Agility is not about being faster, it is about responding to change faster and focusing on the right work, not busy work. When you rush to get work done, you often end up realizing after it has been done that it was the wrong work and that something else was more important.

Measure what makes sense and what is important. Now. And then change it. Spend more time to think what the problem is and what success would look like.

When too many impediments are the biggest problem, measure that. When that problem is more under control, start uncovering the next problem and measure that.

Reason #4 —Scrum is not a competition.

Scrum was born in the development environment, encouraging friendly competition between different teams to be the best (although, in all fairness, not intentionally driven by Scrum but part of human nature). It excluded other parts of the organization and still does to a large extent.

Even the use of the word “Scrum” implies a head-on-head collision between two competing teams with the desire for one to win and the other to loose.

While this can be beneficial in some cases, it also fragments the organization into distinct pieces that tries to be better than the other. The mostly unintended result of this is that teams subtly sabotage other teams by refraining to share knowledge or help other teams reach their goals in a fear that they will not be the ‘winning team’ if they do.

I once worked in a large company with different development teams with one team having a really bad reputation for not completing work and when they do, it is usually filled with errors. Although inside the organization everyone viewed this team as the cause of all the issues, in reality, the entire organization’s reputation suffered as a result. The customers didn’t care that one team was responsible for the back-end and another for the front-end. They care about working software, and when one part doesn’t work, the entire system is perceived as not working.

Solution #4 —Focus on Flow.

You are as weak as your weakest link. The entire company suffers when one team doesn’t perform at their potential productivity. There are no winners and losers in the big picture as shown in this fictitious scenario depicting the time spent on taking a customer need from inception to delivered.

Focus on the entire flow of the system as a whole and on improving the flow, not one team’s velocity.

Reduce lead time and waiting time rather than trying to develop faster. In most organizations, it’s not the developers causing the lead time to be long, it’s often the key stakeholders unable to make decisions, or requirements not being adequate, or even infrastructure not able to handle continuous integration. The list goes on.

Measure the lead time from idea to live in production per story and aim to reduce this measure rather than optimizing the already working parts.

Reason #5 — Customer Collaboration and the role of the PO

A criticism I have for both the XP and Scrum evangelists are the importance that is often placed on the PO having to be available to answer any questions the developers might have during the sprint.

Again, this is not mandated by Scrum explicitly, yet more often than not seen in the agile transformations as there is a lot of emphasis in the Scrum Guide placed on the actual artifacts and measures, not the relationships and the collaborations.

The Scrum Guide doesn’t contain any section dedicated on customer collaboration or relationships. Understandably, as mostly this is implied and hard to articulate in words as it depends on so much, but invariably this causes the focus of many Scrum implementations only to be on the process, roles and artifacts and not the relationships.

Remember, every moment the PO spends with the developers is a moment that they are not collaborating with the customer. The less they collaborate with the customer, the less likely the PO will be in solving the right problem.

Solution #5 — Relationships first.

Success relies 100% on relationships.

It’s close to impossible to build a great product when the designer and the developer doesn’t want to speak to each other or the Product Owner is too scared to question the customer and challenge their requests.

More than anything, the soft skills like communication, conflict resolution and negotiation are the indicators of how fast a team can produce something without having to redo it. Spending time to build relationships might not feel productive, but the cost of not having good relations within a team and between the team and the customer is the number one reason for customers looking for alternatives or the wrong software being developed.

Focus on the items in the Scrum Guideline, but don’t exclude the importance of relationships.

And the PO is not a dedicated resource that should be available at all times to the developers. They should spend equal or more time with the customers than what they do with the developers.

Conclusion

Scrum is good. It might even be the golden bullet you’ve been looking for. But just like no one medicine is the anti-dote to all illness, so too no one methodology or framework is the solution to every organization’s problems.

Please don’t just Scrum on. Question whether it works for you and try new things. Fail fast. Learn from your mistakes, cultivating a culture of Kaizen. And most importantly, focus on the relationships. Healthy relationships are a far bigger success factor than most others.

Originally published on Medium: https://medium.com/teal-times/why-scrum-doesnt-make-you-agile-33f89498c02a