Are You a Scrum Cog Led by a Scrum Mechanic?
Mechanical Scrum — a really bad way how to bring agility to your company. How to move past it?
Popular. Not the best for all.
Scrum is one of the most popular and widespread agile frameworks. Also, it is the most abused and misused one. The trouble with Scrum is that although it can bring huge benefits if used as intended, the very nature of it makes it susceptible to misinterpretation and misuse.
Most of the problems with Scrum come from its technical or mechanical application. Observe these signs:
- Daily Scrum meetings that look like mini-statuses, with every team member just presenting what he did, is planning to do and what obstacles he has?
- Sprint Reviews with no real stakeholders but a bunch of parasitic ones that result in no feedback?
- One- or two-week long iterations producing potentially releasable product increments that are released twice per year?
- User stories (or whatever else you are using) that are non-negotiable or so detailed and technical they don’t allow for any innovation or creativity?
- Product Owners without any authority who just transcribe somebody else’s requirements into the Product Backlog?
- Many dependencies on other teams / units / individuals resulting in your team not being cross-functional and capable of end-to-end delivery?
- Customers and users represented by series of proxies who “translate” their needs for you and maybe even prioritize them for you?
- External departments such as QA, Legal, HR or Finance taking part in the process of delivering software yet being completely detached from your teams?
- Scrum as an IT-only initiative without understanding & acknowledgement from the business?
- Scrum Master who is just a glorified assistant, schedulung meetings in your calendars, dealing with administrative “impediments” and bullshitting about what the Scrum guide dictates you do?
- Short iterations that follow a half-year long release plan with fixed date and set of features so that in fact it is just a traditional approach split into small chunks?
This is mechanical Scrum: the ceremonies, artifacts and roles are there, yet the substance is missing. There is no value being delivered on a regular basis. There are no real needs being addressed. It is doing Scrum for the sake of doing Scrum (and being cool or proving that “our IT can do it”).
Implications of mechanical Scrum include demotivation of team members, no true difference in value brought if compared to traditional approach, blaming agile for all problems and even reinstallation of traditional, command&control culture. Not something you want.
Many of you will now have the simple answer: “Scrum, if done properly, does not lead to this” and that “these are signs of dark / zombie / bad Scrum”. And I agree. I only ask you to think about this:
Scrum, as it is formulated, is emphasizing ceremonies, roles and artifacts. It not only allows mechanical interpretation, to majority of readers — and without deeper understanding — it suggests it. It creates the impression that if you put all of these in place, things will somehow miraculously be great (again).
The authors, Ken Schwaber and Jeff Sutherland, have included Scrum values in the latest revision of the official Scrum guide. Definitely a step in the right direction. The only problem with it is that in organizations, values and culture are not ideal and aligned with the ones of Scrum. They often directly contradict them. And that contributes to many Scrum implementations going wrong — even if you try enacting different values in your team, they will be overrun by the corporate ones.
One framework does not fit all.
The good thing about all this is that it can be stopped. And anyone in the team has the power to stop it or at least seriously question it. Yes, that means even you can do that! And you can start focusing on any of these improvements:
- Pair, mob or otherwise share the work in the team. Although mobbing might not increase speed of delivery (which is not the goal anyway — who would want to have more crap delivered faster?), it improves code quality, overall architecture and most importantly makes teams jell, have fun and learn new things.
- Value finished features over completed sprints. Your users are not buying sprints. They are buying valuable products with important features in them. Why then not focus on finishing features one-by-one as quickly as we can?
- Learn new skills to be self-sufficient. Dependencies are killers of agility. Are you lacking some knowledge? Learn it. Is it a completely different area like legal, marketing or finance? Ask someone who has the experience to join your team and spread the knowledge.
- Question and streamline processes that hinder you. If something is impeding you, be curious. Don’t immediately label it as just a stupid process. Try to find out why it is there and what and to whom it brings value. Once you know that, you have likely either gathered sufficient evidence that the process is useless or you have an idea how to provide the same value in a way that works for you.
- Inquire for and solve real needs. Don’t just accept features as they are thrown at you. Always strive to understand why are these features important and what problems they should solve. Only when you have real needs are you able to design the best solution. Also note that not all solutions are software applications — don’t be afraid to suggest different solutions besides what the IT is normally doing.
- Invest more in learning, less in demand execution. Building software is a complex endeavour. In order to succeed in it, we have to constantly leard — about our users and their problems and needs, about the markets we are working with, about technology. Value this learning more then blind delivery of features.
If you are now thinking: but wait a minute, I am just a developer, how do I do these things? We need a manager to take care of this! No. You don’t. Agility is based on collaboration and the power of people and their contributions. And if you really want to make a difference, don’t wait for an action by somebody else that never comes — act yourself. You, like anyone else in the team, can suggest running an experiment such as mobbing and question things. The key is only for you to be non-judgmental and ask questions not to make others stupid, but of curiosity and with the intent to improve how you are working. Try it and you will be surprised.
Agile is not Scrum. And agility is not agile.
Remember that Scrum is not the only agile framework and it just might not be right for you. Also keep in mind that agile is not something you do — that will end just the IT doing something in short cycles but the business still expecting old behavior and behaving in an old way (= treating the IT department as demand executors, not as partners) — but rather agility is something an entire organization can achieve.
Because our organizations are very different from one another, chances of an universal process, approach or framework enabling agility in them are slim. Don’t despair though. Any organization can foster agility; it only takes some time and you have to find your own path.
While looking for that path, here are some helpful patterns:
- Don’t use a framework, method, tool or process because everybody else is. Chances are for most of them it is not working as well.
- Dont’t fix what ain’t broken. Focus on things that could be improved and improve these one by one, in small steps, gathering feedback as you get along.
- Treat agile as a path, not as a destination. Agile, or agility, is there to help you achieve your business goals. Running two-week iterations without building something valuable for real users may be cool, but is not helping your business.
- Be pragmatic. Sometimes, you just can’t get to where you want to go. Find something else to improve instead or run an experiment to gather data and subsequently use this data to persuade others.
Above all: remember that anyone can start the change and if we are all passive, nothing changes. So try and experiment on a small-scale. I am sure the results will be worth it!
