Australian Scrum Community

There has been a good deal of uproar on the scrumdevelopment group over recent days regarding the way Microsoft is distorting Agile in the form of the Microsoft Solutions Framework for Agile Software Development product. Upon first glance, MSF Agile appears to include tools for Visual Studio reflecting a process invented by Microsoft that borrows a number of elements from Agile methods.

In response to the question “Is MSF for Agile Software Development really agile?” the relevant FAQ states:

Yes, we follow the “agile pattern” of defining iterations and scheduling work in a “just in time manner”. Development requires the more common practices such as unit testing and refactoring. We have some innovative techniques that provide alternatives to the common barriers to using an agile process such as pair programming and the on-site customer. This makes MSF more approachable for many projects.

Many of the posts on this topic are quite interesting but I found Ken Schwaber’s to be the most revealing. Ken delivers a concise but highly informative summation as to why he believes MSF Agile is not agile.

It defines roles within the development team, so it isn’t cross-functional. It tells the team what to do, so it misses self-management. It defines what steps to take, so it isn’t empirical. It has increments that aren’t potentially shippable, so it isn’t lean. Lots of artifacts and no emerging list of requirements and architecture, so it is wasteful and not lean/agile.

Some of the debate related to whether the Agile/Scrum community should defend the brand from such misuse. On this, Ken warns:

The biggest danger to Scrum and Agile is accommodation, and that is what is being done with MSF Agile.

Interestingly enough, Ken’s reasons for chooses to use ‘ugly’ terms such as Scrum, pig and chicken rather than using softer terms relates to the imperative to bring about change upon introducing Scrum.

I’ve been tempted to drop the Scrum words and adopt an ‘Agile’ vocabulary. I’ve decided against this because the ugly words of Scrum are the words of change … they stand out in their ugliness (chicken, pig, etc.) and are clearly not the old way. Agile, and words that are equally nice, are so easy to adopt and not change.

It seems that many organisations are adopting Scrum BUT... with a slew of variations. Perhaps continuing Andrew’s thread on how agilists need a good sense of humour, it turns out that someone at Microsoft has coined an amusing term for this: “Scrumbut”. See this blog post. Some of the examples of wayward practices there are truly awful.

Ken has some words of advice on bending Scrum…

If Scrum is being bent so that it can fit in without change occurring, bad news. In my experience, every time that a Scrum practice isn’t used, it is because it was exposing some dysfunction that people didn’t want exposed, didn’t want to deal with.

Finally, Ken relates an amusing annecdote: apparently Microsoft actually asked him to change Scrum to fit their tool!

I got a request for support from the MS Project group. They wanted me to work with them to change Scrum so it would work better with MS Project… I always thought that tools automated a process, not that a process reflected a tool so that it could continue making money!

So, I guess the moral is to remain sceptical of products from non-Agile specialists jumping in on the Agile bandwagon and to suggest to any colleagues – particularly any looking at MSF Agile – to do the same.