Have you ever discussed Agile with someone who said they were following an Agile methodology and then added a little “but”? They might have said something like “Yes, we are doing Scrum, but we don´t do stand-ups” or “Yes we use an Agile approach, but we have changed the length of our iterations to 10 weeks”. I certainly have and I’m not alone. Eric Gunnerson made the observation back in 2006 and wrote a great post on what he calls “Scrum-but”. I prefer the more generic “Agile-but” term, as the phenomena applies to Agile methodologies in general and not only to Scrum.
The problem with the Agile-but’s is, that if there are enough of them on a project, you can question whether the project is actually agile or not. To be extreme, would you consider at project that claimed to be doing Agile, but did all design and planning up-front, didn’t demonstrate to the customer, delivered only once at the end of the project and didn’t do stand-ups really to be doing Agile? I certainly wouldn’t – or at least I would argument that the project was far from realizing many of the potential benefits of an Agile approach. This example is of cause extreme and therefore the answer becomes obvious, but what about more gray zone cases?
The interesting question therefore becomes, how many and what Agile practices can you compromise and still get the benefits from doing Agile? The easy answer would be none and always stick to following a methodology (pick any) by the book. The problem with this approach is that it’s not very Agile. One of the fundamental principles in Agile is that every project and every team is different by nature and you therefore cannot predict up front exactly how the project will evolve. The applied methodology needs to be tailored from project to project, and maybe even more importantly, continuously as the project progresses and the conditions changes.
Turning the question of what Agile practices can be compromised around, I believe there half a dozen key practices that are core to Agile and which you should work hard to practice on every single project in all situations:
- Work toward a clear and commonly accepted vision.
- Let only the customer decide priority for any work item.
- Let only the team pick the items they can do in an iteration.
- Facilitate a daily stand-up and track progress using a simple visual indicator (e.g. a burn-down chart).
- Manage scope using a backlog – not by extending iterations or adding people.
- Demonstrate and release working deliverable at least once a month – including within the first 30 days.
Although there are many other great Agile practices you should consider applying dependent on the circumstances, the list above gives you a solid Agile foundation to start from. If you can apply these six practices without saying “but”, and that is not as easy as it sounds, then you have come a long way.
What practices do you think are not but-able? Please feel free to use the comments below as I would love to hear what practices are sacred to you.
This post is part of my republished collection. It was originally published in October 2008 on AgileThoughts and I have only made minor changes before republishing it.
Image credit: Unspash.com