Tuesday, September 27, 2005

Why Estimates are Muda

I get a reputation as a Bad Boy of project management! My advice to stop estimating doesn’t go down too well with the traditional PM community. It doesn’t sit too well with some of my new friends in the traditional software engineering community either - their PSP/TSP method is based around estimating and tracking estimates against actuals. My dislike for earned value reporting isn’t too popular either - particularly as it’s mandated by the American government for certain types of contracts. [I’m not overly fond of Scrum burndown charts either - when they are based on time on task estimates rather than customer valued work items like user stories] My agile estimating technique based on velocity of client valued work items seems natural to me. It seems like the agile way. The simple, easy to calculate way. The doesn’t-waste-any-time way. And it’s this that I want to talk about today - doesn’t waste any time! Traditional estimating is muda! Agile estimating isn’t! Here is why…

Let’s assume that software development is the capacity constrained resource in our organization. It often is! Even if it isn’t we wouldn’t want to waste slack capacity which might otherwise be used to absorb variation elsewhere in our system. When we spend time estimating something, and we use the capacity constrained resources to do the estimating, we effectively lower our capacity. We lower the capacity on an activity which isn’t client valued. The customer doesn’t care how long your estimate for a task was. Doing the estimate often takes a significant chunk of the time compared to the time it would take to do the work. Doing the estimate even a few days but more likely a few weeks or months and in some cases years before the work is done means anything learned from the estimating process is lost. It gets worse. Often we estimate work which gets cut or doesn’t get done at all because the estimate is too large. Calculating a time on task estimate doesn’t create customer valued knowledge. Estimating is non-value added. Estimating is muda!

On the other hand, I thoroughly embrace the idea that we analyze and partition our problem space. In FDD, we analyze the work into a domain model and later partition it into components. We further analyze the work into Features and group them into Feature Sets and Subject Areas. All of this analysis work gives us a work breakdown structure which is entirely value added. All the work done analyzing the Feature Plan is value added. It creates knowledge which is used to deliver the customer valued functionality. We then estimate based on feature velocity. An agile estimating technique that takes almost no effort to calculate. Agile estimating based on analysis minimizes waste of capacity in the capacity constrained knowledge worker resources.

Just one more reason why agile methods deliver better economic returns than traditional software engineering and project management methods.

Sunday, September 25, 2005

Agile or CMMI

We [the MSF team at Microsoft] are getting asked a lot, how does someone choose between the MSF for Agile Software Development and the MSF for CMMI Process Improvement templates in Team System. We’ve decided to issue some guidance on this choice and will be including it in the final revisions of both process templates. This is a preview…

MSF for Agile Software Development, like all good agile methods, relies on people over process. MSF for CMMI Process Improvement introduces an agile approach to CMMI and has extended the guidance from MSF for Agile Software Development with additional formality, reviews, verification and audit. In this way, MSF for CMMI Process Improvement relies on process and conformance to process rather than relying purely on trust and the ability of the individual team members.

MSF for CMMI Process Improvement has an organization wide focus and scope and formalizes continuous improvement activities. MSF for CMMI Process Improvement provides a framework for objectively measuring continuous improvement based on the teachings of W. Edwards Deming. Choose MSF for CMMI Process Improvement if your organization seeks to build an environment and culture of quality assurance and continuous improvement.

MSF for Agile Software Development does include learning opportunities in the form of iteration retrospectives. Improvement relies on the people on the team and focuses on the project rather than the organization as a whole. MSF for Agile Software Development relies on tacit knowledge and experience of the team members. Choose MSF for Agile Software Development if reliance on the team and informal accumulation of improvement knowledge are appropriate for your context.

Saturday, September 17, 2005

Troubling Entries at Microsoft

Whilst the Economist chooses to sing the swan song for telecoms this week, Business Week decides to focus on Microsoft and the recent exits of some high profile employees. Whilst the piece contains many accurate facts, its presentation is rather one-sided. It doesn’t talk about some of us who’ve joined the company in recent years and why we might have done so. One accusation is that Microsoft isn’t innovating and that consequently it isn’t an exciting place to come and work. Well I’d like to analyze that from my own vantage point, sitting inside the Enterprise Framework and Tools product unit of the Developer Division.

From where I sit I see lots of innovation. In fact, I see a product unit which is leading the future of software engineering. With a team that includes Keith Short, Jack Greenfield, Steve Cook and Stuart Kent, (not to mention me), and with a vision to revolutionize the way software is developed, we are delivering on the company’s mission of enabling customers to realize their potential. It’s only two days since I listed the innovations in our MSF methodology. And I’ve got no doubt that this innovation is troubling our competitors. When you couple that to the Domain Specific Languages tool (Corona) launching next year and the longer term Software Factories vision, you have the most innovative and far reaching work in software engineering happening anywhere. If you were an undergraduate looking for a career in the future of software engineering, why would you want to work anywhere else?

There are around 30 million people working in this profession worldwide. They are amongst the highest paid people on the planet. By global standards of wealth and poverty, there is no such thing as a poor software engineer. The cost of software development is a major drain on the World’s economy. We develop software today with a similar craft model to how they developed automobiles in 1905. In EFT, we firmly believe that the software business has the same economic upside in the 21st Century that the automobile industry had in the 20th Century. That’s a 200 fold increase in productivity! With MSF, DSLs and Software Factories we’re leading that change and inventing that future.

One day, I think we’ll look back and see that innovation as important - others have already commented. If you can build software 20 or 50 or 200 times faster on the Microsoft platform, why would you look anywhere else for your technology solution?

[Update: Om Malik offers us some balance and points at Brad Feld who thinks 2006 is a good year for Microsoft and Paul Kedrosky rates the stock a buy. ]

POTS and PANS RIP

The Economist has finally written the obituary of the telecom business (sorry, E+ content) following the acquisition of Skype by eBay (more E+ content) this past week, which indicates that the cost of making a voice call is heading towards zero. The Horseman of the Telepocalypse is looking pretty smart have predicted this at least a couple of years ago. Yep, when the stupid network collides with the stupid old phone company the result is an implosion of the business model. How long before the stock price of POTS and PANS telecoms companies goes the same way?

Of course, we knew this back in 2000, when my team started to work on a future IP layer 7 strategy for Sprint, with Martin joining the team in early 2001. But the company that prided itself on innovations like the first nationwide fiber optic network wasn’t ready for the Internet revolution. The lack of willingness to embrace innovation saw both of us leave and ultimately, I got out of telecom altogether. Working in a loss making industry doomed to the history books, just isn’t fun. [See my next entry on why I don’t believe my new employer is either doomed or unable to innovate, despite what Business Week might be saying about it.]

What I’m wondering now is, does the failure of the trillion dollar telecom industry mean the end of 20th Century cost and management accounting? Is the model introduced Donaldson Brown at GM during the Alfred Sloan years now destined for the scrap heap?

What went wrong with telecoms? I dedicated a whole chapter of my book to describing what’s wrong with the telecoms financial model. EBIDTA = (ARPU - CCPU) x Number of Subscribers. Niklas Zennstrom of Skype agrees with me. He realizes that he doesn’t have a “cost per user” and that his model is to minimize revenue per user but to have lots of users. By snapping out of the telecom business model, Skype was able to think out of the box. Had Sprint been able to do this, I might still be there.

The cost accounting requirement to designate a “unit price” or “product cost” and determine a “product revenue” doomed the telecom business by boxing in its thinking and allowing others from outside to innovate them out of existence. Isn’t it time, we started to adopt the use of a management accounting model that thinks systemically rather than trying to optimize locally?

[If you’d like to understand this better, it’s explained chapter 17 of Agile Management for Software Engineering where I develop a system level accounting model for services] 

Thursday, September 15, 2005

Innovation in MSF v4.0

A couple of weeks ago I was presenting MSF v4.0 to a prospective customer. I got to the end of a 3 hour walkthrough and one of the audience threw me off balance with this comment, “it seems undifferentiated from [insert name of other popular methodology here].” I was taken aback by this. Yes, we might have 5 tracks (formerly known as phases in MSF v3.0) and yes some other rivals also have 5 phases. Hmmm. So we’re updating the MSF guidance to detail the many innovations we’re bringing not just to MSF and process guidance but to the field of software engineering. We truly believe that we are innovating with MSF v4.0 and beyond that we have a clear roadmap of further innovations for future versions. It will be at least a month before this material is available in a guidance download. Here is your first chance to see it.

(1) Separation of governance from capacity

MSF separates out the corporate and project governance for allocation of resources to projects and the value the project seeks to create, from the operational management of functional capacity, throughput and its variation.

Governance

Which projects should we do? Which features should be included in the product that project is producing? How much of our capacity should we allocate to this project? What’s the return on investment? How can we deliver value into the hands of customers early and often? These are all valid questions for good corporate and project governance? MSF makes these the responsibility of the product managers, project managers, the integrated project management office and senior management.

Capacity

Meanwhile, what’s the capacity of our development organization? Our test organization? Our user experience function? How can we increase that capacity? How can we maximize effectiveness of the function? What’s the variation in capacity and productivity? What causes that variation and how can it be minimized? These are all valid questions about the operational function of the organization. Functional structures are a fact of corporate life, because functional groups are efficient. Accordingly, MSF does not matrix everyone under a project manager or project director. MSF recognizes that capacity, productivity and its variation are important and functional managers have a role. That role is to maximize and increase capacity, and the reliability of that capacity through the reduction of variation. Reduction of variation includes improving quality to reduce capacity sucking rework and regression.

(2) Lean Project Management

Project management in MSF using Team System takes a Lean approach. The flow of value creation through a lifecycle of progressive functional steps is tracked and managed by monitoring the queue of work at each step. The Work Remaining report uses a cumulative flow chart developed for Lean Manufacturing. Work-in-progress and queuing can be monitored with this report in order to identify bottlenecks and address issues which are affecting throughput and reducing capacity.

(3) Trustworthy Transparency

MSF leverages Team System to track progress of work items and link that progress to check-in policies for artifacts stored under version control. The reporting in Team System provides transparency on progress. By tying the work item lifecycle to the control of artifacts in version control, Team System makes that transparency trustworthy. Metrics collection is friction-free, because it is a by-product of everyone’s work, not an overhead sucking capacity and producing waste. As the reports reflect the status of real work and faking the data would require tampering with real work - something that would be unacceptable to team members - the reports from Team System are both trustworthy and transparent.

MSF takes advantage of trustworthy transparency by focusing on the use of reports to drive objective, rational management decisions and interventions. MSF metrics have been selected to be simple, self-generating, relevant and leading (or predictive) indicators of project health. Trustworthy transparency leads to realistic schedules, reliable estimates, sustainable pace of work, and professional maturity rather than a reliance on heroic efforts.

(4) Qualities of Service

Too often non-functional requirements are second class citizens in project scope. Often they are added as an afterthought and they are treated in the “nice to have” category. MSF elevates non-functional requirements to first class citizens in the project scope through the definition of Quality of Service Requirements. For example, performance and security are not added as an afterthought, but are planned and scheduled from the beginning and developed into the product as recognized value within the required scope.

Qualities of Service can differentiate a product from its competitors. They can represent true customer value and defensible differentiation against competitors products. MSF requires that Qualities of Service are taken into account from the beginning and that systems are architected to deliver the required qualities of service from the beginning.

MSF leverages guidance from Microsoft’s Patterns and Practices Group to provide context-specific guidance on qualities of service, such as the incremental threat modeling method for security requirements, architecture and design. Through incorporation of incremental threat modeling, security requirements are treated as first class citizens in MSF.

(5) Constituency and Event-Driven Risk Management

Risk Management is not new, but the MSF approach is. MSF combines a day-to-day event-driven risk monitoring with the MSF Team Model, which treats risks as future special cause events with a probability and impact of occurrence.

The Team Model in MSF offers seven constituencies of risk concern - Product Management, Program Management, User Experience, Architecture, Development, Test, Release and Operations. Each of these constituencies must have at least one advocate to insure appropriate coverage of concerns to mitigate risk. Roles within MSF are mapped against Team Model constituencies as advocates.

Risks are future potential special cause events that might block productivity, reduce capacity and impact project schedules. They are identified based on prior data and experience from the advocates of each risk constituency. The probability of occurrence is weighed against the cost of mitigation and the impact of occurrence. Mitigation actions are then planned and managed to reduce the likelihood of occurrence and consequently reduce variation in capacity. The reduced variation, in turn, improves the reliability of delivery and improves competitiveness through shorter schedules.

(6) Continuous Adoption Curve - Agile through CMMI

By developing a Deming-based quality assurance approach to the CMMI and by incorporating all the guidance from MSF for Agile Software Development within that approach, MSF offers organizations a smooth adoption curve up the organizational process maturity ladder.

MSF for CMMI Process Improvement provides acceleration to CMMI Level 3 and provides a basis for progress to Level 4 and Level 5 with up to 35% coverage of practices at those higher levels. Future work in MSF will provide additional guidance on how to smoothly move to Level 5 and adopt the use of statistical process control with existing metrics and reports such as Velocity and Work Remaining. This leads to full implementation of Deming’s Theory of Profound Knowledge and his teaching of the avoidance of management mistakes #1 and #2.

MSF v4.0 is innovative and provides a clear roadmap of continued innovation in version 5.0.

(7) Situationally specific, context-driven project guidance

MSF understands that no one size fits all. MSF provides two process templates and a framework for process innovation that allows the process template to be readily customized for individual projects. Each project can run a separate version of a process, yet the metrics can be consolidated across all projects, regardless of process choice

In all cases, MSF adopts the use of concrete and specific methods for requirements solicitation and capture through the use of Personas and Scenarios. Unlike other methods which use abstractions and encourage analysts to get abstract early, MSF encourages the use of concrete examples through the lifecycle.

Concrete examples improve context throughout iterations and reduce the need for end-to-end traceability or for documentation explaining the meaning behind abstractions. MSF believes that concrete persona definitions and usage scenarios are more memorable for developers and testers. Concrete scenarios lead to better quality assurance than the use of abstractions, which often hide the true goals of the user from the developer or tester.

(8) Full Life Cycle Agile Methodology

Where many attempts to capture the spirit of the Manifesto for Agile Software Development in methodologies have focused purely on coding and testing, or iteration planning and issue management, MSF delivers a full lifecycle agile method with an expanded set of roles including business analyst and release manager. From creating the vision statement through to deployment of a working system, MSF for Agile Software Development describes the entire lifecycle for a project being undertaken in an agile fashion. MSF for CMMI Process Improvement incorporates MSF for Agile Software Development and hence both MSF v4.0 process guidance offerings deliver a full lifecycle agile methodology.