There are quite a few software engineers out there who are tired of agile and Scrum. I keep encountering this opinion over and over again:
“I am sick of agile/scrum and it is terrible to work in. There are better ways to do estimation. And the idea of a t-shaped employee learning all the jobs of everyone on the team is insane and insulting. I have a degree in computer science. I have been coding for years. No one is going to learn my job part-time who doesn’t have a similar background. This why I hate agile/scrum!”
There is a lot going on there to address. But I think it needs addressing. Not because it is wrong, because this sort of misunderstanding will lead a lot of teams away from agility and to a dark place where they are experiencing learned helplessness and don’t have the vocabulary to push back against practices and ideas that hold them back.
What follows is not a correction. It is a clarification. Hopefully, I have added enough additional information that the problems people are experiencing are exposed so they can make improvements.
Definition of Agile
Agile and Scrum are not synonymous. They are two different things.
There is no universally accepted definition of Agile other than the Agile Manifesto. The Manifesto is the letter to the world written by 17 software developers who were all working on improving how software development is managed. It isn’t just a letter to developers – it is a letter to management telling them that there are better ways to lead a team of professional product developers.
The definition of Agile is in the first principle of the Manifesto’s attached principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile is how able you are to deliver frequently for customer satisfaction. It’s essentially your Time-to-Market. It’s a measurable number. Agility enables you to use empiricism to gauge customer satisfaction after delivery and then make new decisions. The more frequently you can deliver, the faster the pace of learning, and the more likely you are to deliver what the customer wants and stop spending money when you reach the point of diminishing returns.
Agile teams are able to deliver frequently. They learn faster, they have lowered risk, they reduce overall cost to build, they have lowered cost to own, they can exploit opportunities that emerge but are only available temporarily. They bring just about every advantage that a business owner could want from their software development experts.
When viewed this way, the word agile is an adjective.
Definition of Scrum
Scrum is a framework intended to create agility by using rules as forcing functions to encourage the lean behaviors that lead to agility. Concepts like cadence, small batch work, short horizon planning, decentralization, and other lean ideas create flow. The sprints and events are intended to help with agility and give a structure through which you can enact empiricism.
Scrum is a way of working. Agile is the outcome from working that way. Scrum is not the only way to become agile. It is entirely possible to do so without following all of the rules of Scrum. However, in the pursuit of agility, you will inevitably end up following most of those rules:
- You will establish a cadence to create flow and ensure the queue is replenished and that work and the process are reviewed. You now have sprints, sprint planning, sprint review, and sprint retro.
- As you work your cadence, you might establish a goal for each iteration. You have created the Sprint Goal.
- You will probably plan each iteration. That plan is a Sprint Backlog.
- These iterations you are doing are probably in pursuit of the next thing on the Product Roadmap: the Product Goal.
- Because you are moving quickly, you will want to meet regularly to ensure the team is aligned on what emergent problems to solve that are hampering flow. You now have a daily.
- You will have a queue of work piling up that someone needs to organize. You can do it as a team, or perhaps you can convince someone in “the business” to own it and put it in order. Now you have a product owner and a product backlog.
- As you realize that having code written is not improving agility, you begin shifting things right of coding to the left into the team. Testers, deployment capability, etc become members of the team dedicated only to the work of the team. Now you have a cross-functional team and a Definition of Done.
- It is likely that no developer on the team has read 100 books about enacting lean concepts and empiricism on a team, and it is helpful to have someone play devil’s advocate around the team’s practices to keep them continuously improving. You just hired a Scrum Master.
Why treat them as rules? Why not just consider them recommendations? The rules are forcing functions designed to expose obstacles to agility. If you don’t follow a rule, you are probably allowing a problem that you could have solved to be covered up and cause problems for years to come.
My proposition: isn’t it possible that in the pursuit of lean concepts such as small batches of work, WIP constraints, cadence, customer feedback loops, and decentralization, that we inevitably end up with something that looks an awful lot like Scrum? The difference between a highly-evolved Kanban implementation and Scrum is batching of the iteration vs. the work item.
Not Part of Scrum
Most of what people hate about Scrum is not part of Scrum and cannot be found in the Scrum Guide.
- Story points – these are not mentioned in the Scrum Guide. The word “story” appears only as part of the word “history.” The word “point” only appears as part of the word “pointless.” Story points were invented by Ron Jeffries. He was not practicing Scrum. His team was doing xP.
- Velocity is not mentioned in the Scrum Guide.
- Burn down charts are mentioned in the Scrum Guide as a complementary practice, but they are not required by Scrum and are just a popular thing to do like story points and velocity.
- Estimation is not mentioned in the Scrum Guide. Scrum doesn’t require teams to estimate work. It uses the term “size.” Because story points are so popular, a lot of people misunderstand that to mean we should assign a size in points to an item, but sizing is intended to mean breaking down work items into smaller items.
- T-Shaped Employees – The idea of being T-shaped doesn’t appear in the Manifesto, and it is not a rule in Scrum. The guy who came up with the idea didn’t even do Scrum. Scrum says that a team must be cross-functional. Cross-functional does not mean t-shaped. Cross-functional means that the members of the team come from all functions needed to do the work. It’s an attempt to get rid of functional silos, the handoffs they cause, and the waste associated with them.
- Going around the table at the daily is also not part of Scrum. The Scrum Guide says, “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.” Everyone doesn’t have to report in at the daily and make it a useless status update. Problems here might be self-inflicted.
The rules of Scrum were written to be minimalist and allow a team to develop their own way of working within the constraints of fixed-length iterations. People will argue against following those rules, “We need to be flexible. This is agile so we can pick and choose what to do.” That too is a misunderstanding. Nothing related to agility says that we need to be flexible and work in a way that fits in with the way we already work. Agility is a numerical measurement of frequency of delivery of working software. Some things will help you shorten your delivery cycle. Some things will make it much, much worse. We cannot do whatever we want and achieve a specific goal.
The purpose of this article is not to tell you to follow the Scrum Guide and do Scrum because it works everywhere all the time for everyone. Scrum does not work or not work. It is the people who are doing it and the people they work for who either can make it work or not. You can decide for yourself what works best for you. But if you say you are an agile team, then I am going to ask you how frequently you deliver working software and how long it take you to get to customer feedback. If the answer is “three months,” what you are doing is not working.
My suggestion: read the Scrum Guide carefully and realize what has been forced on you vs. what is actually a rule of Scrum. Then read about lean product development, and put the two together, and you might see something of great value to you.
The Scrum Guide is located here: https://scrumguides.org. The Kanban Guide is here: https://www.prokanban.org/the-kanban-guide
If you want to read about the lean concepts that Kanban or frameworks like SAFe and Scrum are trying to enact, the best book for that is The Principles of Product Development Flow by Donald Reinertsen.
If you want to learn about what to measure, then here’s where you start: The Evidence Based Management Guide.