Is Scrum Agile Enough?
When people forget the goal and focus on the method.
Too many times people confuse agile and scrum. Agile is a concept with principles that helps us develop software better, validate it as soon as we can, and bring value to our customers faster. Scrum is just one of the software development frameworks that implement agile and there are many others including Kanban, extreme programming, lean software development and more.
Scrum is a valid and very popular framework for agile development. There is nothing bad in Scrum, but many times because of its nature, which I will explain below, it is easier to miss the agile concept in scrum vs other frameworks of agile, and some people abuse the framework.
The Agile Manifesto
Before we dive into the details we must remind ourselves what is agile about. Agile is just a means to an end. The agile manifesto talks about 4 values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These values translate to 12 principles:
- Satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development.
- Deliver working software frequently, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Trust them to get the job done.
- Convey information to and within a development team in face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development that maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective and adjusts its behavior accordingly.
The Ceremony Pitfall
Scrum centralizes itself around a sprint. As part of the sprint, there are various ceremonies: sprint planning, daily, sprint review and sprint retrospective.
All of these ceremonies have a lot of value if done correctly and the agile principles are not forgotten. The problem with these ceremonies is that too many organizations focus on them without a good understanding of what stands behind them and forget what agile is about.
Too many times, the focus on ceremony leads to what is called Agilefall. The organization indeed works in sprints with all the processes, but do a long session of writing requirements before and delivers value to customers only 3–4 times a year. This is not agile. I have written more about it in Plans with Problems. Execute with Solutions.
Bigger organizations might even take it further by implementing SAFe (Scaled Agile Framework), which gets the power back to project managers instead of trusting the power of individuals to get things done. Marty Cagan has written about it in Revenge of the PMO.
Planning Waste
Let assume for the sake of the discussion that in your organization you are implementing Scrum as intended and you are working by all the agile principles.
Even in such cases, I think there is a lot of waste in Scrum. There is usually something between a half day and a day of planning. This is one full day out of ten days in which the team only do the planning and do not progress on development or testing. And most of the time developers are very bad in estimating their work accurately, which leads to a lot of frustration.
If people are not motivated enough and need a deadline to finish the work, Scrum may be very effective. If on the other hand, you have a team of motivated individuals that anyway work as fast as they can, they might feel very frustrated by the planning waste time. Don’t forget the Parkinson’s law: work expands so as to fill the time available for its completion.
Another problem with getting everything into sprints is that sometimes there are features that even after you reduce them into their minimum do not get into 2 weeks, and then you need to waste a lot of times into breaking them to small stories not according to value, but just based on time.
Not Fast Enough
In a startup environment, even a perfect scrum process is many times not fast enough. When your product is in the stage of looking for a product market fit and trying to secure its early adopters, many times urgent things enter on a regular basis. Locking the team for a sprint as happens in scrum does not work.
You need to be able to change priorities very fast and your backlog consists of everything that has not started yet. In such cases, I always prefer Kanban in which the team just takes one task after another and do not commit to timelines.
It is much easier to change priorities in Kanban and direct the team to work on the most urgent task.
Deliver Constantly
The perfect fast delivery of value to the customer is, of course, continuous deployment. But not every team is ready for this because it requires a high coverage of automation.
For those of us not ready, I suggest a release every week (many companies call this a “train”, and whatever feature is ready after it was tested gets into the train. It’s a method that many times is referred to as Scrumban.
Summary
Whatever method you choose to work with, do not forget the principles behind it. Your ultimate goal is to deliver the right value as fast as you can so you can validate your assumptions.
Make the process a mean to an end and not the goal itself.
Be Lean
And don’t forget. If you enjoyed the reading you can clap up to 50 times.
Originally published at www.askbenny.tech.
