I live in Cape Town, South Africa. Apart from the great beaches, a mountain in the middle of the city, good food, and good wine there is a feeling of enthusiasm for agile software development in this town. It’s been around for a while but really started getting all hot and sweaty with the Scrum wave. I estimate that it’s been at least 2 to 3 years since some teams in Cape Town adopted Scrum. Of course, there are teams adopting Scrum in this community every year. That’s all good, but I’m afraid it’s shaping to be just like Table Mountain.
Regardless of the hyper-performing tagline of Scrum, each team settles down to something with which everyone is comfortable. The big change that has happened is that of changed behaviour. Scrum does that – it alters behaviours. When everyone plays by the rules (i.e. they behave consistently) then you don’t have chaos. It’s better than better – it’s just nice! It is very comfortable. But I see signs of chaos not far away again. This is what is happening and it is almost without exception here in Cape Town. Some are off the table top already.
Let me make the Scrumvangelists feel better for a brief moment. Scrum won’t kill you – directly, but your adoption of Scrum can kill you if you ignore one thing – your code base. It is a code base out of control that leads to certain death, and Scrum won’t be the saviour this time. Bringing your code base under control is not easy. It is all about architecture, design and changing your style of development to live the principles that end up characterising good code. I don’t need to tell you what you need to do. It’s been told so many times – TDD, refactoring, continuous delivery, single code base, etc. At the code face it’s SOLID and DRY and lots more.
The plateau of complacency is an interesting place. We may think we are collaborating but in reality we have just found a way to work together without causing chaos. I call it co-operation. It’s just keeping chaos under control so that we can make the sprint, again and again and again. A sure sign of being on the plateau is when we can’t get rid of our Scrum master. When we work the Scrum master out of the system, then the team will need to take on more on it’s shoulders.
A major limiting factor to get off the plateau will be the people on the development team. Hyper-performing teams have talented developers(*) that are able to design and express that design in code without breaking their principles. A team that is unable to bring a code base under control will compensate by leaning on a scrum master for support.
In the journey of dramatic improvements to bring your code base under control, there are few things that you should take notice off.
- An architecture will emerge that supports the design of the resident parts. Things fit together beneficially.
- The code base will get smaller and the team will shrink to about 2 or 3 people.
- Each developer will take on greater responsibility and will find it difficult to break core principles. The act of living those principles will result in a values that don’t need to be listed on a poster on the wall.
- The scrum master will become redundant.
- The product owner will do more by working directly with the developers.
Then you won’t need Scrum, because the code base is under control, developers represent the interest of their customers, and the bottleneck is now at the customer.
Am I being idealistic? No, it’s about pragmatic decisions and the pursuit of freedom. It’s hippie Scrum.
(*) By talented I mean developers who have the ability to communicate, share, solve problems simply and elegantly, and can sniff out bad design and architecture. Talented developers are not code monkeys that can churn out code. Their single differentiating trait is the ability to design well and express that design in code.
5 thoughts on “Let Scrum die”
[…] my last post I said we should let Scrum die. We can’t let Scrum die. It doesn’t behave like […]
I understand your points but I disagree with some of them. I think that scrum works because it points out the issues that could arise if an architecture that doesn’t support the design is chosen or a large code base exists etc. Scrum is the process that will raise the red flag and place a focus on needed change.
Also I think scrum achieves the goals you identified does happen in scrum under the following circumstances:
1. Within retrospective scrum meetings where the team constantly looks to improve things and identifies that architecture, code base, taking more responsibility etc are points that need to be worked on
2. The team is empowered to make those changes targeted in retrospective by management
2.1 The team is empowered enough to go to management and get authorization for full sprints dedicated to refactoring (I.E. Full sprints of “money for nothing” features)
3. The scrum roles and dedication to the scrum process is followed diligently.
Nice article! I could not agree with you more. I have also seen several IT departments implement Scrum and then go “whew” that will solve all our issues… only to discover a little bit later that they still have a mess of support and a code base / architecture that is dragging them down.
The tendency then is to lose energy (and focus) or to look for the next “silver bullet” process (or hit the Scrum nail harder) and not address the core issue that is making their software delivery slow. I think Scrum (or any agile process for that matter) gives you a nice start to fixing your problems, but unless you fix your code base (an the complexity that lies within it) you are doomed to be “sprinting in mud”.
I do think that “getting your code base under control” is usually a massive task – not for the faint of heart
Scrum… You keep using that word, but I don’t think it means what you think it does.
The focus on codebase quality is a key component of “done” in scrum. If you code is crap, you aren’t “done,” even if it sort of works.
Applying scrum to an existing crap codebase is a challenge, but so is working with crap under waterfall. In fact, the incremental nature of scrum makes fixing a bit crap at a time easier.
Time and time again we read on developer blogs:Advice = limited life experience + overgeneralisation.