Is Ken Schwaber libeling me here in the Scrum Yahoo group? You decide!

MSF for Agile Software Development was mostly authored by Randy Miller but I contributed. People like Ward Cunningham and Jim Newkirk reviewed it. Is Ken libeling us all?

I'd like to pick Ken's post apart line by line...

It defines roles within the development team, so it isn't cross-functional.

This isn't true. MSF has the Team Model which is completely cross-functional. In fact, the MSF Team Model includes the full lifecycle including deployment, support and operations and as such is more comprehensive than any agile method I've seen.

It tells the team what to do, so it misses self-management.

On this point, Ken is correct. MSF for Agile Software Development was developed as an "agile for the rest of us." It was intended for adoption in mid-market IT departments that were previously unwilling to adopt agile methods. It was designed for organizations where there isn't sufficient trust to have extreme agile methods or where there isn't a critical mass of top developers who will maintain the self-discipline that extreme agile methods require. The replacement for complete trust and self-discipline is prescription.

In addition, MSF for Agile Software Development supports the most advanced software development environment ever offered to the community. The process is designed to educate the community on the features in the product and teach them how to use those features. To do this, it is necessary to describe processes and procedures of use. It is necessary to provide prescriptions of use.

It defines what steps to take, so it isn't empirical.

Ken clearly uses a different version of the English dictionary from me. I don't understand what prescription has to do with empirical observation. If he is implying that a defined process can't work for an empirical problem then this is just plane wrong. It is perfectly reasonable to define a system that adapts for empirical observation. Anyone who ever studied the design of central heating controllers or operational amplifiers knows this.

It has increments that aren't potentially shippable, so it isn't lean.

This is simply not true. It also shows a lack of understanding of batching processes in lean manufacturing. MSF encourages shippable code and shippable releases - at least with a daily build and with small iteration sizes of 2 to 6 weeks. However, MSF also recognizes that enterprise scale software development necessitates integration layers and batches of work (iterations) that might need to be merged with others before they are releasable. This is the working reality for many of us solving the enterprise scale agility problems every day.

Lots of artifacts and no emerging list of requirements and architecture, so it is wasteful and not lean/agile.

Again, this simply isn't true. There are actually very few artifacts in MSF for Agile Software Development and those that do exist are clearly not waste. Is a Persona definition waste? Is a usage Scenario, for that persona, waste? Is a deployment architecture diagram waste? Is an application system diagram, waste? Actually, I'd claim that the Team Architect features that allow the modeling of mock deployments represent poka-yoke in Lean terms. I personally feel that Ken's comments show that he is out of touch with modern approaches to software architecture and system development tools.

MSF Agile was developed by several people that have aren't very practiced in Agile working with EDS and Accenture, neither of which have any experience in Agile. They appear to have read the manifesto and seen how they could shoehorn their old waterfall processes into it so they could call it Agile. It is a disgrace to those who were engaged in this activity, and to our profession.

There really isn't much to say about this paragraph. I think you, as readers of this website, are better placed to decide. You've read my work over the years. You've seen my contributions to the literature. You've read my published results on productivity, quality and team development. You choose - am I a disgrace? and do I insult our profession? Whom does this post by Ken reflect most poorly on? You decide!  Technorati tag: Agile, David+Anderson, Ken+Schwaber, MSF, Microsoft, Visual+Studio, Team+System, Randy+Miller, Ward+Cunningham, Jim+Newkirk

I left the house without my underwear this morning!

It's not unusual that I'm not wearing any underwear. 3 or 4 days per week, I bike to work. However, my underwear is usually safely stowed in my messenger bag, nestled in with my trousers and shirt in the main compartment separated from my office laptop. Safely stored ready for use when I emerge from the office shower room 30 minutes later.

However, today was different, I was half way to work, cranking a big gear down 15 Ave just passing the city pound (ah hem, animal shelter) when it hit me. Oh no, I forgot to pack something. Aaaaaggggghhhhh! Never mind, I had traffic to worry about. I'd made it to 2nd Ave in Belltown about 5 minutes from my office when I suddenly remembered my contingency plan. I had a packet of spare clothes stuffed in the back of my filing cabinet. In fact, this contingency plan had been in place for 2 years and the packet of clothes had moved offices with me from Microsoft to Corbis recently. The question to be answered was, "is there a pair of underpants in the packet?"

The original risk was identified as "what if I get soaking wet cycling to work and my clothes inside my rucksack get wet?" The mitigation was to store a spare set of clothes at the office. The contingency plan was to use those clothes in the event of a drenching. Now despite Seattle's reputation as rain city, it actually doesn't rain all that often. Indeed it was dry today. But I made another mistake. I was too sleepy and though I remembered to pack my workout clothes for my personal training session at the gym beside the office, I forgot something small but vital. Luckily, I was able to invoke the contingency plan for a similar risk with the same outcome.

Risk management doesn't need to be difficult. It's just a case of thinking through likely outcomes - errors that can occur, external variations out with your immediate control that can occur - and then mitigating them and putting in place suitable recovery plans - contingencies. Luckily for me, forethought 2 years earlier saved my blushes.

Now I just need to remember to replenish the filing cabinet before it happens again ;-) Technorati tag: Agile, David+Anderson, Project+Management

I've decided to triage my wardrobe! "Huh?" I hear you saying.

America is big. Things in America are big. Cars are big. Houses are big. Parking spaces are big. Burgers are big. Fries are bigger. And most of all spaces for hanging clothes are big. In fact, even in relatively densely populated coastal cities like Seattle walk-inn closets tend to big enough for a dad to swing a small child. The problem with this is that it is easy to keep shelving more and more clothes and never throw any out.

It's also really easy with approaching middle-age and fast growing children to let years go by and forget about wardrobe updates. Then one morning comes when you look in the mirror and realize you are dressed in clothes that pre-date your marriage. So, I've decided to triage my wardrobe.

When I was on my Asian tour recently I was surprised how often I had to explain the triage process for software projects. Typically, triage is held to process and prioritize bugs reported in system testing. However, with MSF we suggested that triage is a good process for sorting working queuing for development. In Team Foundation Server, MSF CMMI process template, there is a triage report that shows all the work item types such as requirement, change request, bug, issue, and risk queuing for prioritization. It seems that the meaning of triage is not widely understood. So, I thought I'd use my personal fashion disaster I call a wardrobe as way to explain it.

Triage is a process borrowed from medicine - initially, field emergency medicine. Triage is the process used to sort patients in an ER(A&E) room. The triage nurse examines the patient and decides whether they need: immediate attention; need attention but can wait until later; do not need attention (in a war time field hospital situation this usually means that they are beyond help.)

In software triage we seek to sort things in to three buckets too: things that need to be dealt with in the current iteration; things that can be postponed to a future iteration; and things that will not be dealt with (i.e. not fixed, not selected, rejected and so forth.)

In order to make the selection we need a set of criteria that can be applied consistently against each item in the backlog. At Microsoft, these criteria are described as a "bug bar."

So, when it comes to triaging my wardrobe, I need a set of criteria to process against the clothes hanging on the racks. So here is a first pass set of criteria...

• haven't worn the item for more than 2 years
• the item is older than 10 years
• the item is so out of fashion I can't imagine wearing it ever again
• the item is faulty or has developed wear or holes
• the item does not fit (I lost a lot of weight since I left Kansas City 5 years ago)

All items meeting at least one of these criteria will be placed in the third bucket - the one headed for a Salvation Army store.

• the item is out of season but not out of fashion

Summer clothes aren't needed now that fall (autumn) is with us. However, they can be "postponed" for use next summer. I'll sort these to the back. These represent the second bucket - clothes postponed for future wear.

That will leave me with the current fall/winter clothing. I can then do a gap analysis (against my unwritten requirements) on these and determine what I could do with buying to complete my new fall/winter wardrobe. Technorati tag: Agile, David+Anderson, Software+Engineering