Transactional or relational?

---

Here I am again: flogging my book*, with this question of the day:

Transactional or Relational? Is a project only a business transaction -- exchange one set of assets on the balance sheet (cash) for another set (project deliverables, aka inventory)? Everyone get out their pocket protectors!

Or, can a project also be relational -- form a partnership with the business and deliver the best value as judged by business impact?

So, let's parse the question a bit:
Who among us would argue against partnership? Well, actually many would. You can only have partnership if you have shared reward for shared risk.

How is this sharing to be done with a project underway and chartered?  The very word "sharing" dilutes control -- if not power -- shifting a bit from the project charter back to the business. But, of course, the business has put up the money -- they've certainly got skin in the game -- so naturally the business believes they are owed the benefits of partnership.

The best value thing is usually ok as a planning objective -- like partnership, who would argue against getting the best value? But the devil is certainly in the doing: if the business mucks about in real time with the definition of best value then the whole thing can be a PM's nightmare with shifting and changing priorities and druthers.

And then we come to the fuzzy stuff: what's a relationship?
As a PM, my visceral reaction is: give me something I can measure so I can go to work and manage it-- no measures, no management! Transactions uber alles! Again: pocket protectors to the front, please!

But about relationships: we're talking about reciprocity and flows: reciprocal trust, respect, loyalty, and commitment to shared values and outcomes; flows of ideas back and forth; and flows of risks back and forth.

Are these qualities measurable? Are they manageable? (Are those even important questions to ask about the fuzzy stuff?) And, even if they are not, shouldn't we still care about them day to day in project life? I submit that each of us must arrive at answers in our own way in our own value system.

But, let's grant for the moment that we see the benefit of joining project transactions with business relationships. What do we get?

Among other things we get access to business thinking that may inform project decisions day to day. That's important because it's actionable and ultimately will be reflected in the transactional side (measurable, manageable).

And the business may get our attention on mitigating a business risk by making some decision, some choice, some investment that we might not otherwise. Relations can point to branding, qualitites of esteem, and other appeal attributes that would fall into the best value bucket and be beyond a simple business transaction.

Is this agile writ large?
Some might say I've just spent a page explaining the reason Agile is agile: the relationship with the business. In that respect, yes I agree. (And, here's a shock -- I wrote that book also!)

*If you've read the book (and liked it), please review it where other's can read about it.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Are we done yet?

---

The "done" thing keeps coming up in my agile classes.

I challenge my students this way:

When an agile project is "done"? Is it done when time/money runs out? Is it done when the backlog is fully exhausted? And, is it done when the customer says it's done, or someone else?

Here's some set-up:

• Sponsor is a member/executive of the business that sponsors the project; the sponsor has control of the money from the business, and provides the money to the project. Sponsor also controls/owns the business case on the business side that more or less conforms to the project charter on the project side.
• Customer is the person who buys the deliverables from the business, after the project is "done". Customer brings money to the business, but not to the project
• User is in the customer community, but has no money. User may advise the customer, or hold the customer's proxy in the agile project team.
• Project is the collective entity of the business doing the project tasks. Project gets its money from the business sponsor.
• Now, if the project is a contract with the customer, then the calculus changes since now the customer brings money to the project. See: Golden Rule.More often than not, my responding guidance goes something like this:

 I wrote the book, so I'm supposed to know something about this.

So, here's my guidance, more or less, to the "done" question.

  Getting to "done"
-- Other people's money (OPM): the sponsor always has a vote on all strategic aspects of the project, including "done:
-- The business case: no serious project is approved without a business case, even if just a web form to the CFO/sponsor. Therein is a narrative, a vision, and a business expectation. Probably little other detail (thankfully)
-- Other swim lanes: no serious project has one vertical in the WBS or one horizontal on the swim map, so agile often only applies to the development; the rest of the project often runs conventionally and according to plans with "done" defined
-- Strategy v tactics: in general, agile puts strategic responsibility with the sponsor and the narrative; tactical value judgments are made by the customer/user
-- Sequencing: Newtonian physics still apply: roof after walls, so some things the customer wants may have to be deferred and money spent elsewhere (See below: best value "done")
-- Quality, standards, regulation: The customer doesn't usually get a vote on business policies to adhere to standards, maintain accreditation, and conform to regulation. These take budget, and thus discretionary funds for customer needs/wants is thereby diminished, deferring some requirements to the next project.
-- Non-functional: The customer usually doesn't have a say in non-functional requirements, and they figure heavily into "done"
-- The release: theoretically, an agile project is "zero base" after every release and could be ended right then and there. Release = 'done'
-- Backlog: there's always another project to absorb the undelivered backlog. (Else we wouldn't have careers)
-- Best value: Best value is the maximum scope deliverable for the fixed budget (investment) where the scope is the best fit (highest fidelity) to customer/user needs and wants, as prioritized for urgency, importance, usefulness (utility). In a BV project, done is not-later-than when the money runs out, but not mid-release either (there can be no partial releases). It's presumed that value is built in priority sequence with every release. In my opinion, BV is the most optimum way to plan an agile project.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

About planning

---

I was recently asked to explain planning -- more specifically, how to get started with a plan. (I didn't ask: did they read my book, Maximizing Project Value, which has myriad commentary on planning?)

Here's my take:

First, think about this: are you leading with the solution or leading with the problem? Resolve this question in your own mind. And second, only then assemble the solution-detail team or the problem-resolution team to plan. My prescription:

• All plans begin at the end, with the "memorial" to whatever the project is.*
• It's best to wrap the memorial in a narrative, a story if you will, of what is envisioned, why it's important to do, and when it needs to get done
• Rationalize the narrative and the memorial with whatever long term strategy (and/or mission)informs the project context.
• Compose a half-dozen headlines that capture the theme of the narrative -- topic sentences of paragraphs you would write to explain more of what's in the narrative. If these can be stated as goals, all the better.
• Arrange everything by urgency, importance, and required sequence. (Actually, you may find that there is more than one arrangement possible -- thus sticky notes or whatever) Of course, you must honor sequence that is determined by constraints (walls before roof). But as to urgent vs important: they are quite different. Urgency is a temporal characteristic. Importance has to do with shades of "must have"
• Let it rest! It may look a lot different in the morning. Modify as necessary
• Decompose the headlines into how-to steps. This is where you deconflict and deconfuse the "how" from the "what". This may require a lot of SME input.
• Then, follow the standard planning steps for planning cost and schedule given in the PMBOK or elsewhere.

A few other ideas about the plan

• Separate "means" from "ends" -- that is, separate process from memorials
• You may decide not to maintain the plan -- planning is more important than the plan. The plan may go awry as soon as it is put into play (See: MSProject schedules)
• Relect and replan when you are sufficiently off the baseline that the plan is no longer relevant.

And finally:

• How are you going to explain results (elsewhere: the memorial)? In other words, what's the message to be that is about the memorial? Thinking about the message should inform the plan to get there.

*Some say deliverables, but I say memorial because in the public sector and non-profit domains, projects are often about improving lives and circumstances; and these improvements may not be so tangible as a deliverable the way we normally think of it.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Credibility

---

I posted recently about respect and loyalty often missing from the conversation about what we like in leaders -- and leadership.

Another recent posting reminded me that I should have also included "credibility". In her posting, Linda Bourne tells us that credibility is built upon a foundation of trust and respect -- I agree -- and other contributors are reliability (do what you say you are going to do) and a convincing demeanor (sincerity, belief conveyed, the aura of truth)

Of course, in my earlier posting, I mentioned 'command presence' which more or less puts all of these leadership attributes in a package, the objective of which is leadership effectiveness.

Command presence, -- if you've not thought about it before -- as given on leadership-tools.com:

Command Presence is essentially your ability to project your position as one of authority in a professional sense, to others in your environment. How you are perceived by those around you defines your level of Command presence.

The vast majority of time, command presence is expressed as a non-verbal communication to those around you and is determined at first glance or through your first instructions, interactions or comments.

Your appearance, including your posture and personal presentation in how you walk, speak and the gestures you use all project your personal "Command Presence".

"Walking with INTEGRITY" is the essence of Command Presence.
 

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

This explains everything

Want to know everything? I do. So I just finished reading an interesting book of 150 essays (2 or 3 pages each): "This explains everything" which is more or less a production of the contibutors to the equalling interesting edge.org.  

This book purports to answer the Edge's "annual question" for 2012 seeking elegant theories about how the world works. And so readers explore quantum physics, evolutionary biology, the origins of the universe, and a myriad of other theories of how we think and live, communicate and decide, and how artists do their thing.

Of course, I was on the watch for stuff that would pump up project management. To that end, I found a few things to ponder, to wit:

A system that makes no errors is not intelligent.

Perception requires smart bets called unconscious inferences.(p. 55).

Inexactness challenges causality. As Heisenberg observed: “Causality law has it that if we know the present, then we can predict the future. Be aware: In this formulation, it is not the consequence but the premise that is false. As a matter of principle, we cannot know all determining elements of the present.”(p. 79).

“Culture is the precipitate of cognition and communication in a human population.” Sperber’s two primitives— externalization of ideas, internalization of expressions— give us a way to think of culture not as a big container that people inhabit but as a network whose traces, drawn carefully, let us ask how the behaviors of individuals create larger, longer-lived patterns.(p. 113).

INFORMATION IS THE RESOLUTION OF UNCERTAINTY

... as time becomes worth more and more money, time is seen as scarcer. Scarcity and value are perceived as conjoined twins; when a resource ... is scarce, it is more valuable, and vice versa. So when our time becomes more valuable, we feel as though we had less of it. (p. 193).

(a) “Deterministic” doesn’t mean “predictable”; (b) we aren’t good at intuiting the interaction of simple rules with initial conditions (and the bigger point here is that the human brain may be intrinsically limited in its ability to intuit certain things— like quantum physics and probability, for example); and (c) intuition is not a quasi-mystical voice ... but a sort of quick-and-dirty processing of our prior experience (p. 211). 

Collingridge dilemma— the idea that there is always a tradeoff between knowing the impact of a given technology and the ease of influencing its social, political, and innovation trajectories. Collingridge’s basic insight was that we can successfully regulate a given technology when it’s still young and unpopular and thus probably still hiding its unanticipated and undesirable consequences— or we can wait and see what those consequences are, but then risk losing control over its regulation. Or as Collingridge himself so eloquently put it: “When change is easy, the need for it cannot be foreseen; when the need for change is apparent, change has become expensive, difficult, and time-consuming.” (p. 255).

And, I found a few others that PMs might appreciate:

To have a good idea, stop having a bad one. The trick was to inhibit the easy, obvious, but ineffective attempts, permitting a better solution to come to mind.(p. 303).

Most of us develop a biased temporal orientation that favors one time frame over others, becoming excessively oriented to past, present, or future. Thus, at decision time for major or minor judgments, some of us are totally influenced by factors in the immediate situation: what others are doing, saying, urging, and one’s own biological urges. Others facing the same decision matrix ignore all those present qualities, focusing instead on the past: the similarities between current and prior settings, remembering what was done and its effects. A third set of decision makers ignores the present and the past and focuses primarily on the future consequences of current actions, calculating costs vs. gains. (p. 317).

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

AGILE FAQ --- the Big Three

---

Students of agile project management with real experience and success with traditional project practices and methodology come to class more often than not with these three questions at the top of their list of things to learn:

1. What is this thing called agile?
2. How do I work agile into my traditional environment?
3. How do I get started?

Fortunately for them, I wrote the book! (But, so have others. Just take a look at my library for the ones I like)

But, back to the Big Three FAQ. Here's my 'elevator speech' for those without the time to read the book:

To Point 1:

Agile begins with the Agile Manifesto and the Agile Principles, which in the main redirect the project focus to the 'ends' as having a higher priority than the 'means'.

The management focus is first on outcomes and results and only second on inputs, like cost and schedule.

Agile is a change-driven quality-centric methodology that seeks to deliver "best value": the most important, urgent, needed scope possible for the investment offered by the project sponsor, where maximum fidelity to customer need is the driving factor.

Now to the second point, agile in the traditional environment:

First, make agile its own swimlane or WBS vertical. Such allows the agile method to run along somewhat unencumbered and unencumbering to the other swim lanes with traditional methods

Second, work out strick interface definitions/specifications/functionalities between the agile deliverables and the traditional deliverables. In other words, control the integration between swim lanes at the interfaces

And, third, keep to the overall narrative developed first in the business case and flushed out a bit in the project charter. Inevitably, agile in less-than-a-green-field is going to be more constrained than otherwise.

And to Point 3, how to get started?

You get started with a pilot project. Mike Cohn has some excellent advice on this: pick something important, but constrained. Get the buy-in of a sponsor for the pilot, do some training, line up a coach or mentor, and then give it a go.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Disruptive technologies

---

We've all seen forecasts and predictions in print and in video of coming revolutions (or aggressive evolution) in living and working (and playing) to be brought by advancing technology.

However, I was struck by a forecast in this 13-page presentation from McKinsey & Co that upwards of 140M jobs will be driven out of the world economy by productivity.

Wow! That's profound. In the US, the total non-farm payroll is about 134M, so McK is talking about improving productivity worldwide by a factor equal to the whole US non-farm workforce. OMG

Of course, these disruptive technologies will bring on hundreds of millions of replacement jobs, even new industries that do not exist. And that is where we come in: if you look at the project and project management implications of the relevant technologies and the scope of the efforts, our industry has a lot to do over the next 20 years.

Of course, as you look at the report pages, keep in mind you are looking at business value, not project cost. Hopefully, the project cost will be much less. Afterall:

The cost of a project is not its value. A successful project is a project that is a value-multiplier on cost.

Erik Brynjolfsson has one of the many TED talks on this point about technologies, productivity, and employment. He poses a grand challenge: "Learn to race with the machine" (instead of racing against the machine) He talks about the great decouplings: productivity from employment, and wealth from work. But, he ends with this idea: Technology is not destiny

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Constructive criticism

---

It was famously said, in a paraphrase: lead people, manage things. I buy into this advice, so I'm always on the alert for something that plays into it. In a recent posting, I read some advice on delivering constructive criticism that seem pretty sensible, given my own experience of being on both the receiving end and the delivering side of such encounters. And, full disclosure: the first time I really had to do this, I really screwed it up!

So, the main points are:

• Deliver the news in person, not on the phone, Facebook, or by tweet or email!. I once had a boss (vice president) who was fired by email... so chicken-crap by the guy who sent the email.
• Focus on actionable things to do. Seems eminently sensible to be concrete, but often you get this: A friend was told he did not have the "leadership presence" for executive office. What do you do with that?
• Bring praise. I always try to start with praise. In fact, my advice is never come without praise. No one is a complete dolt. Seems kind of backwards to me to start negative and then wind saying: "but you do a lot of stuff well".
• Encourage problem solving, since folks who can see a problem and get it solved always have a job; and those that can't are 'takers' for the most part and always at risk for their job.
• Provide a model. If you're asking for change, there should be a model for guidance. Afterall, if there's no direction to change to, how is one to know where the utility lies?

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Risk management models

---

Dr John Breit is physicist who departed physics early for the world of quantitative risk management, after looking briefly at joining the Naval intelligence community. He went to work on Wall Street and became a risk slueth, overseeing risk taking and teasing out the unacknowledged uncertainties.

In an interview published online, we learn that "early in his career, Mr. Breit figured out that models for markets aren’t like those for physics. They don’t come from nature. It was necessary to know the math, if only so that he couldn’t be intimidated by the quantitative analysts."

To apply this insight to project management, just substitute "human behavior" for "markets" and you readily see the point: you really can't reduce human behaviors and factors to quantitative models. Ergo, there are limitations to schedule and cost models, like PDM networks and EVM and others, that depend on rational interactions among all the actors (project staff).

He warns that numbers often disguise the risk rather than reveal it. We read: The only thing from capital markets math he came to embrace was this immutable law of nature: investors make money by taking risk. “If it’s profitable and seems riskless, it’s a business you don’t understand,”

And Breit counsels that risk managers should  "... build networks of people who will trust them enough to report when things seem off, before they become spectacular problems"

Frankly, it all sounds rather practical for a physicist!

My counsel: work in reasonably short "waves", with the wavelength not greater than you can see ahead. Rethink, reassesses, and replan each subsequent wave. Don't expect that any model is going to be better than a piece-wise construction of short linear forecasts, each one adjusted for the circumstances of the current planning wave.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

plan

Process vs Practice

---

I am constantly amazed at the number of PMs -- presumably experienced -- that I speak with that don't seem to grasp the idea of "process". They all seem to know practices: Risk management, change management, chartering, earned value management, etc, etc. But, ask them about how a practice fits into a process and the veil drops.

So, back to "Process 101": Input --> practice --> initial conditions, outcome with controls, constraints, and policies as modifiers/influencers on the practice. See Six Sigma and any of a number of other doctrine -- like PDCA -- about processes and process control.

And, this matters because: Because it's about dots, connecting the dots, and having a project narrative to govern by. Narrative is what makes the connection between the business case and the project charter. There's got to be a process to get from 'dot #1' to 'dot #2'.

It's probably too much in a "101" discussion to bring in the idea of process networks with nodes, connecting links, link protocols, and work flow. But, if I ever get the "201" level, those will be ideas we'll explore.

However, even at the '101' level there should be room for a discussion of 'lean' practices -- some say lean processes -- that try to optimize the value add of the process and minimize the waste of overhead. One approach is to look at batch sizes and try to find the minimization where overhead and batch size seem to work together, and to look at parallel/serial task flow, again with the idea of value add maximization.

And, at the '201' or '301' level we might bring in the Theory of Constraints to look at how moving/redesigning a constraint can reduce the cost of the process -- by reducing the cost of process inventory at intermediate steps -- and maximize the throughput.

So, with all this stuff, perhaps I should not be amazed, but I still am.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

A strong risk culture

---

A recent posting by McKinsey & Company talks about "managing the people side of risk".  Part of their discussion is about the properties of a "strong risk culture" which are worth a mention here at Musings:

Acknowledge Risk: Everyone knows that risks should be acknowledged (no news there), but to actually have the courage to do it consistently is the sign of a strong culture. We read: “If we see it, identify it, and size it, then even if it’s horrible, we’ll be able to manage it.”
Encourage transparency: Sometimes accepted practices "... unintentionally reduce transparency regarding risk. For example, at one .... company, the culture thrives on competitive teams. Competitiveness is so strong that product-development teams use subtly different risk classifications so that their respective projects can’t be directly compared."
Respect risk: "Companies often unconsciously celebrate a “beat the system” mind-set, rewarding people who create new businesses, launch projects, or obtain approvals ....—even if it means working around control functions ....." But, in the long run such rogue activity can be destructive by its overall culture of disrespect; others have shown that .... "In the best of cases, respect for rules can be a powerful source of competitive advantage."  At first blush, this is not intuitively obvious, by the McKinsey folks say: "... confidence in proceeding [with a risky venture] resulted from an exhaustive risk debate [in accordance with rules and controls] that reduced fear of failure and encouraged greater boldness..."

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Teams ... Managing the white space

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively.

Inevitably, keeping the team together to promote cohesiveness raises the question: how to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it). In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

• Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
• Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
• So also bring in mock testing, special event prototyping, and, of course, that bane of all:
• Maintenance of team records.

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:

The cost of a project is not its value; in a "good project", value greatly exceeds cost

Here's the memo: Manage for value! (Oh!, did I say I wrote the book?)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Is your fuel gauge agile?

---

It seems that there is always confusion the first time someone rolls up on an agile methods burn down chart:

• What are we burning?
• How much is there to burn?
• How long does it take?
• What is the starting point?
• When does it end?

An analogy
Think of a burn down chart in the same way you regard the fuel gauge in your car:

• You fill up the tank
• You drive around, consuming fuel
• Eventually, it the fuel runs out, the gauge shows empty, and the car stops

So, to make the analogy:

• The gauge, if it has any metric calibration at all, probably says "full" at the top.
• Let's say that "full" is 20gal (US) or about 75ltr. So, the gauge could read 20gal instead of "full".
• But, if the car gets 30mi/gal, then the gauge could read 600mi (965km) when "full" instead of 20gal. Some driver digital display systems give such measures
• But, if you drive about 10mi (round trip) every time you run an errand, go shopping, go to a restaurant, etc, then the gauge could read 60 trips when "full" instead of miles or gallons. Naturally, when the gauge gets to 1/2, then you've got 30 trips left in the tank.

And so it is with a burn down chart.

• Typically, we're burning some consumable resource, like hours (gallons of fuel), to empty the backlog (tank)
• When the backlog runs out, we stop
• But, we could look at some velocity, a rate of consumption, like stories per hour (miles per gallon)
• Or, we could look at the number of stories (trips to the store) we expect to complete if we burn all the hours (fuel)

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Testing COE and Agile

---

The question: Many organizations have created Testing Centers of Excellence. Is there a place for this in Agile or is this approach counter to the intimate nature of Agile? 

My answer: COE's usually are staffing pools, where the pool manager focuses on skill development, and sends/assigns the skilled staff out to the dev teams. In this regard, the test person from the COE simply joins the dev team.

Sometimes, a COE is in the workflow of the project; in this scenario, the release package goes through the COE for some kind of validation testing before release to production.

Of course, agile is not a complete methodology if the field is not green; integration/UAT testing with the existing product base often is handled in a traditional sequence, post-agile development. The COE could be responsible for this last testing step.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Large Scale Agile

---

I think this cover says it all. Large scale agile is a bit of a high wire act, but doable.  So we read in the May/June 2013 issue of CrossTalk, the Journal of Defense Software Engineering.

(Full disclosure: when I decided to write a book based on my agile experience, I chose to write about agile in the enterprise: "Project Management the Agile Way: making it work in the Enterprise")

The lead article, "Scaling Agile Development" is by authors Craig Larman and Bos Vodde, the former known best for his 2003 book: "Agile & Iterative Development" but more recently for a two volume tome about scaling agile, from which this article is developed.

(Another disclosure: I've not read any of Larman's books; only this article)

In a word or two: OMG, No!

At best Larman and Vodde are examples of agile naivete; at worst, they're just plain wrong headed about how to do agile in the defense industry. And, it's a shame that Crosstalk, a worthy journal to be sure, but obviously not peer-reviewed, would publish such a poorly conceived paper.

Their basic idea is this: Agile, in the guise of Scrum, is scalable to any limit -- thousands of developers they say -- by the simple expedient of adding teams (in 10 person increments) and adding some coordination meetings and tools. Architecture, testing, and management -- unneeded they say except for that which a team can provide for itself -- are unnecessary burdens, even for huge projects.

They posit that all this is doable in three frameworks: First the single team for the small projects; second a framework that does for 10 team (100 team members); and then a third framework that is unlimited in its scalability. The differences in frameworks are some overhead services provided at each level for coordination and communication and management of the project-level backlog, and the idea that at the framework 3 level more than one product owner will be needed, and so a committee of product owners will be needed. Indeed, most of the discussion centers on the backlog and how it is to be distributed among teams.

At scale, for many skills, like architecture, the authors suggest the benefits of a "community of practice" birds-of-a-common-feather organization plan (I like this idea and it's generally endorsed in the agile large-scale community).

I also like some of their ideas about organizing the backlog -- which at scale will be tens of thousands of stories, etc -- into "areas", like protocols, but NOT into such broad categories as "performance".

There's no discussion of how these frameworks fit, or could fit, in a contractor/government environment; how the warfighter's interests are to be represented... they certainly aren't present to be the product owners; and how processes that obviously breakdown at scale -- like simple war rooms with sticky notes for stories -- would work with tens of thousands of stories. And, there's no discussion of interfaces to legacy installed base; no discussion of working through defined interfaces or APIs; and no discussion of how other swim lanes (or WBS verticals) would be brought into the project.

Even worse in some respects, given the need to honor "other people's money", there no discussion of a business case or how to present large-scale agile in a business case.

All the method discipline of XP is ignored; all the great practices of agile modeling and scaling, so well documented in the agile DSDM methodology and by such practitioners as Scott Ambler who has made a science out of agile-at-scale is ignored in favor of the lightest weight and least demanding of the agile methodologies: Scrum

In short, if these two guys have ever been close to a large scale agile project for real, it does not show. If they have ever tried to build programs and projects for the defense industry, whether business systems or warfighter systems, it is certainly not in evidence.

For more of my thinking on agile in the DoD, read this white paper. (Yet again, another disclosure: I worked for the DoD as a project manager and I worked for the DoD as a contract project manager doing software systems development). And, for agile in the waterfall: this posting.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting