There are several different strategies you can use:

Strategy 1: Fix the scope and flex the price

This keeps scope management very simple, you just build all of it.  The catch is it may take longer than you expected, so you may need to flex the price through a time-and-materials contract or some kind of sharing of financial risk.  Understandably, this risk of cost overruns renders this simple approach unsuitable in many environments.

Strategy 2: Work in priority order and stop when the money runs out

(Admittedly, this is not exactly fixed scope.) This is very commonly recommended on agile projects, too commonly in my opinion.  But again, it has the virtue of being relatively simple.  Do the most beneficial stuff first, leaving the least beneficial until last.  When the money runs out, just stop and don’t do the rest.  Agile makes this approach possible – but not mandatory.

Strategy 3: Implement remaining features more simply when short of time

There are many factors that influence the effort required to develop a feature (or user story, depending on your terminology).  Some of those factors are probably under your control: e.g. How extensive is the validation? How much effort do we put into optimising the user experience (UX) and appearance?  Do we fully automate everything, or do we allow manual overrides so we don’t have to code every single  edge case?  Can we think of something that would save development time, and still meet the overall business goal (albeit in a different way from what was originally expected)?

If you are using good earned value tracking you should know, within the first quarter of the project, whether you are likely to run out of time at the end.  Once you find that out, immediately start seizing all these opportunities to simplify the remaining 75% of the project.  And, because you have good earned value tracking, you can justify the simplifications to your stakeholders.  The aim is to deliver all of the planned business benefits, just with simpler implementations than might have been originally expected.

We’re using a variant of this strategy on my current project.  We built the highly-used parts of the system first, taking a lot of care with their appearance and usability. The second half of the project consists of functionality that is much less commonly used, so here usability and appearance are much less important. (If it takes a user a few extra minutes to do something, it doesn’t really matter if they only do that thing a few times each year.) So for the second half of the project, we have consciously shifted our design approach away from ease of use, and towards simplicity of implementation.  Because we were using earned value-like tracking, we can justify this change of approach to users and management.

Strategy 4: Split each feature (or user story) into essential and nice-to-have parts

This a refinement of the previous strategy. Right from the start of the project, you split features/user stories into two pieces: an essential minimum piece, which you implement early, and nice-to-have embellishments (such as advanced data validation or visual styling) which you defer to the tail end of the project.  If you run out of time, you drop some of the embellishments from the tail, and still deliver a working system with the full scope of capability/functionality.

Strategy 5: Make multiple passes over each story, doing the basics first and then improving it later

Similar to strategy 4, but you may “visit” a given user story 3 or more times within the project, instead of just twice as in Strategy 4.  I like this in theory, but in practice I think it’s too hard to used earned value or burn-chart tracking in this strategy.  Whereas in strategy 4, I feel that earned value remains (just) feasible.

[Tim Wright's comment,  below, gives more details on how this strategy can be done]

Summary

The last three strategies are all variations on a theme. Within a single project, you may use several of them, and maybe also resort to strategy 2 for a few user stories.

I recently heard the phrase “value management” to describe the work of deciding not only what to build, but also how simply or thoroughly to build it  The aim is to meet the business goals with the optimal expenditure of effort – i.e. do what needs to be done, without overspending on superfluous details.

Further Reading

All of the following are excellent.

Alistair Cockburn’s Trim the Tail.  A rich explanation of the theory and practice of strategies 4 and 5, with significant additional benefits in risk management.

Alistair’s list of related strategies.

Jeff Patton’s concept of Feature Thinning: Jeff’s a leading practitioner of Strategy 5. See: Finish on time by managing scale, Difference between incremental and iterative, Accurate estimation = red herring  Jeff has often used these techniques on fixed-scope, fixed-price projects.

Description from an agile company called Atomic Object, of how they operate with fixed budget and controlled (rather than fixed): here and here.

Martin Fowler’s Scope Limbering

The opening section my my own agile earned value (pdf) has more info on why fixed scope is a valid option in agile.

I’ve also posted a summary of estimation tips for agile projects.

Alistair has a great approach to  agile, extremely well-informed without becoming dogmatic.  I’ve described more about his approach to agile, and how important it is, here.  When you talk with Alistair, he makes you think – and he also makes himself think (so you get advice tailored to your particular situation).  At the risk of sounding like some book’s dust jacket: Alistair is co-author of the Agile Manifesto, co-author of the Declaration of Interdependence (great idea), co-founder of the International Consortium for Agile (I really like their approach to agile training), author of 5 books from use cases to agile development, and a specialist in agile requirements gathering, development, methods, and organizational processes.

I asked Alistair to describe what he can offer to Wellington teams, and he replied:

• align different parties’ views on what agile is and how it fits into the company (e.g. 1/2 day)
• organizational "blood-pressure" check on adoption of agile and unaddressed ailments in general (2-3 days)
• coaching on use cases, user stories, project management, agile adoption (1/2 – 2 days)

He’s done this kind of work for many other teams around the world.  If you’re interested in tapping into his expertise while he’s in town, email Alistair directly. To prevent it being harvested by spam bots, I’ll describe his email address to you as follows: the part before the ‘@’ is ‘TOtherAlistair’ (short for The Other Alistair) and the part after the ‘@’  is ‘aol.com’.

By the way, also in Wellington this month, and speaking at the conference and at AgileWelly, is Jeff Patton.  Jeff’s an excellent speaker on defining and managing the scope of agile projects.  Both Jeff and Alistair have been heavily involved in the agile community in Salt Lake City, Utah, which seems to be a breeding ground for great agile ideas.  I don’t know whether Jeff is available for consulting work while he’s here, but if you’re struggling with defining or scoping agile projects, get in touch with him and ask!

Finally, Alistair’s surname is pronounced “Co-burn” the Scottish way.  I don’t know of any other Scottish words with a silent “ck” :-)

That was my first taste of agile as a belief-based movement.  It’s dangerous ground, a philosophical quicksand which has grown over the following years – to enthral some and to alienate others.  I vividly remember a presentation, again on Scrum, which I paid to attend some years later. It reminded me of something which no professional event should ever resemble: a recruiting session for a strange religious cult.  The kind where the charismatic speaker sways all listeners with his eloquence and fervour… then gets arrested three years later for embezzlement and child abuse.  (I once stayed in the commune of just such a cult.  After one uneventful yet unsettling night, I was glad to see the last of it.  Years later, the leader was indeed arrested!)

Agile as a belief system

At its worst and most cult-like extremes, belief-based agile can be dismissed out-of-hand, and rightly so.  But at the milder end of the scale, such as the Schwaber-Beedle book, it serves a valid purpose.  It presents a clear and compelling introduction to agile, which is great for people who have never heard about it before.  It worked for me.  My team tried what we read in the book, and we loved it. It was great to have such a simple introduction to agile.  Without that simplicity, we might never have got started.

But then we started to struggle.  Our projects didn’t seem to fit the book.  We had constraints which the book didn’t even mention.  I began to suspect Scrum was good for other people but not quite right for us.

But what bothered me more was that I still didn’t understand it.  What the heck are these so-called emergent properties anyway? And how do you force them to happen? ;-)

Agile as (social) science

I wasn’t until I read Alistair Cockburn’s book Crystal Clear that things started to make sense.  The book is not about Scrum, it’s about Alistair’s rather different formulation of agile (more on that in a moment).  And yet, it was only by reading Crystal Clear that I actually understood Scrum.  Although it uses different terminology from Scrum, Crystal Clear filled in the missing pieces and answered my questions about Scrum’s “emergent properties”.

But Crystal Clear did three things which even more important:

1. It showed that agile can be based on evidence and science.  (Although, when you base it on science, agile turns out slightly, yet significantly, different from the “agile” you may be accustomed to.)  I’m not talking here about the popular misconception of science-as-blind-faith-in-experts, but about the true nature of science where even the experts question their own judgement and are determined to follow the evidence where ever it may lead.  Crystal Clear grew out of Alistair’s PhD research (which in turn grew from his process work at IBM and elsewhere). Based on observations of real-world projects, Alistair formed hypotheses about the factors that led to success in software development.  Then he painfully discarded one hypothesis after another, as the evidence demanded.  He eventually arrived at the family of methodologies known as Crystal, of which Crystal Clear is the version applicable to small teams.  (Alistair’s development of Crystal preceded the founding of the agile movement.  He was later one of the 17 co-creators of the Agile Manifesto.)
2. It showed that agile should be flexible, to suit the nature of humans.  It is impossible to read Crystal and not be struck by how human-friendly it is;  how it allows, and in fact requires, variation to meet your circumstances; and how one-size-fits-all rules are the very antithesis of agile.
3. It explained that simple belief-based formulations of agile are the starting point, not the destination.  The common rigid, belief-based formulation of agile is an ideal learning tool, but it’s only the starting point on the learning journey, not the end.

Conclusion

Today, I happily use Scrum – informed by and infused with a healthy dose of Crystal Clear.  If you are not familiar with Crystal Clear and Alistair’s work in general, you owe it to yourself, and your project, to learn.

Seek a broader perspective and, at the risk of being facetious, don’t stay in the commune until the leader gets arrested!

On my current project, we’re realised that minimising change is not necessarily a good thing. Why? After the system goes live, we must be able to change it.  (In our opinion, an unmaintainable system would be a failure.)  So… if we are going to successfully change the system after go-live, then we must practice making changes before go live.  Without such practice, how would we know whether the architecture is maintainable?  How would we know whether the team has the necessary skills and confidence to safely change the code?

So each mistake, dead-end, or change of direction has a silver lining: it’s a chance for us to practice the essential skill of changing our code.  We need these mistakes to happen, so we can practice correcting them.

He shows that pairing is a form of expertise, that takes time and effort to develop, just like any other type of expertise.

Furthermore, I would suggest, it’s very hard to imagine successful pairing if you’ve never actually seen it.  Which brings me to the point of this post: is there anyone here in New Zealand who is doing pair programming and who might be interested in letting myself and a couple of colleagues see how you do it?  We work for a registered charity (so we’re definitely not one of your competitors).  I’m hoping that, like many agile teams, you’d like to share your success stories.  If so, I’d love to hear from you.  My email address is on the contact page.

Do you have strong experience in agile testing? Or are you a good senior tester who wants to learn agile? Either way, we’re keen to hear from you.

Our project is just getting started. If you’d like to be part of a friendly, co-located agile team in central Wellington (NZ), let’s talk! The best way to contact me is via email.

How does expertise develop?

Kahneman’s book points out that expertise develops, virtually inevitably, when a practitioner has long experience in a field where both of the following apply:

1. There is indeed some correlation between decisions and outcomes. (Conversely, no amount of practice will ever give you expertise in predicting the next outcome on a roulette wheel!) In the field of software development, our design decisions do indeed influence the outcomes of correctness, performance and maintainability.
2. Practitioners receive feedback on their decisions (so that their inner neural network can learn). In other words, we make decisions, and then actually see how those decisions affect the correctness, performance and maintainability of our software. As long as we maintain an open-minded willingness to learn, and we don’t change jobs too often, we will receive this feedback and therefore expertise will develop.

A case in favour of pairing

While I’ve questioned the efficiency of expert-expert pairings, the science of expertise suggests a possible benefit of expert-novice pairings – a benefit which I have not seen described elsewhere. I suspect that such pairing may help the novice to develop expertise more quickly. Not because of what they expert says (as implied by some other descriptions of expert-novice parings), but because of what the expert does. Remember that much of what we call “expertise” takes place unconsciously. So the expert couldn’t put it into words even if they tried. But, perhaps, there is some value in less experienced programmers seeing how the expert works. Maybe that will give the less-experienced member of the pair a chance to pick up on things which the expert could never teach verbally.

A related point is that much of programming is about how the software is produced. Yes, you can learn from reading other people’s code after it’s finished (and we should do this more often) but I think we might learn more from observing how that code is produced – What kind of things did the author try as they worked? Where did they backtrack? How did unit tests guide their work? What are their special Google search tricks for finding relevant information?

(Note: don’t forget the conventional advice that “pair programming is best done by peers”. An expert-novice pairing is arguably not at all the same thing as regular pair programming.  My point here is that it might be a valuable tool for transferring the expert’s “automatic” (“non-concsious”) skills.  I would see it being used in moderation; rather than  for 6 or 8 hours a day like regular pairing.)

The mathematics of paired experts

I discussed my previous post with a friend before writing it. We agreed that experts can’t discuss the first part of their thinking (the automatic bit), and that discussing the second part (the effortful bit) takes longer because the experts have to slow down to the speed of human speech.  However my friend suggested that the collaboration will still pay off, due to improved quality of the final decision.

That could be a very strong argument if feedback from a peer was the only kind of feedback available.  But, it’s not.  Experts also get feedback from the situation, via unit tests etc.

Example: An expert is looking for the cause of a defect.  The bug is reproducible, but the expert doesn’t know what causes it.  Hunting for the bug is like a search.  At each step in the process, the expert chooses a “move” that will narrow the range of possible causes.  Moves may include setting particular breakpoints, looking for patterns in the inputs that cause the bug, stepping through the code, adding additional unit tests, and so on.  Each move narrows down the search space, until eventually the defect is found.  The better the move, the more it narrows the search space.  A really good first move might eliminate 90% of possible causes, leaving only 10% remaining.  A less efficient move may eliminate only 50% of the possible causes, leaving the other 50% still to be searched.

Question: if the expert is paired with another, will the pair choose substantially better moves?  Yes, they probably will.  After some discussion, the pair may choose a “90% move” (eliminating 90% of possible causes) while an expert working alone might only come up with a “70% move”.

But what about the time cost of the pair’s discussion?  In the time that the pair spend discussing one move, a solo expert might try several. Imagine that a solo expert can make two moves in the time it takes a pair to discuss one.  If the solo expert tries one 70% move, followed by another, they’ll cut the search space down to 9% of the original space. [ (100% – 70%)^2 =  30%^2 = 9%].   That’s about the same amount of progress as the pair’s “90% move”.   So the solo expert has produced the same result as the pair, in the same amount of time, but for only half the personnel cost.  If the solo expert’s cycle time is even shorter still, allowing them to try 3 or 4 things in the time that the pair tries one, the solo expert will outperform the pair in both cost and elapsed time.

In summary I suggest that: by using a shorter cycle time a solo expert might outperform a pair of experts.  This a special case of the general principle that “starting to iterate” often beats “improving the plan”.

So how should experts interact?

If experts avoid pair programming, will they end up working completely alone?  No.  I think there are at least two options worth considering:

Option 1: Expert “pair preview”

I’m suggesting this based on a real life example.  I’m calling it “preview” rather than “review” because it comes before the code is written.  I’ll anonymise it by changing the names to “Alice” and “Bob”.

Alice was (and still is) an awesome programmer, whose expertise I greatly respect.  She was working alone on a difficult part of the system.  Once Alice had an initial design in mind, she ran it by Bob for review.  So far, so good.  But the review is where things came unstuck.  Alice and Bob didn’t know Kahneman’s concept of effortful versus automatic thought.  Alice described her proposed design to Bob.  Bob understood it, but had a hunch that an alternative design would be simpler.  Bob didn’t know it, but his half-formed alternative design was generated by the automatic “part” of his mind.  Because it was automatically-generated, it seemed like nothing but a vague hunch.  Consequently neither Bob nor Alice gave it the attention it deserved.

In hindsight, they should have recognised Bob’s hunch for what it was: an instinctive product of Bob’s long expertise, and therefore something worth looking into.  Perhaps Alice should have spent a couple of days spiking Bob’s idea.  That would have tested the hunch, and by having Alice do the spiking (rather than Bob, who had suggested it), we would have leveraged Alice’s existing detailed knowledge of the problem space.  (Having Alice do the spike would have also made it psychologically easier for her to embrace the new idea, if it did indeed prove to be the best.)

Unfortunately, no such spiking happened, and the two programmers did not manage to have an effective discussion of the problem.  Alice spent about 5 weeks implementing her proposed design.  Some years later, it proved inadequate to the growing needs of the system, at which point it was re-implemented along the lines of Bob’s hunch – in only 2.5 days.

Option 2: “Expert Escalates”

Even experts get stuck.  Part of being a responsible expert is to realise when you’re not making productive progress, and seek out someone to bounce ideas off.  Perhaps they will see something that you haven’t, or spark some new ideas.

What about the evidence?

Two commenters on my previous post suggested that my concerns were all very well, but couldn’t be valid because the research shows that pair programming works.  I promised to respond with some comments on “the evidence”.

It turns out that the evidence is rather more mixed that you might suppose. Here’s a quote from the abstract of a meta analysis done by the excellent Simula Research Laboratory.

…between-study variance is significant, and there are signs of publication bias among published studies on pair programming.  A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high. The higher quality for complex tasks comes at a price of considerably greater effort
– from here, or alternate link [emphasis added]

The finding, that paired effort for complex tasks is much greater than solo effort, appears consistent with my above concerns and reasoning about paired experts.

Imagine two novice chess players, working as a team. (We’ll assume their opponent is a computer, so it can’t overhear them talk.)  Our two novices will benefit greatly from their collaboration.  They’ll discuss all their thinking – everything from possible moves, to correcting each others mistakes, to “can you remind me how a knight moves?”.  Working together like this they will make fewer mistakes, and generate better moves than each would have done alone.

But what if we paired two chess masters?  Scientific research proves that the thinking of experts is different. Much of it happens as automatic pattern recognition rather than conscious reasoning.  When a chess master looks at a chess position, (good) possible moves spring to mind immediately.  As described in my previous post, these “candidate moves” are generated directly by the brain’s underlying neural network.  Neural networks can’t explain their own reasoning, so the master doesn’t consciously know why those moves came to mind.  Of course, the moves are indeed based on the master’s long experience, but the mapping from prior experience to current ideas is not open to inspection by the conscious mind.

So how will our two chess masters collaborate?  Neither can explain to the other why they thought of particular moves – because the conscious, effortful part of the mind doesn’t actually know. So what will their conversation consist of?

• They can’t discuss the justification for their proposed moves, because as we just saw, they don’t know the justification.  (Several writers, including Nobel-winner Daniel Kahneman, point out that if you ask an expert, “Why did you suggest that?”, their effortful mind will indeed come up with a justification of the idea, but the justification is produced after the fact. It doesn’t necessarily match the invisible reasoning that originally created the idea.  In fact, I’d suggest that since the invisible reasoning consisted of pattern matching in a neural network, any attempt at a logical sequential description would be incomplete at best.)
• Instead, imagine that they pool their sets of candidate moves, and then discuss which of those moves to actually play.  This approach makes sense because, as we saw in the previous post, selecting one of the candidate moves requires effortful thought.  And effortful thoughts can be perceived and described by the thinker.  So let’s assume our two chess masters try to share these thoughts.  If they do, I believe they’ll run into another problem: verbalizing the thought process slows it down – a lot.  A master thinks through many possibilities: What would happen if I play this move?  How would my opponent probably respond?  How would I respond to that?  A master can process these “what ifs” relatively quickly.  Not nearly as quickly as the automatic thinking that produced the initial set of candidate moves, but much, much faster than the rate of human speech.   To share thoughts verbally, the master must slow down to speaking speed.  In summary, although it’s possible to verbalize these thoughts, there’s a high (performance) cost in doing so.

Pair Programming

Now let’s consider the analogy to pair programming. Novice programmers don’t yet make significant used of automatic pattern recognition, instead they rely more heavily on effortful thought.   Therefore their thoughts are open to introspection and can be verbally shared.  Experts, on the other hand, make significant use of the “automatic” part of their mind.  So most of their thought processes are not open to conscious introspection, and the remainder are so fast that verbalization carries a huge performance cost.

I think this may explain the confusion and frustration that some experienced programmers, including myself, feel when we’re asked to pair.  We can’t see how to map our automatic thought processes into the driver/navigator model of pair programming.  Furthermore we probably can’t explain what the problem is – at least, I know I couldn’t, until I read Kahneman’s effortful/automatic description of the brain.  His book points out that because automatic thought is, well, automatic, we lack awareness of its role in our thinking.  Since we lack awareness, we struggle to explain the difficulty we have with pairing. I hope that greater awareness of Kahneman’s work will give us a suitable vocabulary to describe the problem.

I also hope to stimulate discussion.  The thought processes of an expert, which elegantly combine the automatic with the logical, are extremely efficient. I believe pairing undermines this efficiency – by leading coders to create after-the-fact justifications of their automatic intuitions, and forcing them to unpack their conscious thoughts into spoken language.  I suspect paired experts may even find themselves forced back into novice-like patterns of thought.

What do you think, does pairing prevent experts from performing at their best?

Update, 31 Jan: I should clarify what I mean by “expert”.  I use the term in the sense used by Daniel Kanheman, Anders Ericsson and other researches into expertise.  But you might have seem some pair programming studies use the term “expert” in a different way, particularly those studies where all test subjects were students.  In those studies the word “expert” simply means “good performer” – a student who gets unusually good grades.  These cannot be experts in the Kahneman/Ericsson sense of term.  Developing that kind of expertise takes many years, far longer than any university degree.  Furthermore, Kahneman/Ericsson expertise is not simply about possessing knowledge, in the manner of an A student; instead it is about a mode of thought in which much of the knowledge is possessed and processed unconsciously, through automatic pattern-recognition honed by long experience.

Update, 15 July: Arlo Belshee replied with a very informative comment, below.  He addresses the concerns of this post as follows:

Pairings of experts can work very well. But they have to stop explaining why to each other, and just state partial what. Assume the other expert gets the why, or can create his own. Don’t slow down the thinking to talk; shorten the talking to fit within the fast cycles and focus on the part that will challenge the other guy’s thinking.  [emphasis added]

Back in 2000, there were very few other (documented) options.  But I did find the Maltron layout.  It’s cleverly designed to put common pairs of letters together, so you can just “roll” you hand and type them in a single motion – for instance “TH” can be typed in a single motion.

The problem with the Maltron layout is that it places ‘E’ on a special thumb key – which is only present on Maltron’s specialist hardware. (Very good hardware, apparently, especially if you have RSI, but beyond my budget at the time.)

So, I programmed the Maltron layout into my much cheaper Kinesis contoured keyboard, and then moved ‘E’ into a more normal place (because E just didn’t work for me on the Kinesis thumb keys, which are different from those on the Maltron.)  The change required moving a few other keys around to make room  After some analysis and testing, here’s the layout I ended up with. (The number row remains standard, and is not shown):

The key design ideas were to retain Malton’s ease of typing common letter combinations, to work the left hand slightly harder than the right (I had discomfort in my right at the time), and to keep things really simple for my pinky fingers, by giving them little to do except press home row keys. I even moved the Shift keys to the home row.

The layout has worked well for me ever since.  I like it, and typing no longer seems tedious. I don’t know how “optimal” the layout is, because back then analysis programs like Carpalx didn’t exist then – and I became hooked on the layout before I finished writing my own analysis program.  I’m sharing it now just in case anyone finds any of its ideas useful (and because, unlike in 2000, Maltron’s patent has now expired so I believe it’s fine to publish a modified version).

Warning: I am not an ergonomic expert.  In particular, note that I have put F and G into positions on the bottom row where the ring finger needs to curl to reach them.  Compared to the Maltron layout, mine therefore presumably puts more stress onto the tendon that is shared by the ring and long fingers.  The result feels fine to me, but had I known about the issue at the time, I may have done those keys differently.  I therefore feel obliged to point you that, if you choose to use this layout, you do so at your own risk.