This past week I was putting the finishing touches to my paper for next month's Agile Conference in Denver. [You can hear me during the experience reports on Wednesday morning.] As I read the reviewers comments [I asked people inside Microsoft and members of the Yahoo! group to review the paper] I realized that there are two schools of thought on the topic of what agile is all about and neither of them match with the world view that we, on the MSF team at Microsoft, hold.
The first school thinks that agile is all about feedback loops. It's all small iterations in different shells from 15 minutes continuous integration to monthly sprint retrospectives. The second school of thought thinks that agile is all about people and treating people as human rather than fungible interchangeable engineering work stations. Both of these are important aspects of agile but for me they do not identify agile as unique.
Iterative and incremental development life cycle ideas have been around since the 1970's. Agile may have added some new tooling twists in recent years such as continuous integration but I don't believe this is enough to cite a unique differentiator. First of all, continuous integration isn't a facet of every agile method and it uses tooling and automation which some of the agile community at other times will tell you that you don't need. There is a bit of a double standard - tooling for testing and integration is OK, but tooling for project management is to some people, unacceptable - apparently it should all be on index cards and white boards.
Meanwhile, treating people as people isn't new either. It's 35 years since Jerry Weinberg published The Psychology of Computer Programming and 30 years since Fred Brooks' original Mythical Man Month article. So, much as the work of Alistair Cockburn and others, has highlighted the importance of treating people as people and realizing that psychology is the big factor in motivation and productivity, I don't feel that the people factor uniquely differentiates agile software development.
The factor that I feel is unique in comparison to earlier approaches is TRUST. Trust is the grease that takes the friction out of the software engineering economy. It's well documented that economies with high levels of trust generate the highest levels of growth and the greatest wealth for their participants. For example, the trust amongst Dutch merchants 2 and 3 hundred years ago, led to the greatest levels of trade going through cities like Amsterdam. This brought great wealth to Holland and established the Dutch Guilder as the World's reserve currency. Although there was some literature about the importance of trust in software engineering - Luke Homann's Journey of the Software Professional comes to mind - it wasn't a recognized aspect of the software engineering economy until agile methods put it front and center.
In developing MSF v4.0 in both its Agile Software Development and CMMI Process Improvement flavors, we've focused on the idea that high levels of trust were important for high productivity. We've focused on eliminating the waste in software engineering which comes from a lack of trust. [With the CMMI method, we still need to facilitate audits and appraisals but we've tried to automate as much of the evidence gathering using the tool as is possible within the specification.] Agile software development brought the idea of trust to the forefront. When there is trust, there is less waste, less extra work, less verification, less auditing, less paperwork, less meetings, less finger pointing, less blame-storming. Building trust between the engineering group and the customers is the first goal for any agile manager. Equally building trust with and amongst the engineering team is also essential. So many aspects of agile methods are about building trust - frequent delivery, focus on working code rather than documentation, face-to-face communication, pair programming, peer reviewing, stand-up meetings, shared responsibility and joint accountability, direct customer collaboration including on-site customers and customer involvement in modeling sessions, estimating, tracking and reporting based on customer valued functionality, information radiators, big visible charts, burndown, cumulative flow and ultimately complete transparency into entire engineering process. Agile for the first time, enables us to run software development like other parts of a business. It clears away the fog. It lifts the veil of secrecy. It blows away the opaque clouds and reveals the naked truth of what is really going on.
During the development of MSF v4.0, we've faced criticism from some quarters that Microsoft was misusing the "agile" term or misappropriating it, or seeking to reinvent it in its own image - Simon Evans provides one recent example. Nothing could be further from the truth. What we have done is create an agile method which addresses previously unsolved problems for typical IT departments. It's a full lifecycle agile method that gives responsibilities to a wider range of roles - roles typically found in IT departments. And with our CMMI method, we have stuck closely to our core agile process definition and stretched it to fit. We'll be releasing the Beta of MSF for CMMI Process Improvement on MSDN next weekend. Meanwhile, you can get the story of how we invented a full lifecycle agile method that is compatible with the CMMI, by coming to hear my presentation at the Agile conference. I hope to see you there.
