Tuesday, December 13, 2005

MSF for Agile Software Development - You've Got To Be Kidding, Right?

Matt Davey pointed me at the MSF for Agile Software Development Beta. Damian Guy and I read through it - its a very good laugh! I would like to thank Microsoft for producing such a magnificent pre-Christmas spoof for our entertainment. I recommend it for your geek office party.

Hold on - maybe they're serious?? If so this is a real problem.

This is a terrible whitewash of the MSF product with an Agile brush for the purpose of marketing. The phrase which really rubs me the wrong way is in the Principles section of the Overview:
"This approach helps create an adaptive process that overcomes the boundary conditions of most agile software development processes while achieving the objectives set out in the vision of the project"
What the hell are you talking about? What boundary conditions? They don't define them anywhere. Is the boundary the need not to use the MSF product?

I cannot see much in here that would help you get any more Agile than you would be using normal development practices. Further a lot of the statements in here are non-sensical to an Agile ear, for example:
  • Under the Role>Developer>Fix A Bug>Step-By-Step it describes the process as fixing the bug THEN write the test to prove it works. Clearly the Agile practice of Test Driven didn't quite get through?
  • There is a section in the role>Developer>Implement A Development Task>Step-By-Step that describes doing a code review and says "Stay in the zero defect state". What? When do you not operate in a zero defect state?
  • The Role of Architect clearly describes a "big design up front" approach
  • It is very light on any Practice description - although a practice described in the "Pride of Workmanship" Mindset is "giving projects code names to clearly identify the project". Wow.
  • One of Damian's favourites is the diagram at the bottom of Overview>Team Model under the Scaling Down subtitle. This recommends which roles not to try to share in individuals if you scale the project down. It recommends not confusing people by combining the roles of Developer, Tester and User Experience. Errr...that's, like, completely opposite to most Agile thinking?
  • The Project Manager appears to be very busy estimating Scenarios, Development Tasks and Testing Tasks. Thankfully the MSF for Agile helpfully co-ordinates this into Microsoft Project so he can print out a Gannt chart for developers
  • The list goes on....
I thought Ken Schwaber's comments on this were very interesting, too.

This is an abuse of the Agile ideas for vending the same old tools and maintaining the same behaviorial practices. There is nothing in here about the practices you use to achieve valuing your people over your tools. There is nothing in here that would create a self-organizing complex adaptive Agile team.

If you're looking get the benefits of Agile Delivery, don't start with MSF for Agile.

They're using the words but not singing the tune.


At Tuesday, December 13, 2005 1:50:00 pm, Anonymous Anonymous said...

well you can't blame MSF for trying to exploit Agile, isn't that the Fenetx game to. Most place care little about people or tools, a sorry state of affairs but no less a reality. Why would any organasitioon care about creating a self-organizing complex adaptive Agile team. Where is the bottom line? At least MSF seem to understand this.

At Tuesday, December 13, 2005 2:08:00 pm, Blogger John S Nolan said...

'Exploit" is a key term here.

Finetix is investing in doing agile and selling the benefits to our clients: frequent rapid delivery, change your mind, control in your hands, etc. We're using Agile to act in a more professional manner by acknowledging that we need to behave differently to produce what our clients need.

MSF for Agile to me is an unethical use of the term Agile. There is no embodiment of behaving differently or acting more professionally over any other version of MSF.

I have never said that Agile is about organizations caring more about their people. Agile is partly about recognising the source of value in a software development effort comes from the people not from the tools.

Why care about a self-organizing complex adaptive team? Your business exists in a changing environment that you cannot predict. If you cannot predict, you cannot plan. Without planning what do you do? Adapt to the circumstances.

Agile is about how to build an adaptive team that can match the rate of change of your business environment. The bottom line is without an Agile delivery team (formally or informally) you are increasing your probability of failure through planning. And probably simultaneously wasting your companies resources.

At Tuesday, December 13, 2005 4:14:00 pm, Anonymous Anonymous said...

Have you ever personaly worked on a full blown Agile project at an investment bank? I very much doubt it, and also doubt that such a beast exists.

If the degree of uncertainty and inability to plan or predict was as great as you suggest then nothing would get done. Investment bank real world development often leaves a lot of blood on the carpet, and I would certainly agree we need to do better as a community, but this approach does get results.

Jumping on bandwagons is a fact of life, ethical or not, get over it and move on. Results are all that count.

At Tuesday, December 13, 2005 4:27:00 pm, Anonymous Nat said...

When evaluating Microsoft technologies and practices I always follow these rules of thumb, rules that I've learned through hard experience.

1) Never use any Microsoft technology that Microsoft themselves do not use to support their own business.

2) The quality of Microsoft technology decreases the further away it is from the hardware. This creates an exponential decrease in quality as a good underlying technology is used as the basis for a poor technology that holds up even worse technologies, in a teetering stack of cruft.

Microsoft's push into "Agile" follows the rule: Microsoft don't use MSF and VSTS internally, they don't follow Agile practices internally and Agile practices are at the very top of the technology stack, far far away from operating system kernels, virtual machines, compilers or graphics libraries. Therefore, don't follow their recommended practices or use their tools that purportedly support agile development.

At Tuesday, December 13, 2005 4:37:00 pm, Blogger John S Nolan said...

Yes, I have. And they do exist.

I have recently heard at least 3 senior people in 3 different banks ask the, "What is my IT department doing? We give them huge budgets and they fail to deliver what we need!". I put it to you that to the customers it looks like nothing is happening.

I agree that it is results that count, and I believe Agile is a better way to achieve results. But this MSF product is not a way of achieving the benefits.

I challenge your generalisation of the "real world investment banking" model. In my "real world" it is unneccessary for there to be blood-on-the-carpet because everyone gets things done together without wasting time on heroics. No less edgy, no less pacy - just more effective.

At Tuesday, December 13, 2005 5:23:00 pm, Anonymous Anonymous said...

I notice that the project roles are: Business Analyst, Project Manager, Architect, Developer, Tester and Release Manager.

Where's the Customer and User?

At Wednesday, December 14, 2005 12:01:00 pm, Anonymous Anonymous said...

(I am anonymous poster 1+2)

My experience differs from yours, so I guess we should agree where we do and move on elsewhere as we (particularly I) have drifted from the point of your post.

My experience has been that the kinds of comments you have recently received were commonplace in 2002/2003 and preceded a significant cut in IT spend. Today IT departments are much leaner and projects are only getting approved where there is measurable business benefit.

Investment banks aren’t people focused despite what they may say. They have tried dress down and chill out rooms, when key people were leaving for dot bombs, but a lot of this has now fallen by the wayside like other fads. I see engineering techniques of significant value in Agile that can be adopted in most banks today, but I personally doubt that many banks will change the people side of things to the extent that will allow the broader adoption of Agile that you advocate.

I strongly agree with Nat’s comment and would suggest that it extends to most organisations. If Fenetx are truly doing Agile and are able to sell it to the Investment Banking market beyond the short term then you are a lucky man my friend.


Post a Comment

<< Home