How to Detect Fake Scrum?

2022-08-01

Tags:

Agile

Some organizations are adopting agile and Scrum approaches simply because they see competitors doing it. In these situations, there is rarely a desire to adopt a new mindset and culture, or motivation for true change.

A common pattern is the adoption of a new nomenclature. Project Managers are renamed as Scrum Masters. Business Analysts become Product Owners.

Very little actually changes. Few benefits of agility are realized.

If anything, the situation may become worse as some previous structures are lost, yet the discipline for Agile is just not there.

Larman’s Laws

Craig Larman is one of the founder of LeSS. He has formulated laws based on his observations. The laws reflect the difficulty of a successful transformation.

Organizations are implicitly optimized to avoid changing the status quo of middle- and first-level manager and specialist positions.

The corollaries are:

Any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.

Any change initiative will be derided as purist, theoretical, revolutionary, religion, and needing pragmatic customization for local concerns. It deflects from addressing weaknesses, and manager or specialist status quo.

If after changing the change, some managers and single-specialists are still displaced, they become coaches or trainers for the change. They frequently reinforce (1) and (2).

In large established organizations, culture follows structure. And in tiny young orgs, structure follows culture ^[1].

— Craig Larman

Fake Scrum is around us everywhere we go. This dreadful situation is unavoidable.

Five Scrum Fake Indicators

How to find out if you are in a fake agile environment? Indicators you are in a fake agile or Scrum environment often are:

No goals

If a Scrum team has absolutely no goals, what is the purpose of its existence?

All good teams have goals. Scrum bakes the concept of goals right into the framework.

We have product goals, which are a commitment to the Product Backlog. And then we have Sprint Goals, which are a commitment to the Sprint Backlog. Those goals are designed to help us achieve focus, get stuff done, and get results.

If you do not have goals, you got fake Scrum.

No Self-management

A team that cannot self-manage is a team that cannot be nimble. They are not going to be quick. They are going to stall. They are going to wait to ask questions. They will always be asking for their boss’s approval.

Teams like this are very slow. The whole point of being agile is to be nimble, right?
So, if it does not feel like they are being nimble, I should look a little deeper.

Self-management is a really common problem.

It can happen from a lack of trust with the boss or your business stakeholders. It can come from a lack of trust for each other as team members.

Wherever your problems are, self-management is crucial to have working in order for Scrum to work. If you do not have self-managing going on, it is probably fake Scrum.

No deliverables

No increment at the end of the sprint. The entire point of Scrum is to have releasable increments for every single sprint. Without that, well, we are just cranking a bunch of levers.

To get to a deliverable can sometimes be kind of challenging. You have to write requirements in such a way that something can be delivered in just a short timeframe.

No transparency

Without transparency, I cannot inspect, I cannot adapt. If I cannot inspect and adapt, the entire empirical process falls apart. If the entire empirical process is falling apart, you got fake Scrum. Scrum is built upon this engine.

Scrum is built upon the idea that we make things transparent.

We inspect and adapt at the appropriate frequency, and that is how we manage all the complexity of product development. We certainly cannot eliminate complexity, but we can work with it. So, if you do not have transparency, you got fake Scrum.

No results

If you got stakeholders that do not see a difference. They do not care if they are not talking to your team. They are not talking to your product owner ^[2].

If you are not delivering results then what is the point of your work in the first place. You are probably doing fake Scrum.

Digital Software Product Development

The software industry has created and promoted agile and Scrum approaches. A development department is responsible for delivering working software each sprint. Accordingly to the Scrum, a potentially shippable product is the increment result produced multiple times per week.

You can easily detect fake Scrum and incompetent software development teams:

Git commit multiple times per day per developer: All your software development teams are working with git. Each developer creates multiple well-commented commits per day. Use git history to check this hypothesis.
Here some links to how you can use git [2][3] [4].
Deliver working applications multiple times a week: All teams deploy their digital increment multiple times per week. DevOps practices ^[3] are lively in our organization [1, 2].
No errors older than a few days: Quality and craftsmanship are cornerstones of agile approaches. A way to check these good practices is to study errors reports [5]. Another test is to look at the OWASP static analysis and the obsolete libraries reports.
Living documentation: Professional developers provide adequate and actual documentation for their solution. Does the team have living documentation. This documentation is often a generated static website [6]. Agile software architecture regularly uses domain driven design ideas [7]. Ask the team how they do software design activities?

Final Thoughts

Walk the talk. Become a professional Scrum master [3], product owner [4], or team developer.

A digital product development team shall be DevOps affine [5, 2, 6].

See also another blog [1] describing how the department of defense of the USA detects agile lies.

References

[1] N. Forsgren, J. Humble, and G. Kim, Accelerate: The Science of Lean Software and DevOps. IT Revolution Press [Online]. Available: https://www.amazon.com/dp/B07B9F83WM

[2] D. Farley, Continuous Delivery Pipelines. 2021 [Online]. Available: https://www.amazon.com/dp/B096YGZVZ9

[3] S. Ockerman and S. Reindl, Mastering Professional Scrum. Addison Wesley, 2019 [Online]. Available: https://www.amazon.com/dp/B07XTLNPTC

[4] D. McGreal and R. Jocham, The Professional Product Owner. Addison-Wesley Professional [Online]. Available: https://www.amazon.com/dp/B07D5ZPJBY

[5] J. Humble and D. Farley, Continuous Delivery. Addison-Wesley Professional, 2010 [Online]. Available: https://www.amazon.com/dp/0321601912

[6] G. Kim and N. Forsgren, DevOps Handbook, Second. IT Revolution Press, 2021 [Online]. Available: https://www.amazon.com//dp/B09G2GS39R

1. In big established groups, culture/behavior/mindset follows and is influenced by changes in the organizational system and design. In large established organizations, if you want to really change culture, you have to start with changing the organizational system because culture does not really change otherwise. Said another way, the organizational system is strongly influential on mindset and behavior.

2. Your product owner is not doing her job. One key responsibility of a product owner is to involve and inform all stakeholders.

3. Continuous integration and continuous delivery is Dev practices. Continuous deployment and infrastructure as code are Ops practices.