It seems that the debates about scrum are always ongoing and it or agile development in general is still a pretty hot topic. There’s even a new job role ‘agile coach’ as more of an industry is built around it. The world is ever more moving online and getting more digital, so it’s a big market.
I think too much is expected of scrum and agile practices and that it is viewed particularly by non-technical people as some kind of development process panacea. It’s also worth remembering that scrum came more from the project management side of things rather than the technical side like extreme programming (XP).
My first scrum project was in 2007 and it was text book stuff. I was in the ‘chosen’ team working on a cool new green field project in a special room and we even did planning poker (for a while). Over the years, in different companies we all did what I now call “scrum-but”. I got this phrase from discussions with people in different organisations asking how they do scrum. It goes like this:
“So you’re doing scrum right? How’s that working for you”
And the answers would invariably be:
“Yes we are doing scrum but we’re not doing this.. “
“Yes we are but we’re doing this…”
“Yes we do scrum but..”
In short “scrum-but”.
The real world is different than what you learn in scrum trainings or read in the books and I’ve seen a lot of this:
- Product owners have a very clear idea of what they want and don’t consult the technical staff until just before the project start. Technical viability and cost is often not explored
- It’s worse if design agencies are involved because then there is no room for feedback, it really is just a case of ‘implement’
- Often, there is little concept of minimum viable product
- Real user feedback isn’t gathered until just before the release or after, there is no feedback and altering of requirements until it’s too late
- Stakeholders and owners often don’t care about the technical details, maintainability and quality and if external code shops are involved, they will probably not be thinking of how the thing will be in five years time
- Scrum is fine for projects but once the project is released, it then goes into maintenance and extend mode. What then?
- Technical teams are often working on multiple areas at once, new work, maintenance and ongoing development work. That doesn’t fit with the idea of nice clean projects and backlogs
- Not nearly enough focus on fundamental technical issues such architecture, quality, testing
- And for agencies, how do they manage billing and cost estimates if the whole thing is done iteratively? This was a big topic for agency managers on a scrum training I went on and the answer was “look, scrum doesn’t solve your business model problems”
- User stories like, ‘As a log file I don’t want to see error message xyz’
After I did a scrum master training in 2012 none of this bothered me any more regards scrum, because I realised that scrum was a square peg in a world was full of round holes. And from then on I decided to just take the good bits from scrum, other lean principles, XP and just make them fit the need and environment, ‘scrum-but’.
I think the trick is knowing where the line is on technical compromise, that’s personally where I don’t budge. Make sure here you have a strong technical lead who gives honest feedback. At the end of the day, corny as it sounds, project success and ongoing success is about people, teams, trust and responding correctly to business needs.
Martin Fowler reposted this post from 2009 last year, and it’s as valid now as then. http://martinfowler.com/bliki/FlaccidScrum.html
Klaus Harris 