Pages

Tuesday, September 4, 2012

The Best Agile Methodology

I've been developing software for 18 years now, and I've been doing it in different agile ways for the last six years. Starting off with just having a daily stand up and soon after adding more of Scrum until we did the whole package. Later I have tried both XP and Kanban too, but none of them appear to be the perfect fit for me in my daily work. A year ago I read Crystal Clear by Alistair Cockburn and thought that might be what I was looking for... it was just that I wasn't sure how to fit the roles with my organization, so I dropped Alistair an email to get some guidance.

He's response was right on for me. He basically said that Crystal Clear is dead and pointed me to an article of his called "The end of methodology". Instead of trying to buy in on a whole package you should have a toolbox of good practices that you use to build the best methodology for your team in your current project with your current stakeholders. There's no way any off the shelf product will be the best choice, and most agile methodologies aren't even comprehensive enough to be called a methodology - it's just a set of practices that you need to complement with other practices to run a project.

That being said there are a few practices I'll never leave out.

First is the story. Be it a user story or a light version or even a use case, but something that explains the functionality we desire in words that make it valuable for the stakeholders. And then make that story 100 % done before going to the next feature. This is where I've had most problems before going Agile. Sitting with a project that is almost done in every single end and then having months of work just tying it all up.

Second is priority. That's really the essence of agile: Do what's most important first. If you do it in sprints, if you have burndown charts, if you code test first, if you have continuous integration - its all "processes and tools" and something we should value less. For every new story you start, ask if that's the most important thing to do - if this would be the choice if only thing could be added to what we already have.

Third is the retrospective meeting. Without that we won't achieve the continuous improvement that makes the process ever better. This is where problems are brought to surface so we can do something about them and make our team gel. This is also, not to forget, where we can scratch each others backs about all the good things we do, making the team gel even more.

Fourth is the demo. This is the developers moment of pride, and the product owners opportunity to make sure the assignment was carried out properly. Two good things make a right! Even a small bug fix may be understood incorrectly by the developer and it's a lot better to find it now than after the release. It's also a thousand times more time efficient to show what's been done and get immediate feedback that can be addressed and discussed than to just send over the software and wait for an email with comments. And if that isn't enough you should also see it as an opportunity to read each others satisfaction level.

And finally the fifth, and that's the stand up meeting. If it is a low pace project it might be enough with a weekly stand up, but most projects benefit from a daily stand up. But remember to keep it brief! This is not the time or place to discuss designs or what you did last night. Also make sure everyone shows up, and that they show up on time. And remember, this meeting is for the production team to coordinate today's work and bring up immediate problems, not a status meeting to report progress to the project manager.

That will set you up with a good base that is useful in every project! Then you'll probably add a number of different other practicies, patterns and tools that you should have in your toolbox. You find them in XP, Scrum, Kanban, Crystal Clear and other methodologies and apply them as you see fit. You can also find treasures to add outside the methodologies, like the Pomodoro Technique for example. Then you'll have The Best Agile Methodology - tailor made for you and your context!

Best of luck, and I would love if you took some time to comment my post!

About Me

I've worked with software development since 1994. Desktop applications, web applications and real time embedded software have all been part of my profession through the years. Since 2007 I've had an enormous interest in methodology, trying out plenty of agile practices and read tons of books and blogs on the subject.