ScrumBut: The "Agile" Buzzwords

A normal day in the office. I tried to get more details for some stories from a product owner. Half an hour before lunch time a co-worker entered the room, we did some small talk and made an appointment to go for a walk'n'talk later.

Suddenly he wondered about the book on my desk: "Agile Retrospectives" by Esther Derby and Diana Larsen (http://bit.ly/cvoaH). He took a look at the back and read "Project retrospectives help your teams examine what went right--and what went wrong--on a project."

He instantly asked "Why is any new book called 'agile'? There are enough 'agile' books on the market. Is there any need for a book on retrospectives? Doing retrospectives is a common project management method, so what for do we need that 'agile' buzzword for retrospectives?"

In my point of view we need the 'agile' buzzword for everything we do! Why? Simply to intensify our agile project marketing. There are lots of stakeholders who still do not understand what it means being agile. We have to throw all that agile mumbo-jumbo around so that they get the chance to ask what we are talking about.

"We have to get higher quality, faster development, more features realized, so we will use a bunch of agile best practices. But whatever we are going to do, the most important thing is to control everything in a closed-meshed manner. And we need key performance figures."

The biggest ScrumBut in this quote is "use a bunch of agile best practices": do some planning poker here, take the name 'feature' from FDD, talk about Critical Chain project management, and write a 40 pages definition of those 'best practices'. Will such an approach have any chance for success? I doubt it.

Lets take a look at the other points of the quote. You want to control everything? Of course, you can, it's no problem at all: daily scrums, iteration reviews, and product demonstrations will assure controlling. You want figures? Just collect our agile metrics and you have them: velocity, burndowns, number of stories done, and so on. But what is the goal of controlling and collecting figures? We want to improve our team, our methods, our agility. The best way to improve is by implementing retrospectives the agile way (just read the book on my desk if you want to know more http://bit.ly/cvoaH).

Once a manager said: "Could you please stop talking about 'timeboxing'! This concept is so old and it's common sense to keep track of my project at least once a week. I don't want to hear that term 'timeboxing' any longer!"

"Timeboxing is not about frequent progress tracking, it's about fixed lengths of meetings and iterations. You even can timebox our release if we have to be date-driven. If story priorities change at the end of the timebox, some lower valued stories will just be moved into the next release", I replied.

"What do you mean 'moved into the next release'? You gave the promise to implement this set of features for this release at the planned date."

"You know reality. Project scopes change constantly, things may be decided to be more important this month and less important next month. Additional features are moved into a project and some other features get too large to be implemented at the proposed date. If your goal is to release twice a year, we have to timebox our releases to 6 months. This will guarantee a sustainable pace for the releases. If additional requirements get into a release, some other stories have to move to a later release. Otherwise we will not be able to guarantee a new release of the product every 6 months. Even worse: the succeeding release will be delayed before it ever started."

Somehow my last sentences opened his eyes at least a little. But that ScrumBut discussion has not been finished yet. I will report the results of our next discussions, of course.

The team leader of a group of developers once said: "we will not do iterations. That would be too many changes for the team, let's just do this feature driven-development now. If this works, maybe we can do some more."

This one is a heavy ScrumBut: do half of some agile method. Without iterations every other advantage of being agile gets lost completely. You would win nothing if you had to take a look at the project's results half a year later for the first time. Iterative planning and iterative retrospectives are so important that they must not be skipped by any means!


If you want to know more about ScrumButs, take a look at Ken Schwaber's site http://www.controlchaos.com/. Some interesting thoughts about ScrumButs can be found in http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html.