Agile Smagile

I love agile, I really do, for me it provides such a close cooperation between all parties involved in a project. I love agile pragmatists, people who know what to use when, and more importantly what won’t work for their specific environment, customer or company. These are people who see agile as a toolbox that provides a suite of tools that help you to deliver great software more frequently and better aligned to what your customers want.

However I really disagree with the pursists, delivery is not guaranteed based on the number of books you have read ( and can quote ) or the number of certificates you have, its based on how you apply the core tennets of agile at the appropriate time. You don’t need to follow Scrum, or DSDM, or XP or any of the others by the book, instead you need to know that each has its place, but none are the only solution.

Certification is diluted, every man and his dog has some form of certified agile this, and agile that, its time to talk about experience not paper. Certification should be seen as getting your papers to operate within an agile environment, its says you get it, you want to get it more and you want to operate under its guiding principals.

Where I work, we love Scrum, just about every project we deliver uses Scrum, but we don’t follow it religiously, for example, we have 2 week time boxed sprints but we release as soon as a feature is ready and by release I mean straight into production from the first day of the sprint, right the way through to the last day. When its ready it ships, we don’t hang around.

Sometimes ( shock horror ), Scrum doesn’t work for us, we have a large production system and sometimes we need to get a number of small changes out the door as quickly as possible, this is when we swap between Scrum and Kanban, and allow us to push features through the entire SDLC piece by piece.

In terms of development, TDD is great, its a major innovative step in software quality, but sometimes its hard. Its hard to learn, its hard to practice, but once your get it, personal and team productivity does soar. However sometimes people like to try an idea out, explore a concept, see if it works, if it doesn’t abandon it, if it does work then refactor it with tests to make it stronger. I get no greater thrill out of sitting down at a keyboard and trying to get an idea to work in code. I know and support the power of tests and refactoring, but sometimes ( just sometimes ) they get in the way until you really understand what it is you are trying to solve. Then the discipline kicks in and I can refactor then hell out of the code and build in quality with tests.

Agile is now so close to becoming mainstream its scary, but its still fragmented, and still too many high priests ( and their followers ) telling us their way is best, or jumping on the band wagon too late and telling us their re-interpretation of agile is best. Lets get back to the 4 key principles and make them work for you.



Iain McKenna


Nowhere in Scrum does it say you only have potentially shippable product at the end of the sprint and most of us who train on Scrum advocate limiting work in progress so that teams can release multiple times during the sprint, sort of like Kanban and indeed what you are doing.

I also agree that sometimes coding in a sandbox to try out ideas is useful and powerful.

In short, I think you’ll find that those with real proven experience in the CST community agree wholeheartedly with you 🙂


and in 5 lines you justify my entire post, clearly being a pragmatist you see the value of frequent releases, trouble you are still a minority case, too many people still think Scrum is delivery at end of sprint, instead of when then thing can release value.

Your email address will not be published. Required fields are marked *