The Declaration of Interdependence
| As the manifesto grew in significance, people asked
Jim Highsmith notes that to understand the agile manifesto for products at large instead of just software, simply replace the word product for the word software in the manifesto, and the manifesto is still clear and correct:
Indeed, this is evidenced by the myriad applications of the agile values and principles outside of software already discussed in this book. Reread, in particular, Mike Collins' sidebar (p. 323) to see how lean manufacturing already anticipated what we wanted to say. On the management side, a number of people voiced an interest in exploring the extension of the agile manifesto to project management and product development outside software. We held the first meeting to explore that topic at the Agile Development Conference in 2004. That group met twice more, finally on February 1, 2005, writing the six points of the Declaration of Interdependence, or DOI:
The signatories to the DOI were David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Polly-anna Pixton, Preston Smith, and Robert Wysocki. That list of people is notable for the breadth of expertise, ranging from project management to product development to agile software development to line management to teamwork specialist. Next, I elaborate on my thinking about this declaration. Understanding the DOIThe six sentences are formed as two clauses, "We accomplish this by doing that." In other words, you see us doing that, and the reason we care about that is because we're trying to set up this. Personally, I like to read the DOI in a two-column format, where the left column identifies what we're hoping to accomplish and the right column identifies how we intend to accomplish that. Consider it in this form:
The alert reader will notice that there is precious little about the Declaration that is unique to project management. The points apply across all management, even self-organizing and self-managing teams. If there is one problem with the DOI, it is that the six points sound like platitudes. Perhaps that is because, unlike the Agile Manifesto, the DOI doesn't name the bad guys. It states cause and effect relations. Only when trying to apply the points do the surprises show up. Here are some of the surprises lying in wait:
Lean manufacturing teaches us that a process improves as the batch sizes shrink (see "Lean Manufacturing at O.L. Tanner" on p. 323). When developing software, the unit of inventory is the unvalidated decision. Every written requirement, architectural decision or document, design drawing or decision, and piece of written code counts as inventory until it is integrated and tested! Shrinking each of these to a unit piece or continuous flow is a stretch goal to consider for software development. It implies that every decision, whether requirements, architecture, design, or code, must be implemented, integrated, and tested as a single unit. I'm not good enough to do that yet, but I do understand the importance of the goal.
Most managers manage tasks, checking task lists and task completion, when they should be managing the growth of value. In software development as well as in other fields, value accrues (or fails to accrue) suddenly, at the moment of integration. All the work leading up to that moment carries no value for the buyer. This is the reason agile teams have replaced the standard earned-value chart with burn-up charts showing accumulation of running, tested features (RTF), not just completion of tasks.
Shared ownership is difficult to imagine for certain consumer products but is easy to imagine for smaller customer groups. I am thinking in particular here of development for any internal user group and custom development of any kind. See the sidebars describing Tomax's new contracts with its customers (p. 316) and Géry Derbier's relationship with the French Post Office (p. 364). Despite that, very few organizations take the idea of sharing ownership with their customers seriously, and equally dangerous, very few customers take the idea of shared ownership with (and responsibility to) their contractors seriously. Many customers don't even want shared ownershipmany will say that they hired you to do "all that stuff; just deliver a useful system soon." The other surprise in the sentence is "frequent interactions." It's surprising because the importance of frequent interactions has been highlighted, researched, and reported for decades. It shouldn't be a surprise at all. However, how often does your customer, buyer, sponsor, or user base show up on the programming floor and check out what the team is really doing? The Agile Manifesto says the desired answer is "daily." The DOI says "frequent." I'll bet that in most of your organizations it is neither.
Many managers and management advisors advocate that the point of project management is to eliminate uncertainty. The DOI takes the stand that uncertainty is a fact of life, which must be met on its own terms, and in this, it distinguishes itself from other management advisories.
The DOI diverges from the agile manifesto by calling for anticipation. The feeling among usincluding both of the agile manifesto authors in the groupwas that the agile community has been forgetting to use the information they already have at hand, and have been costing their organizations by forcing them to react to events that should have been foreseen. To test this point of the DOI, consider in what ways and to what extent your management balances the use of iterations with anticipation, and to what extent they ever adapt.
Be truthful, now"People are the ultimate source of value"how many managers really take that seriously? We do. But the DOI extends the Agile Manifesto by reminding us that the environment also matters. People treated as cogs in a machine do not do as well as people who feel not only that they matter but also that they can make a difference in other people's lives. This is in danger of becoming a platitude, and I suspect that organizations that aren't already paying attention to this point won't change just on the basis of the DOI. However, I keep reading business cases where a company disrupts its competitors, and inside the case description a lot of space is given to the way in which people are not just empowered but feel they have a chance to change the world.
Group accountability for results has long been known for its effectiveness. One way to achieve group accountability is through cross-functional teams. These teams have been documented and recommended for several decades because they outperform the other teams (Hammer 1995, Liker 2003, Cockburn 1998, p. 214). Lean and agile manufacturing texts recommend cross-training people at adjacent workstations. The DOI goes further and suggests that people on the team develop an awareness of what the others on the team need so that if they can't do the job, they can help in whatever way they can. Sociologist Karl Weick, studying teams that work in life-critical environments such as aircraft carriers and firefighting, calls this mindfulness: people being aware of what other people are doing (Weick 2001). Mindfulness is a perfect term for one of our objectives with osmotic communication, and a goal to keep when communication is no longer osmotic. Mysteriously, this idea gets overlooked in most companies.
Chris Avery, the teamwork specialist among the DOI authors, clarified the shared accountability phrase. He wrote:
Zhon Johansen, a senior programmer, describes that he views improved business impact as the programmer's responsibility, as is improved usability and system quality. He applies that sentiment for each job in the company and practices it himself.
Of all the points in the DOI, this one should be most expected to anyone who has read this far in the book. We have discussed at length that what works in one situation may backfire in another. This is not obvious to those many managers who keep looking for a simple formula to apply. Surprisingly, it is also not obvious to otherwise enlightened people researching "best practices." The optimal strategy for a situation may require a reversal of what would normally be considered a best practice (see "Strategy Balancing," p. 101). The successful team stays alert to changing circumstances and adjusts strategies and practices to suit. Those are some of the surprises in the DOI. There is much more one can write about it, just as there is much more one can write about the agile manifesto. A longer discussion of my interpretation of the DOI, including the DOI as a "12-step process," is on my web site.[1]
Finally, it is useful to know that in constructing the DOI, each coauthor embedded in it his or her own personal framework for management. We collected those personal frameworks and checked that each person could operate his personal framework from the DOI, even if that framework wasn't explicitly named in it. Just so you can see one, here is my personal framework. It consists of three elements:
You may find it useful to write down your own personal framework for project management and see how it fits or contrasts with what is in the DOI. Using the DOII wish that the principles in the DOI might become the default mode of management in the future, not the exception. Improved Project ManagementA production manager for one of my books tried to schedule the entire four-month book production process up front. She did this because she was worried about meeting a deadline. To make sure she left nothing out, she assigned everyone's time in half-day increments . . . and then ignored small realities, such as that I would be on a small boat in the Caribbean for ten days. Naturally those were exactly the days she scheduled for me to revise the manuscript. She phoned each person's manager each day to check that the activity was proceeding according to her schedule. She had the 300+ page manuscript mailed from person to person in its entirety (a large batch size; see p. 60), so no parallel work was possible. She allowed no time for second revisions by any person because of course no one would make any mistakes on a project this important. Needless to say, the project immediately ran off the rails, starting with my ten-day vacation. People made mistakes, had other work to do, and so on. The project was behind in no time, and everybody was miserable. She was not malicious and not even particularly incompetent. She was trying to maximize business value, cut costs, maintain quality, and so on. Her mistake was only in understanding. I want every person, untrained or trained, to think in terms of the DOI. I want its precepts taught in kindergarten and used by reflex by everyone on a project. "Traditional," impersonal, batch-oriented project management is what ought to be questioned in every case. That's what I think this declaration should lead to. When you next put 'agile' into your contract, write using the project management Declaration of Interdependence. That way you'll get not only working software but also the benefits of the things on the right side of the previous table. Self-Managed TeamsA final comment is appropriate for self-managed teams. We were quite aware that there are many self-directed teams with no distinguished manager position, and we wanted the DOI to be applicable for them, too. A self-managed team should have no trouble signing up for group accountability for results and shared responsibility for team effectiveness, as well as flow of value (not effort), shared ownership, iterations, anticipation, adaptation, recognition of individual human beings as the ultimate source of value, and an environment where individuals can make a difference. Actually, it seems to me that the DOI is exactly the sort of declaration a self-managed team would hang on their wall. |
EAN: 2147483647
Pages: 126