[This article first appeared in the Cutter IT Journal Volume 20, no.8, August 2007]

Stop Negotiating! No really! Cut it out! Banish it from your thoughts, your actions and your organization. Refuse to negotiate. When you need to work with another department, group or team inside your organization, and you find yourself in negotiations to get what you need, just say “Enough!” And refuse to negotiate.

[Download in PDF]

Co-authored with Merwan Mehta and David Raffo

Providing value to customers in software development through lean principles

Abstract

Lean thinking has created substantial benefits for a variety of industries. Although it is not easily apparent, the same principles can be utilized in reducing lead times for software development. Fundamentally, lean principles leverage the benefits of software engineering best practices to improve the work flow and the tactical management of the project. By managing the project more efficiently and reducing waste, tremendous performance benefits can be achieved.

This article seeks to present and articulate a number of key lean principles in the context of software development. The goal is to provide insight into practical strategies for making trade-offs between the core lean principles of providing the highest possible customer value, maximizing work flow, and eliminating waste in the context of specific real world software development situations. Copyright © 2008 John Wiley & Sons, Ltd.

On June 6th, Rick Garber and I presented a brief overview of our Kanban system for software engineering sustaining releases adopted on my team at Corbis. I'm making a PDF of the slides available for general download. This is very much a first attempt to explain and teach what we're doing to a wider audience. It should be read along with associated blog posts: Kanban in Action, My Approach At Corbis, Kanban Conversation , Six Month Review, April Fool With Meaning, Do you have your Sticky Buddy?.

Abstract

Given an executive directive to focus 10% of engineering resources on maintenance and upgrades through regular sustaining engineering releases of software systems, the Software Engineering Department promised it could deliver a release every 2 weeks. Initially, a traditional project management approach to define scope and schedule with a firm release date was adopted. The results were terrible – the process of gaining agreement on scope, cost estimates and release dates with management alone often took over 2 weeks and the process drained resources from other major projects...

The week before I left Microsoft I was due to give a webcast on Lean Project Management with VSTS and MSF. This was an update to a rather hurried presentation that I gave as the "vendor" talk at Agile 2006. Anyway, the webcast didn't happen for one reason or another. In the end, I partially presented the slides in a Channel 9 interview that should appear any day now. Here is the full presentation. This material shows how to do iteration planning and tracking, how to identify waste in the process, how to buffer for variation and how to gradually improve.

Download Lean Project Management slides [3MB PDF]

This week I presented a case study at the TOCICO conference in Barcelona. As part of the philosophy of the TOCICO is to make all the material on TOC available in the public domain, I am with permission sharing the paper and slide presentation with readers of Agile Management.

From Worst to Best in 9 Months - Implementing Drum-Buffer-Rope in Microsoft's IT Department

Abstract

This is a case study about implementing common sense changes where they were needed. It’s a story not about the brilliance of the Theory of Constraints (TOC) but rather TOC playing a role as permission giver, reinforcing the beliefs of a manager and encouraging him to do the right thing. It’s also a story about simplicity – making just a few simple changes, collecting less data, spending less time on overhead and bureaucracy and more on productive tasks... (read more)

Download the paper in PDF, From Worst to Best in 9 Months - Implementing Drum-Buffer-Rope in Microsoft's IT Department
Download the presentation slides in PDF (special download version without custom animation)

I have to congratulate the organizers of the PMInAction event - the PMI Orange County Chapter - for a 1st class event. It definitely wasn't Mickey Mouse despite the fact that we were hosted at the Anaheim Community College and the speakers were lodging at the Holiday Inn adjacent to Downtown Disney and right outside the Disneyland amusement park. Hal Macomber, Greg Howell and I had a hearty dinner at one of the Disneyland restaurants and talked agile and lean project management over a few margaritas. I thought that might be the best bit of the weekend but I was wrong.

You might ask, what is a conference for project managers run by project managers like? And the answer would be, well organized! If ever there was evidence to underscore Peter Drucker's observation that volunteer organizations have highly motivated people then this was such an event. I was picked up at the airport and dropped at my hotel. I was picked up at the hotel the next morning with my fellow speakers and delivered to the venue 10 minutes before breakfast officially opened. At the door of the venue I was met by my speaker liaison. He would then escort me, personally - the other speakers had their own liaison - to the speakers' ante room. Everything from my point of view ran like clock work. Meanwhile, I'm still getting a kick out of the idea that members received a PDU for their PMP to sit and hear me suggest that they stop estimating and start agile estimating.

Here are my slides for download...

Here is the paper and the presentation slides that I presented today at the Agile 2005 conference.

Download Stretching Agile to Fit CMMI Level 3 - the story of creating MSF for CMMI Process Improvement at Microsoft [Paper PDF 342K] [Presentation PDF 829K]

[Update: Dec 14th 2005. I got some review comments from Jon Gross at the SEI. I've incorporated most of Jon's comments and issued an updated version of the paper 1.6]

Here are my slides from the WSA QA SIG meeting last month. They represent an update and reworking of the presentation from the Seattle chapter of the ASQ last September. I'm getting beyond bullet points with these presentations. They are more and more just a set of talking points. So they are pretty hard to follow unless you were there to hear the words. I've been asked to write a paper on these slides which will be published in a management journal. That won't happen for about 6 months. When the paper is published I'll put it here too so that you can read the words that go with the pictures.

Thanks to everyone who came along to the meeting. You were a great audience with lots of good questions. I hope I didn't disappoint you.

Download Understanding Variation in Software Engineering [PDF 3.7 MBs]

I have another guest paper this month. This time from my good friend and colleague Daniel Vacanti. Dan has been facilitating lots of domain modeling sessions this past year. This expierence has shown him where there are holes in the literature and the teaching of Peter Coad's methods. This article is his first attempt to start plugging those holes.

Many times in modeling sessions, I've witnessed conversations degrade from a debate about the concepts in a domain into an argument over what color a class on the model should be. Rarely is this type of argument productive (or even correct!). An argument of this nature is really masking something deeper; namely that the model itself could be improved. I think it best to illustrate this point by way of example...

[Download DNC Red Herring: Arguing over Color in PDF 148K]

Finally, my slides from my presentation at the Seattle Chapter of the American Society for Quality from last September.

In this paper, I start to tie together several themes around the theory of variation. This is the beginnings of a Theory of Profound Knowledge approach to managing software engineering development and quality. Like most of my presentations, the slides are just talking points. You need to be in the room to hear the words. There isn't a paper for this presentation.

[Download Variation in Software Engineering 580KBytes in PDF]

(and XP is "rugby") by Brad Appleton

Download [FDD is Football-Driven Development in PDF 143KB]

On the agilemanagement YahooGroup in early December, Ron Jeffries posted a lengthy treatise describing his knowledge of FDD and where it seemed not very agile to him in numerous places

In part of it, he wrote:

1. So far, what you have been talking about lately sounds to me to be indistinguishable from waterfall: analyze, then design, then code. Yet we have heard over here here where I am that waterfall is not agile. There must be something in this discussion that either you're not saying or that I'm not getting. Please explain how the process uses and responds to change. To my aging ears "right first time" and "responding to change" don't sound the same at all.

I thought the exact same thing when I first heard FDD described by someone from Peter Coad's company (Tom Gullion of Togethersoft) and read the initial description from Chapters 6 of Peter Coad's book Java Modeling in Color with UML

I've had this article kicking around for almost 18 months. It delivers a real multi-project solution for Critical Chain. It's based on real experience at 4thpass/Motorola in Seattle where the user experience team acts as the overall system bottleneck. I submitted this article to a couple of serious journals. One in the US which rejected it quickly and another in the UK where it simply went in to a black hole. After all this time I feel it is more important just to get it out. Some people have said that the multi-project solution was missing from my book and that was an unacceptable oversight. So treat this article as Chapter 10.5 :-)

Abstract

UI Design and Usability Engineering can be fully scheduled into the program management activity of larger software development organization using Critical Chain Project Management (CCPM). The UI design group is used as the synchronizer in the CCPM multi-project solution and the throughput of UI design is used to regulate the flow (or velocity) of software development activities elsewhere in the organization. The work of the UI design group will be analyzed, scoped and estimated using the output from interaction design modeling with Visual Vocabulary or UML Statechart diagrams. The method can be used successfully with Agile software development methods such as Feature Driven Development (FDD). The UI design group is established as the managed constraint within the organization and the flow of value is regulated from the development of UI designs and specifications.

[Download Scheduling UI Design with Critical Chain Project Management in PDF 339KB]

Last month I presented a brief overview of my work, both recent material and the basic concepts which appear in the book, at the TOC ICO World Conference in Miami on October 25th. Both the paper and slides are now available. They will also be available from the TOC ICO website.

This material really represents all of my current and latest thinking collected into a single presentation. It includes more or less the entire first section from my book, plus my multi-project critical chain solution, my more recent material on managing with cumulative flow and my experiments with statistical process control and touches on how to use all of this in a Six Sigma solution.

Download the presentation [Feature Driven Development - towards a TOC, Lean and Six Sigma Solution for Software Engineering in PDF 1,108KB]
Download the paper [Feature Driven Development - towards a TOC, Lean and Six Sigma Solution for Software Engineering in PDF 3,780KB]

I planned to re-run my ChAD and Agile Scotland slides about The Coad Method's Contribution to Agile at the Seattle Java Users Group. However, the talk went so well and there were so many questions that I added an additional set of slides on Feature Driven Development and its Knowledge Management System and reporting mechanisms.

These slides really represent the state of the art in The Coad Method and FDD as it is practiced in North America in 2004. Domain modeling in color is an essential part of the process, earned value reporting is replaced with cumulative flow diagrams and daily standup meetings are a part of the regular routine and replace the weekly secretarial meeting in the original FDD documentation.

[Download the slides in PDF]

Cumulative Flow Diagrams provide a method for tracking progress of agile projects in a "burn up" fashion. Because they plot both the total scope and the progress of individual Features / Stories / Tasks / Functions / Use Cases they communicate absolute progress whilst visually providing a proportional message of total completeness. CFDs also offer us a simple method of tracking work-in-progress and visually analyzing the trend in lead time for delivery of working code. They provide a leading metric which allows teams and managers to react early to growing problems wherever they might appear in the flow between requirements and working code. CFDs provide transparency into the whole lifecycle. Tracking a project with a CFD is a key element in moving to a Lean system for software development.

[Download the full paper in PDF]
[Download the presentation slides in PDF]

In 1999, Peter Coad introduced the concept of using colors to signify archetypal behavior for UML classes in a domain (or business) model [Coad 1999]. He went further and suggested that the colored archetypal classes typically formed a pattern which he dubbed the Domain Neutral Component (DNC). Color modeling was the culmination of over a decade of work in object-oriented theory for Peter Coad. Throughout those years, he had been seeking methods to enable the building of  "frequent, tangible, working results". Modeling and its derivative – code re-use – were at the heart of his attempt to create a truly agile method for software engineering This paper will present some of the history of domain modeling in color and the DNC with a brief explanation of its origins and effectiveness. A five year update on the technique will follow. It will show that the DNC provides a strong and robust architecture which withstands change with minimal refactoring and minimal regression effect across the rest of the model. This is the essence of enabling agility with object-oriented functional architecture – a fast, reliable, elegant modeling technique which maps directly to implementable code whilst gracefully accepting change even late in the development cycle.

[Download the full paper in PDF]
[Download the presentation slides in PDF]

This paper first appeared in the July 2004 edition of The Cutter IT Journal. It replaces Chapter 8 "The Agile Manager's New Work" from Agile Management for Software Engineering. This new writing, effectively a second edition of the original chapter, incorporates some newer thinking in Statistical Process Control and Six Sigma which first appeared as concepts in Chapter 32 "States of Control and Reducing Variation."

Abstract

In Agile Management for Software Engineering [Anderson 2003], I introduced the idea that there are four roles for managers of agile projects and that all four roles have to be filled before a software engineering team can reach its agile potential. The names of the four roles were not new - product manager, program manager, project manager, and engineering manager - but their responsibilities were carefully defined to maximize the agile potential of the organization. Although they were described as roles and in theory one manager might be capable of filling all four, the reality is that each of them requires different skills. Hence, there is room for specialization, and it is unlikely that any one person will be good at two or more of the roles.

This article provides a definition of each role and explains why the separation of roles and responsibilities makes sense. The explanation is founded in a combination of management theories for continuous improvement, including the theory of constraints [Goldratt 1984, 1997], statistical process control [Wheeler 1992] and some derivative work in quality assurance by Edwards Deming, all of which provided the underlying theory for Six Sigma.

Download The Four Roles of Agile Management [PDF 2,234KB]

The third and final of the teasers for my forthcoming paper at Borcon on Advanced Domain Modeling is titled "Coarse Grained Components from a Color Model." Again its getting very mixed ratings. I wonder why this is? Are the low ratings from people who have no idea what color modeling is all about and haven't followed Stephen Palmer's column at The Coad Letter over the years, or are they people who love color modeling and are resistant to change and new material being published? Hmmm....

I personally feel that this article is one of the more important papers I will publish this year (or any year) as it lays the groundwork for how to use domain modeling as the basis for service oriented architecture and it shows how to use a bottom-up domain modeling approach to provide a Lean postponed decision on the selection of components. This reduces change and variation in interface design and makes development run more smoothly.

[Download "Coarse Grained Components from a Color Model" in PDF]

I gave the following paper at Motorola's internal S3S conference on July 12th. It doesn't contain anything which is Motorola proprietary, nor do I work for Motorola and hence I'm sharing it with a wider audience. The paper was originally titled, "Transparency, Alignment, Productivity and Governance" but was re-titled "Making the Business Case for Agile Management" on the advice of the conference organizers.

Making the Business Case for Agile Management
- Simplifying the Complex System of Software Engineering

ABSTRACT

Management in this first decade of the 21st Century faces a new set of challenges. Companies must be more competitive whilst at the same time insuring better governance, better alignment with shareholder interests and more transparency into processes and across value chains. Only by achieving all 4 of these goals will companies deliver World class performance. Software engineering has traditionally been very arcane and opaque. Productivity has often failed to meet desirable goals whilst governance and fair and proper allocation of resources has been difficult to achieve. Metrics such as Lines of Code have failed to provide alignment with value creation and shareholder interests whilst transparency of reporting has been a constant challenge. Agile Management seeks to make a paradigm shifting change in the approach to management of software engineering using best practices in management science including the true definition of value, the concept of a value chain, systems thinking and a focus on quality through an understanding of variation. These methods offer the possibility to understand the complex system of software engineering, to identify the leverage points and the correct metrics for measuring and reporting them. By simplifying the rules with which we govern software engineering activity and aligning it with existing management science, it is possible to deliver World class performance and meet all of the 21st Century challenges of transparency, alignment, productivity and governance. The Theory of Constraints offers a framework for simplification and identification of the leverage points and Throughput Accounting offers a method of reporting and decision making for good governance. Statistical Process Control and a deep understanding of variation offer the possibility to adapt “Six Sigma” for software engineering, ultimately permitting us to use quality as a competitive weapon. Agile management for software engineering tracks the flow of client-valued functionality, where value is defined as design information and value-added is the reduction of uncertainty leading to perfect information in the form of working code which passes quality assurance tests. Bottlenecks can be identified by monitoring the cumulative flow through the system and continuous improvement can be achieved through investment in the bottleneck. Agile software development and project management methods demonstrate the attributes of best practice in management science and can deliver all 4 goals of transparency, alignment, productivity and governance. Feature Driven Development is explained as an example of an agile method which exhibits the desired characteristics.

Download the Paper [PDF format 2,703K]
Download the Slides [PDF format 682K]

Recently I gave a talk at the Chicago Agile Developers group and Agile Scotland (in Edinburgh). The presentation was more or less the same with minor variation. Attendees may find these slides useful [PDF 1,1169K]

The second in my series of Coad Letter's from my forthcoming paper on managing project health using cumulative flow diagrams for the Borland Developer Conference this September has appeared at BDN, The S-Curve Explained.

Introduction

In my previous Coad Letter [Anderson 2004], I described how a plot of Features completing - an earned value plot of an agile project - typically displays an S-curve shape. With this edition I'd like to provide some more insight as to what causes the S-curve effect and how managers can minimize the effect it has on the overall project delivery by paying attention to just a few areas at the beginning and end of a project.

The S-Curve

The figure shows the ideal maximum production rate - the natural limit for the development group. There are good reasons why this optimal productivity can't be achieved immediately and why it drops off towards the end of the project. Let's look at the bottom and top of the s-curve separately. This material also appears in Chapter 9 of "Agile Management for Software Engineering" [Anderson 2003].

The first of a new series of Coad Letter's has been published at the Borland Developer Network - Using Cumulative Flow Diagrams. This is one of several which make up the content of two papers I'll be giving at the Borland Developer Conference in September.

Introduction

Agile software development methods such as Scrum and Feature Driven Development manage and report project progress in a very different manner than traditional critical path project management. Scrum started with the use of a "burn down" chart which plotted the estimated number of hours remaining to complete the Sprint backlog. More recently "burn up" charts have become popular. These plot the number of completed Stories, Tasks or Features on the project with a projected completion target. It is possible to extrapolate the plot with a trend line to estimate the completion date of a project.

The concept of a "burn up" chart had been used in Feature Driven Development since its inception in the late 1990's. It's called a Feature Complete Graph as shown here.

I first gave this paper at a Sprint Object Oriented Users Group conference in 2000. It was presented at 3 venues in Dallas, TX, Kansas City, MO and Reston, VA. It gives an outline history of the decade or so it took Peter Coad to develop the Domain Modeling in Color technique between 1992 when he first documented his Item-Item Description pattern through to 1999 with the publication of the Domain Neutral Component.

Better Business Logic Faster [PDF 840K]

Here are the slides I presented at the Barry Boehm's Annual Research Review for the USC Center for Software Engineering in Los Angeles, CA this week. I participated in a panel session on agile experiences but chose to focus my slides as a position statement for the workshop the following day. Hence, these slides focus mainly on what has been on my mind recently - since I wrote the book.

Critical Factors for Success [PDF 146K]

This presentation was first delivered through my former employer's internal university earlier in 2004. There has been such a heavy demand for access to the slides that I am making an updated version available through this site.

Agile Management for Software Engineering - a Brief Overview [PDF 301K]

Four of my recent blog entries [1, 2, 3, 4] grow up to become an article at the Borland Developer Network in my latest Coad Letter #118: The Case For Class Ownership.

Feature Driven Development (FDD) [Coad 1999, Palmer 2002] believes in class ownership - the notion that a single named developer (and perhaps a secondary deputy) is selected to "own" a class. Only that developer will write code in that class. This creates a constraint and a potential bottleneck. Other agile methods do not believe in class ownership. Class ownership is a deliberate choice. In the language of the Theory of Constraints [Goldratt 1990], it is a policy constraint. FDD has chosen to adopt class ownership as a constraint, whilst other methods have chosen to eliminate it by abolishing such a policy and allowing any developer to make the necessary changes in any class. On first observation, the elimination of a policy constraint such as class ownership would appear to allow development to happen faster and for development work to flow more easily. The decision to adopt class ownership was not made lightly and its continued use after almost 7 years of FDD is worth discussing. Class ownership is a choice. It is for individual managers to decide whether that choice is right for them and their organization. With this article, I hope to illuminate some of the reasons why FDD practitioners believe that class ownership makes sense.

[Download in PDF ...]

The first Coad Letter in my official Agile Management column, The Zen of Agile Management, has been published at the Borland Developer Network. Here is a brief extract...

Agile management is about management science applied to software engineering. Agile management is a minimal, lightweight approach to management. It uses a hands-off style. Agile management is highly delegated and provides empowerment at all levels. An agile manager should be empowered, his team leads should be empowered but above all developers and testers doing the real work should be empowered.

[Download in PDF...]

From the Proceedings of ForUse2003, here is the paper I co-presented at the conference.

"Lean Interaction Design and Implementation: Using Statecharts with Feature Driven Development"

Abstract

Lean UI development in Feature Driven Development is achieved through right-first-time implementation of the interaction designer's intent using David Harel's Statechart notation to model the interaction design. Statechart notation can be directly mapped to an MVC Type-II architecture and Mediator Pattern. With a few minor extensions Statechart notation can be used to model complex application behavior such as exception handling and transactions. Statecharts can be mapped into UI Features for tracking using an FDD Knowledge Base. The Statechart can be drawn using a UML modeling tool, and imported into the JStateMachine engine which implements a table driven Mediator and Command pattern system in either a Web Servlet or JFC (Swing) environment. The result is reduced variation in UI development and precise implementation of the interaction designer's intent. JStateMachine (an application framework) validates the runtime code against the original interaction model insuring accurate runtime implementation of the UI design.

[Download in PDF]

My first ever Coad Letter, Morning Roll Call. I have added it to this site for historic purposes.

Morning Roll Call was initially used as a process for recovery because the FDD Features Complete metric was suggesting that the project was going to be late. It served the purpose of keeping people honest and making them accountable for their work. They had to stand in front of their colleagues each morning, look them in the eye, and state how they were getting along with their piece. The process was stopped about two weeks after the hand over to System Test, as the bug count dropped off and the work on the project wound down.