It took some time, but I’m done with scrum. In fact I’m done with pretending in general, but that’s a different matter. As Joost said: ”it takes a lot of time to see you need less to become more.” I’ve long loved scrum though, ever the pragmatist, I didn’t necessarily feel “by the book” was always the right answer. Looking back, that is probably what has driven me to the point I’m at today.
You’re all software companies
I dislike how “scrum-but” is seen as a very negative term, as if you picked up some disease for not following the religion. It’s like being a catholic praying at home but never going to church. It has become the realm of consultants coming in to “evangelize” and “turn the team around” so the inefficiencies can be tackled and the religion indoctrinated at all costs. All hail!
The problem to me is that “pure” scrum is actually a highly dysfunctional approach in many organizations and a local optimization at best. What’s the point of trying to make a hugely effective development team if the rest of the company doesn’t play ball? Right…and that’s assuming scrum is actually delivering those hugely effective teams to begin with.
Less is more
Agile, and scrum for that matter, were always a reaction to the situation way back in the 90s. And while I am still convinced that the values put forth in the manifesto are worthwhile, I also think that they deserve another look. At the heart of it all is a desire to ship software, frequently with high quality. Keep in mind that back then some of today’s tools and practices were not available (JUnit launched in 2000, wide adoption came a few years later probably closer to 2005, and let’s not even talk about today’s deployment frameworks and infrastructure). So really, I think it’s time to sit down and go back to the essence. Let’s stop implementing methodologies for the sake of methodologies and put the entire organization’s focus on developing. As I advised some people back in 2005: building software is not something you do with the engineering department, it’s the entire company’s problem.
So, back to basics
- First and foremost: ship it. Small-ish hypothesis –> software –> measure result –> tweak
- If you’re going to be religious, be so about measuring and displaying results. All hypothesis must come with ways to validate them, build them into your system and make these visible
- automation is king (and yes, the results of automation testing, deployment etc go on a dashboard that is highly visible)
- Unclean code is not an option. Ever.
- Communication happens in many forms. Talking is just one option
- Behaviour of a team is a consequence of productivity, not the other way around. Or put bluntly: teams who get shit done are usually happy, but happy teams don’t necessarily get shit done
The key informal metrics
To me there is one key way I judge any organization: response time without sacrificing quality. How easy/quick is it to ship a trivial change (should be virtually instantaneous). How does that compare to a more fundamental change (should never block out instant shipping of trivial changes). And on a scale from “no” to “yes”, how close are you on average to “great, let’s try it now” in discussions with the people helping you explore and define functionality.