A.G.I.L.E.

Here's an exercise that I invented to help me quickly get a group engaged at the start of a course, and also give me some insight into their pre-existing experience and attitude towards Agile.

Duration: About 10 minutes
Grouping: Pairs, whole group

Procedure

1. Whiteboard or butcher's paper: write the letters A, G, I, L, E vertically
2. Ask participants to work with the person next to them to turn A.G.I.L.E. into an appropriate acronym in two minutes.  Tell them not to worry if they can't come up with a letter: we'll being pooling the results soon enough.
3. Go around the room and write down whatever they come up with.
4. Have a quick scan of the results and give them (positive) feedback about their degree of familiarity with and/or open-ness to Agile.

Benefits

1. Quick, fun and creative.
2. Sets the tone for working with others in the group and sharing ideas.
3. Gives the facilitator useful insights into the group's existing knowledge of and their attitude towards Agile.

Troubleshooting

• I prefer to get some associations, e.g. "A is for Adaptive Planning, G is for Group cooperation ...", but sometimes get a coherent sentence: e.g. "Always Generate Insights & Leverage Experience" -- which is a nice way of saying "Inspect and Adapt", but is showing inventiveness rather than mining awareness.
• Suggestion: Write "A is for ..." to steer in the preferred direction, or do it twice and ask for both.

Adaptability

• Faster to use pairs than individuals during the collating phase.  For large groups consider using trios instead of pairs.
• It's better if the topic at hand has a short name.  E.g. Better to use L.E.A.N. than C.O.N.T.I.N.U.O.U.S. I.M.P.R.O.V.E.M.E.N.T.!

Failing to Plan is Planning to Fail

Winston Churchill

It was Winston Churchill, during World War II, who memorably said:

He who fails to plan is planning to fail.

But in our smaller projects how many times should we plan, and when?

I propose 4 possible answers: 0, 1, 2, many times.

0: Seat of the pants
This is perhaps permissible for small tasks, and certain expert work, especially when it's been done by said experts many times before.  Jazz musicians and theatrical improvisors are ace at this.

In software development this is called "cowboy coding", and is not recommended for serious projects.

1: Classic waterfall and variations
The big risk here is that on larger projects that if and when the plan fails, we must now re-plan (and we've already blown our whole planning budget) or follow the original plan to ruin.  If the project is long, complex, requirements are poorly understood or subject to change it is prudent to reserve a portion of the planning budget for later re-planning.

A superior variation to doing all planning at the start of the project is what I call "research then development".  This consists of a research phase at the start with no planning in which prototyping and other risk-ameliorating work is undertaken, before the big plan is laid down.  It allows for key learning during the research phase.  From a governance perspective these two phases may be considered as separately funded projects.  It's only after the research phase that we are in position to estimate the cost of the more expensive development part.

2: Build one to throw away (and other variations)
Buiding a cheap prototype to explore risks and gain understanding of the challenges of the particular project before locking down the full plan is quite a good strategy.  Recommended in the original waterfall paper by Winston Royce and by Fred Brooks in The Mythical Man Month (although Brooks now advocates the next approach).

Many times: The Agile way
If we accept that projects involve learning, then it makes sense to plan repeatedly, first in a broad sense, and then refining as we learn more.  Adaptive planning embraces change, both in inner factors (learning) and outer factors (changing requirements or circumstances).  The refinement of fixed length iterations and repeated planning encourages us to expend our planning budget over the course of the project, and minimizes the amount of early planning under incorrect or outdated assumptions that is not only a waste in itself, but also leads to other misguided (hence wasteful) activities.

Conclusion
What would Winnie do?  The picture suggests that he would plan twice (or possibly follow the V method of development!).

For my part, bad experiences with too much planning up-front (and the consequent waste and lack of resources to re-plan) led me to more successful iterative and incremental approaches, and later to the shorter, fixed length iterations of Agile.

Agile is, in part, about not being surprised "when our best laid plans go astray", and instead of being disappointed or abandoning planning, "planning to re-plan" ... cheaply.

An Agile Mnemonic: WRIST SPIN & PACE

Well, maybe more of a mnemonic.  I tried to cook encapsulate a not too long list of the keys to Agile success, and this is what I came up with:

The wrist spinner's stock delivery

Workshops
Retrospectives
Iterations
Stories
Test-driven development

Sustainable pace
Prioritization
Incremental design
iNformative workspace

and

Pair programming
Adaptive planning
Continuous integration
Estimation

The basis for a good bowling attack, plus my choice of foundation practices for Agile success.  Must be cricket season.

Howzat!?

Scaling with Kanban

Here's a neat idea for scaling Agile from David Joyce:  As an alternative to Scrum of Scrums, consider Kanban at the programme level:

The programme board has cards for each of the sub projects or sub feature sets (MMFs) only. The detail for each of these is broken out on each of the teams Kanban boards, not on the programme level board.

This approach visualises what is going on at a higher level, and enables the various representatives from each of the sub teams to collaborate, understand what is coming their way that could affect them, and facilitate synchronisation.

A daily standup is still held, but the rhythm is around:

1. what is blocking your team, or about to block another team
2. what work is in progress
3. bottlenecks (either current or impending)
4. are priorities clear on what gets pulled next
5. what needs to be expedited

The standups still run from right to left on the board, in other words upstream; from what is about to released, back all the way to analysis.  More...

If we think of a story wall as a dashboard for the team (and other interested parties), the programme level Kanban can be thought of as a (higher-level) dashboard for the overall programme.

What is project success?

Moonshot: Successful or "Challenged"? 

What defines project success?  The end result?  The net benefit?  Delivered according to plan?

The Standish Group surveys the outcomes of large IT projects and reports periodically in its Chaos Reports.  For example, in 2008 Standish found that:

• 32% of the projects surveyed "succeeded" (delivered on time, on budget, with required features and functions)
• 44% were "challenged" (late, over budget, and/or with less than the required features and functions), and
• 24% failed (cancelled prior to completion or delivered and never used)

I'd like to note that by the above definitions, a project can both succeed and fail at the same time, if the planned features and functions are all delivered on time and on-budget, but do not add up to a usable product.  [Presumably "failed successes" are classified as failures so that everything adds up to 100%.]

Jim Highsmith observed at the 2010 Agile Australia conference that such surveys measure failures of planning more than performance.  For example, a challenged product (say late), could still deliver enormous business value, while an on-time, on-budget, and "fully featured" might be a flop in practice.

Here's a graphic example.  By Standish standards, the project to put a man on the moon was "challenged".  The time goal and stated objective was met -- do it before the end of the 1960s -- but in terms of cost:

[A] preliminary cost estimate of $7 billion dollars was generated, but this proved an extremely unrealistic guess of what could not possibly be determined precisely, and James Webb used his administrator's judgement to change the estimate to $20 billion before giving it to Vice President Johnson.  Webb's estimate shocked everyone at the time, but ultimately proved to be reasonably accurate. The final cost of project Apollo was reported to Congress as $25.4 billion in 1973.

Informally, this project was one of the greatest successes of all time!  The difference is that informally we look at the realized benefits, as well as the costs incurred.

In practice judging project success is a slippery business, and undertaking large-scale research a challenging undertaking  Part of the challenge is devising good measuring sticks.