November 10, 2009
Scrum or Kanban? Pick One And Get On With Delivering Quality Code!I'm getting increasingly vexed by this unhealthy obsession with planning and project management, especially among the Agile community.
The likes of Scrum, Kanban and other variations of the put-stuff-into-some-kind-of-prioritised-work-queue-and-pick-new-work-from-the-top theme have become an obsession to the point that one could be forgiven for thinking that this is what software projects are all about.
They are not optional, of course. You need the work queue. It needs to be effectively prioritsed. You need to track progress as objectively as possible. It needs to be highly visible and transparent. And you need the customer to drive all of this.
But these are no-brainers. There's an inescapable logic behind them, and they should take mere minutes to learn to a practical level where they can be successfully applied.
Writing reliable and maintainable code, on the other hand, takes years to master. And I see increasing numbers of teams who are so caught up in the whole planning and project management aspect of their work that they lose focus on bettering themselves as programmers. Indeed, many of them fall so in love that they cease to be programmers and instead travel the land as disciples of their chosen methodology, spreading the good word to hapless other teams, who in turn become infected with the Scrum/Kanban meme.
That these practices are so very easy to learn is what makes them so virulent. And, if done right, they do help. They help a lot. There's no questioning that.
But if you are churning out crappy unclean code, they don't. Agile relies on code being easier to change. If it is complicated, riddled with duplication and unmanaged dependencies, lacking regression test assurance and basically cobbled together under the relentless pressure of a Scrum or Kanban drumbeat (Kanban's beat sounding a bit more like free-form jazz, obviously), teams will inevitably hit the barrier of increasing software "viscosity" and all their brilliant planning and tracking will just reveal for all to see how quickly productivity is slowing down.
You cannot deliver a continuous stream of anything if your bad habits keep clogging up the pipes.
So clean code is a prerequisite of Agile project management. Teams must focus 90%+ of their effort on to delivering higher quality code, and not waste their time obsessing about whether they should estimate using Fibonacci numbers in their Planning Poker sessions or what colour index cards they should use for reporting bugs.
I'm not saying these things aren't important. But they are practically trivial and easy to master, and they'll mean diddly-squat if you aren't keeping a very tight reign on code quality.
There. I've said it.
Posted 21 hours, 55 minutes ago on November 10, 2009