Monday, February 27, 2006

The Red Beads of New York

So, the Apprentice is back on TV (now on Mondays). I’m sitting watching it now and thinking, “What would Deming have made of all this?” The scores were 40 versus 43. On the team that scored only 40 someone is about to be fired. They are now investigating the assignable cause variation (the root cause) of their failure so that they can finger the loser who will be fired. And yet, I can’t help feeling if only they had held the same game the next day that the result may well have been reversed. What’s missing from this picture is an understanding of variation. It’s the red beads all over again. Next day the other team might have paddled 43 red beads while the previous winners only managed 40. Without an understanding of variation lots of management energy is wasted looking for a cause that might be falsely identified. Changes are made but they may not make a difference. The process is repeated again and again, looking for a root cause that doesn’t exist. In the end, there is a winner but the losers are all great people who got unlucky. They just didn’t paddle enough beads.Technorati tag: Agile, David+Anderson, Apprentice

Thursday, February 23, 2006

Who’s calling FDD an Oxymoron?

Jim Brosseau suggests that agile methods built around a state model for work items are an oxymoron. Jim clearly isn’t familiar with FDD which has six states for its Features, namely, walkthrough, designed, design reviewed, coded, peer reviewed and unit tested, and promoted to build. However, even the simplest of processes have states for work items. Imagine an XP process with index cards for stories and the stories pinned to a notice board in three sections, namely, not started, in-progress, and complete. I simply can’t agree with Jim that state models and agile processes don’t mix.

Jim also suggests that Microsoft selected Agile and CMMI as the targets for MSF v4.0 from del.icio.us tags for the buzz they will create. Sorry, Jim, wrong again. Actually, we did market research with our real customers and they told us that what they wanted was either an Agile process or a CMMI process. We are actually responding to market demand.

Jim continues that, “<!—StartFragment—>building a generic CMMI process model for enforcing the development of software is like talking by building a sentence model around Webster’s Dictionary.” I’m guessing he hasn’t actually seen what we came up with. Because not only is our CMMI method perfectly viable as a workable process for software engineering, it is agile too, and innovative in how it demonstrates its ability to meet the appraisal requirements for a SCAMPI appraisal.

Jim, we’d be happy to have you come visit us at Building 25 on the Redmond campus, if you’d like to learn the facts.

[Disclosure: My employer put me up to it but the words are all mine.]Technorati tag: Agile, David+Anderson, FDD, MSF, CMMI

Blink I just Thin Sliced A Domain Model

Just when I’m not looking Brad Appleton goes and posts two very useful articles featuring Feature Driven Development and UML in Color Domain Modeling.

Brad talks about the idea that FDD doesn’t rely on tooling and sure it is true that FDD doesn’t need tooling to work but it wouldn’t be fair to say that it wasn’t designed for it. In August 1997, the team in Singapore became the first team to use Together. FDD didn’t exist. Jeff De Luca had his ideas on process and Peter Coad had the Coad Method. We were still inventing FDD. Together was a tool directly envisaged out of Peter’s work on The Coad Method. In 1997, it was beta 0.4 (arguably an alpha product). He realized that documents became obsolete and that maintaining them was a wasteful drag on the process. However, he believed in the communication power of the design language and we went on to prove just how powerful it could be when we introduced color to pick out archetypes (as they were to become known). Hence, a tool was needed and that tool had to keep the code and the model synchronized - Together.

A color model from my office in downtown Seattle, February 2004

The technique is so powerful that I have walked past the door of a room in our office building in Kansas City, where some of my team were conducting a modeling session (back in 2000), and in a split second from my peripheral vision have been able to determine that the model was flawed. I stopped, went back, put my head in the door and told them that though I was delighted to see them working collaboratively on the architecture, I had a few questions about the model. I was due in our VPs office (at the end of corridor) but I would be back in an hour. An hour later, I returned and proceeded to ask a series of questions, that led to significant changes in the model - had these not been caught at this stage they would have led to refactoring or rework later on. Proper color modeling leads to code that is robust to change. It absorbs change gracefully. Refactoring is not generally required. Several days later, Daniel Vacanti came to me and said, “You knew didn’t you? It wasn’t an accident? How did you know?” I replied simply, “The colors were wrong.”

Four years later Dan and I were now both living in Seattle and working together again. One morning he arrived in the office full of joy and proclaimed to me, “I can see the colors.” After 4 years of using the technique, he had reached the point of mastery, the point where he could truly teach the subject. He could see the power in the pattern of colors that we call the Domain Neutral Component. Since then, Dan has written articles like this one on arguments over colors and is now writing a book with me on the topic. Color modeling allows me to “thin slice” on a logical architecture. In the blink of an eye I can generally tell if an OO model is highly cohesive and loosely coupled. I just can’t imagine any code-based alternative that is so powerful. Sure, the code might be the whole truth but you simply can’t walk past the door of a room with the listing pasted to the wall and determine the coupling and cohesion of the model at a glance. Technorati tag: Agile, David+Anderson, FDD, Peter+Coad, Daniel+Vacanti, UML, Domain+Modeling

Assembly Line is the Wrong Metaphor for Software Development Process

Keith points out that William Pietri was referring only to assembly lines when discussing whether or not factories were a good model for software development process. I agree entirely, assembly lines are a bad metaphor for software development. There is no conflict with what I said yesterday and what William is saying. There is no correlation between an assembly line with its Takt time, constant flow and lack of variation (though the buffer for task variation is built in to the takt time), to the process of software engineering.

Seth suggested that the reason factories existed is that they relied on a single power source - a steam engine with a complex set of pulleys and gears - and hence all the workers needed to be together. I think that there are many more reasons. Distance creates time delays, it creates communication problems, it necessitates an increase in work-in-progress, it lengthens lead time, it increases costs and so forth. Even today puting everyone in the one room still makes sense - particularly for agile development.

Donald Reinertsen introduced the idea of a Design Factory in 1997. I picked up his ideas of managing the queues of “design in progress” and merged it with the Theory of Constraints in 2002. Mary Poppendieck has increasingly been talking about managing with queues since the Lean Design and Development conference in 2005. Leaders in the product design and software engineering process space believe that we can learn a lot from the way general purpose factories (not assembly lines) are managed. I stick by that conclusion. Technorati tag: Agile, David+Anderson, Glen+Alleman, Keith+Ray, Extreme+Programming, Software+Factory

Wednesday, February 22, 2006

Is Team System Changing Everything?

I’ve inspired Francis to the conclusion that Team System is going to have a revolutionary impact on businesses once they learn how to use the process and the reporting to change the way they manage software development and how the rest of the business interacts with it. Rob Caron wishes he’d been at SeaSPIN last Monday to see me present MSF for CMMI Process Improvement and he observes that what Francis is thinking occurred to him as the Team System Epiphany. I had the same thoughts in 2000 when I started managing a team at Sprint using Feature Driven Development. FDD’s Knowledge Management System (KMS) performed many of the functions of Team Foundation Server and I’ve been able to bring my experience using such tools and process to bear as we ready TFS for launch next month. I’ve been communicating to our Technical Specialists, sales and marketing, and our customers who visit for executive briefings that TFS and MSF give them an opportunity to change the way they run their business. If they embrace this chance then they will realize multiples in ROI compared to simply treating it as yet another developer tool.