Sunday, February 20, 2005

MSF for Agile Software Development

My colleague Randy Miller finally got the second draft of his new agile process out the door. We’ve created a new space at MSDN to house it and the debate around it. Go check it out.  I’d encourage you to download it. Take a look. Please provide all the feedback you have the energy to supply. We’ll have another rev of this before the product ships later this year. So here is your chance to have an influence on Microsoft’s agile offering.

Today, I presented the newly named MSF for Agile Software Development at Web Services Edge. At this conference, Visual Studio Team System was being shown everywhere. Before my presentation, there was a two-hour .Net mini-tutorial where the latest modeling capabilities were shown in a live demo. We also had machines set up in the exhibit hall so that conference goers could try it out for themselves.

Our new modeling diagrams, the logical datacenter, system, application, and class diagrams, really make building web services much easier. Not only are the code and the models synchronized, the logical datacenter diagram validates new web services against the deployment environment. The folks in the Whitehorse group, I mean, Visual Studio Team Architect group have really done a nice job.

Sunday, August 29, 2004

Microsoft Betas Agile Process

Microsoft is releasing an agile flavor of the forthcoming MSF V4.0. Download a sneak preview from this GotDotNet Workspaces site. [You need a Microsoft Passport to get in and you may need to be logged in to passport before you select the link to be successful].

Friday, May 14, 2004

Elevating the Role of Tester

A good post yesterday by Keith Ray, pointing at other writing by Johanna Rothman, about the role of testers on agile projects. What I like best about the trend towards test first and automated testing is the elevation of testing as a profession. Now testers are developers just like the product developers. They need the same skill set and they often get paid on the same pay scale. This blunts the snooty high nosed view that some developers hold towards testers. I even worked for guy a year or two ago who believed that no one really wanted to be a tester and that is why we had high turnover in our test department. He said, “All testers are wannabe developers”. How sad is that?

There is another hidden benefit to having real development skills on the QA team - it makes developers and testers interchangeable. This is fantastic for dealing with bottlenecks in a process and providing a flexible workforce which can respond to change. Agile test methods lead to more agile development organizations and that’s great!

Monday, April 12, 2004

Agile Project Management

 Jim Highsmith‘s new book has just been published. From the back cover…

<!—StartFragment—>One of the field’s leading experts brings together all the knowledge and resources you need to use APM in your next project. Jim Highsmith shows why APM should be in every manager’s toolkit, thoroughly addressing the questions project managers raise about Agile approaches. He systematically introduces the five-phase APM framework, then presents specific, proven tools for every project participant.

You can purchase  Agile Project Management  through my affiliate link with InformIT for a stunning 30% discount. Buy it now!

Saturday, December 13, 2003

Chapter 6 - Agile Project Management

Chapter 6 revisits a theme from Chapter 4, the main variables of scope, budget and schedule, and examines how traditional software engineering methods choose a different constraint than Agile or RAD methods. Traditional SDLC methods fix the scope and allow the budget and schedule to vary. They define “quality” as conformance to scope delivery. This choice is rooted in the project management methods of the PMI and is indelibly fixed into the SEI SW-CMM (capability maturity model) and the definition of ISO 9000-13 software development quality assurance. Agile and RAD methods fix the delivery date and allow the budget and scope to vary.

The Agile choice is the better choice and Chapter 4 explained why - the scope has much greater uncertainty than either the budget or a date. In fact as sure as the Sun rises, any date chosen will arrive. Dates are absolutely certain. What is unknown is how much functionality can be delivered by that date. The Traditional method of fixing the scope means that the variable with the greatest uncertainty is set as the mark by which quality is measured. This inevitably means that any estimates of delivery date and budget based on a fixed scope have a high margin of error. Error on the high side is failure under ISO 9000 standard and CMM quality definitions.

Next, Chapter 6 looks at the effect of cost accounting and its focus on tracking effort expended and value-added. This leads to the false security of recording work-in-progress as an asset. This is somewhat of a historical perspective as, at least in the United States, it is no longer normal practice to capitalize intangibles such as software development in-progress. However, even as recently as 3 years ago, this was common - particularly in high technology companies which were losing money. Recording WIP on the balance sheet takes it out of the P&L and makes the loss look lower.

Throughput Accounting assigns all costs incurred in software development to OE (operating expense) whilst only recording value-added on completion and delivery. Hence, value is only recorded at two points - the input and the output. There is no value-added for partially completed work.

When you start to measure things this way, it naturally leads to a different way of tracking projects - tracking the flow of value. This is a concept from Lean Production and really it isn’t a commonly accepted project management concept at all. The notion of using it for Agile project management was floated academically by Koskela and Howell in the paper, The Underlying Theory of Project Management is Obsolete published in 2002 by the Project Management Institute.

I recognized this proposal as reflecting how FDD projects are managed. With a slight tweaking of the FDD Feature Complete graph, to use the Lean Production reporting tool of Cumulative Flow Diagrams (CFD), as I described at in this article at the FDD website, it can be shown that Agile software methods were already employing the technique advocated by Koskela and Howell. CFDs had been advocated by Donald Reinertsen in his 1997 book Managing the Design Factory as the ideal method for tracking the flow of added information during a design process. As software development is an information discovery, knowledge work endeavor, it seemed only natural that CFDs were the correct choice.