Striking a Balance: Let Scrum Die
Striking a Balance: Let Scrum Die
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
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 great 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.
After the Honeymoon
Regardless of the hyper-performing tagline of Scrum, each team eventually 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. This is certainly a better position to be. However, it is also an overly comfortable situation, and I foresee signs of chaos not far away again. This is what is happening and it is more common than many are willing to admit. 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, domain driven design and more(+). These are the things that you hear from the software craftmanship community. Again, it is not about replacing Scrum for code craftmanship. It's about striking a balance.
Let Scrum Die
Let's pause at the plateau of complacency for a moment. This 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 the process for excessive support.
Often, the closest person in the process to lean on is the Scrum master. This is such a subtle situation of dependency because the Scrum master is presented as a necessary part of the process when the state was that of chaos. Instead, the chaos is under control on the plateau, and so the focus and actions of the team and Scrum master should be re-evaluated. My view is that a step off the plateau to a higher level can be taken by planning the exit of the Scrum master, there by encouraging the team to take greater responsibility. This can only be done when there is an earnest effort to bring the code base under control.
When Scrum has died
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 sweetly and each part supports the other part in symbiotic relationships.
- The code base will get smaller and the team will shrink to, perhaps, just 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.
- The developers will represent the interest of their customers directly.
- The bottleneck will shift from development to the product owner and eventually the customer.
Why is this necessary?
Partly what motivated this introspection is the crazy blog and tweet war that started with Dan North's take on the software craftmanship manifesto. I only followed the trail as far as Martin Fowler's view. Martin and Dan put the customer's derived value from the software as the focal point. The craftmanship movement puts the code that derives the value as the focal point. I don't feel comfortable about either. It is unbalanced.
So, what will provide an equally powerful balancing force to either of these two focal points? I think it is the economic viability of the code base. Earlier, I said that Scrum practioners need to give due attention to bringing the code base under control. It is simple. A code base under control is one that is economically viable. Without an economically viable code base, you have problems bigger than Scrum and craftmanship.
Striking the Balance
In the discussion above, the key message is that Scrum should not be the end goal but a means to get somewhere better. At some point it will outlive it's value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master). I also describe "talented developers" which, perhaps, feels like a craftmanship-esque thing. It's not about that at all. It's about the balance that is achieved when developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable). We need to balance the focus on methodology with a focus on the economic viability of the code base.
At the same time, a narrow focus on just clean code and code craftmanship is equally unhealthy. Look at yourself and look at what you create (i.e. the code base). Also look at the person next to you. That is vital because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers. We equally need to balance the craftmanship with the economic viability of the code base.
There is one area where I don't know of a powerful enough balancing force. I recently blogged about it in Politics of Software Delivery. I draw attention to organisational power grabbing that will always result in non-delivery. I suggest raising the importance of the delivery value. But I think this force is still too weak to balance the power battle. I don't know how to fix that one.
Am I being idealistic? I don't think so. It’s about pragmatic decisions and the pursuit of freedom. It’s hippie Scrum.
(+) Jimmy Nilsson reminded me of an article he wrote about TDD, Refactoring, DDD, and why all such things matter.
(*) 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.
This article is derived from my following blog posts.
Opinions expressed by DZone contributors are their own.