Quick notes on contracts

At today’s IITP Lightning Talk/Panel Discussion, I promised to post some links about how each agile project tends to need its own process, tailored to its own particular situation. Here are those links, and some rough notes on a few other things too:

Tailoring process to each project

The main author on this is Alistair Cockburn. He’s researched and written about why each project needs its now process, and how to cost-effectively do that process configuration. Here’s a quick outline of how to do it, and here’s a much more in-depth description (complete with links to research).

By the way, such tailoring is potentially a challenge to formulating a contract (as per today’s IITP panel) however in practice I think most of the tailoring will focus on a level of detail below what the contract would cover.  The contract would work at a higher level, specifying the overall approach to managing time, scope, cost, risk etc.  While there are still many choices to be made at that higher level, it seems realistic to me to pick one “flavour” of agile for contractual purposes, and to expect to continue with that overall flavour throughout the project.   I posted some outlines of a few “flavours” here, as relates to scope and cost management. After today’s panel I really need to do a more detailed follow-up post, covering more than just scope and cost!

Norwegian Agile Contract

Here’s a link to that standard agile contract, from Norway, which I mentioned.

Feature thinning

There are some good links to this in the “further reading” section of this page.  BTW, the page itself is about agile with fixed scope, and some ways to approach it.

Agile is an umbrella term

There are many “defined” types of agile, and a great many others that are not explicitly defined.  The defined ones include XP, FDD, Scum, Crystal, DSDM, and Adaptive Software Development.  I mention this just to illustrate the variety of what “agile” means.

Just as an example, FDD is quite different from the better known Scrum and XP variants.

The tension between being specific and being flexible

When you start out with agile, it helps to have a very specific formulation of what to do. Basically a set of rules.  As you gain experience, it makes sense to start to look beyond the initial set of rules.  This causes difficulties – for instance when someone experienced (e.g. me, today!) says that agile can be many different things.  That’s true, but not very helpful as a starting point for organisations that haven’t tried it yet!

Authors addressing this include Andy Hunt and Jeff Patton.

This tension between being specific and being flexible is, I believe, one of the key challenges in sharing ideas about contracts for agile projects.  Maybe that will be a blog post another day…

Your thoughts on a simple waterfall vs agile comparison

I’m seeking feedback on the following comparison of agile vs waterfall(*)   The comparison is to be used as background information for a panel discussion on agile contracts, so it emphasizes those aspects which I felt were most relevant to that topic.  I’ve tried to keep it agnostic as to the exact flavour of agile to be used.

Waterfall Agile
Requirements always identified up front Requirements may be identified up front, in a concise list
Users sign off documents Users try out the software regularly
Integrate and stabilize at end Integrate and stabilize frequently
Progress is measured by milestones Progress is measured by % complete (with continuous testing)
Reduce likelihood of bad predictions through planning & signoffs Reduce impact of bad predictions though fast detection & response
Value: delivering on promises Value: openness

What are your thoughts?  I’m particularly interested in your thoughts on the second-to-last line, about the approach to “bad predictions”.  Does that make sense as it stands?  Do I need to add text explaining that I’m talking about all kinds of predictions – not only how long things will take to build, but also what should be built?

(*) Yes, I know, presenting agile and waterfall as opposites is logically flawed, since there’s no “opposite of agile“.  But we need something as background/context for the panel audience.

Great software pricing research

Most software engineers have an intuitive sense that the industry is approaching pricing and estimation in the wrong way.  But we’ve lacked data to prove, or disprove, our intuitions. Magne Jørgensen and his colleagues, at the Simula Research Laboratory, are doing awesome research to fill the gap.

Some of what they’ve found will support your intuitions (e.g. the danger of price as a selection tool) but some may surprise you (you might have some bad estimation habits). Here are some highlights, just from the last few years:

A Strong Focus on Low Price When Selecting Software Providers Increases the Likelihood of Failure in Software Outsourcing Projects.  Empirical evidence for the Winner’s Curse in software development.

The Influence of Selection Bias on Effort Overruns in Software Development Projects. More on the winner’s curse.

What We Do and Don’t Know About Software Development Effort Estimation. The title says it all!

Myths and Over-Simplifications in Software Engineering. A timely reminder of the dangers of confirmation bias when considering how we should go about software development. Similar subject matter to Laurent Bossavit’s Leprechauns of Software Engineering.

The Ignorance of Confidence Levels in Minimum-Maximum Software Development Effort Intervals.  A study confirming a point which Steve McConnell makes early in “Software Estimation: Demystifying the Black Art” – namely that in practice “90% confident” requires a much wider range than we think it dos.

Software Development Effort Estimation: Why It Fails and How to Improve It. The third-to-last slide (how to get percentage confidence intervals without the problems of min-max approaches) is excellent. Just one catch, which would have affected many of the teams I’ve worked in.  The technique requires 10 to 20 prior projects, each with estimated and actual costs.  I suspect that many estimators don’t have ready access to such data. (Maybe organisations need to improve how they keep these records, but that’s not the whole solution. Some teams simply don’t have enough history, IMHO).

Better Selection of Software Providers Through Trialsourcing. “In this article we show that differences between software providers in terms of productivity and quality can be very large and that traditional means of evaluating software providers … fail to separate the competent from the incompetent ones.”  Describes using trial projects to select suppliers.

Numerical anchors and their strong effects on software development effort estimates.   Text not yet available.  Looks like a good one though.  In the meantime, here’s Wikipedia’s background material about anchoring.

First Impressions in Software Development Effort Estimation: Easy to Create and Difficult to Neutralize.  Another on anchoring (this time with full text).

From Origami to Software Development: a Review of Studies on Judgment-Based Predictions of Performance Time.  Interesting title, but no full text yet.


People Skills, distilled

Here’s a 6-point summary of my “People Skills” talk.  The points are in pairs, two about negotiation, two about the “arrows of communication”, and two about mindset.

Identify interests
Generate options

Share your stories
Ask for their experiences

Don’t try to win the meeting
Test your assumptions

Note that there’s far more to people skills than these 6 points. The book Crucial Conversations has many more learnable skills. (About 25 in total).  The 6 I’ve listed here are the ones that seem particularly important to me, and which flow together (somewhat) in the structure of the talk I give about People Skills.


Identifying Interests

A key part of good negotiation, or negotiation-like discussions such as those about design of a new product, is identifying the interests of all parties.

I suspect that there’s a very common mistake made, when identifying interests. That is to assume what the other person’s interests are, instead of asking them.

But it gets worse. In my opinion, assumptions are particularly dangerous when they are assumptions about the other person’s motivations or attitudes.  E.g. “He wants all the glory for coming up with the idea”.  There’s several things wrong with assumptions of this type:

  • Firstly, they distract attention from the real interests that we should be focussing the discussion on: what business benefits does the other person want to obtain?
  • Secondly, they encourage us to fall back into a Unilateral Control mindset.  I find it better if I simply don’t make any assumptions of this type.  Instead of making assumptions about the other person’s motives, I focus on the actual business problem at hand, and seek to learn more about their practical interests in relation to the business problem.

As you talk (and listen) openly about the actual business problem, you’re likely to find that the other person’s motives are not too bad.  No-one comes to work to deliberately do a poor job. On some level, virtually everyone wants a good outcome for the business they work for.  Making negative assumptions about their motives is usually mistaken and almost always a distraction and waste of your time.

Mindsets, distilled

It’s not easy to summarise the wonderful work of Chris Argyris. His work on mindsets, namely the Unilateral Control mindset and the Mutual Learning mindset, seems particularly difficult to summarise – and yet it’s so vitally important to anyone who works with other people.

Here’s my latest attempt, at approachable wording for the two mindsets.

Unilateral Control:  (common, and counter-productive)

“Guess what they’re thinking.
Don’t trigger negative emotions.
Get them to do what you want”.

Mutual Learning: (works better)

” Test assumptions (about what they’re thinking)
Share valid information.
Seek well-informed agreement.”

(In this context, “unilateral” simply means “one sided” and “mutual” means “we’re all in this together”. )

The dynamics of trends

I think this lovely quote, originally about scientific research, probably explains a lot about how trends come and go in software engineering.

after a new paradigm is proposed, the [publication]process is tilted toward positive results. But then, after a few years, the academic incentives shift—the paradigm has become entrenched—so that the most notable results are now those that disprove the theory.

From http://www.newyorker.com/magazine/2010/12/13/the-truth-wears-off . The article quotes a study by John Ioannidis, who writes:

It can be proven that most claimed research findings are false…

…for many current scientific fields, claimed research findings may often be simply accurate measures of the prevailing bias.

From http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1182327/ (Emphasis added)

An Experiment in Think-First Development

I conducted an experiment today. I chose a problem which Ron Jeffries solved with TDD. I took the opposite approach.  I sat for about 5 minutes and thought about the solution.  Then I wrote down the code, added a unit test, ran the test to find the errors (there were 3), added one more test, re-ran both tests, and I was done.

What did I learn?

  1. I’m reasonably happy with my “think first” solution.
  2. I like it because it represents the solution in a very direct way.  It’s something my mind can relate to.  The design embodies a “Unit Metaphor”.  I just made that term up ;)  I mean a small-scale version of XP’s System Metaphor – a way of thinking about this unit of code that makes sense to me, as a human.
  3. I don’t think I would have come up with such a direct solution if I’d worked test-first.  I believe I would have been led to the solution in a much more round-about way,  and vestiges of the journey would have remained in the final code.
  4. During TDD the code “speaks” to you.  But I question whether it speaks with a sufficiently creative voice.  Can it really “tell” you a good Unit Metaphor?  Or does it merely tell you about improved variations of itself?  If the Unit Metaphor is missing at the start, will it remain missing for ever? (And it probably will be missing at the start, because as a good TDD practitioner you deliberately didn’t think about it at the start, right? ;)
  5. As an aside, maybe this example problem is too small.  Ron got a 6000-word blog-post out of it, but its it really a big enough problem to serve as a test-bed of design and coding techniques?  Maybe our online discussion about TDD is skewed by the inevitable necessity to use relatively small examples.  I don’t know….

What I do know (or at least strongly believe ;-) is that a certain degree of directness helps humans understand code, and a little up-front thought may help to create that directness. The trick, I suggest, is to seek a simple Unit Metaphor during your up-front thinking.

The Design Problem

The problem posed was to write code to create textual output in a “diamond” pattern, like this:

- - A - -
- B - B -
C - - - C
- B - B -
- - A - -

(spaces added here, just for readability).

Obviously it should be parameterized, to produce diamonds of various sizes.  The next size up has a “D” line in the middle, surrounded by two “C” lines.

This coding problem was previously mentioned by Seb Rose and Alistair Cockburn.

Comparing the Solutions 

(If you want to try writing your own solution, best to do that now, before following the links to Ron’s solution and mine).

Ron’s solution is in Ruby.  You can find it at the bottom of this page.

My solution is in C#, since that’s the language I know best.  You can find it, and the two unit tests, in this text file.

Comparing the two, Ron’s looks more visually appealing  at first glance. The methods are shorter, like methods are “supposed” to be, and it’s doing some clever stuff with generating only one quarter of the output and using symmetry to produce the rest.

Mine looks uglier.  The implementation is one 24-line method. (I think I’ve violated a few published coding standards right there!). But it does its work in a very straightforward way. It builds up the diamond one complete  line at a time.  It directly models the current width of the diamond, by keeping track of the edge’s “current distance from the centre”.

My, totally biased(!), view is that the direct, single-method implementation is actually easier for humans to make sense of and reason about.

BTW George Dinwiddie posted another solution here.

An Aside About Timing

It’s worth noting that my initial 5 minutes of thinking produced the general shape of the solution, but not all the details.  The actual coding, including the two tests, took about 18 minutes – an embarrassing proportion of which was consumed by the three bugs and with details of C# that I really should have known (e.g. I felt sure there was a built-in “IsOdd” method somewhere for integers.  But apparently there’s not.)

I think I would have taken longer to produce a solution with a pure TDD approach.  Of course, I can’t prove that because, as Ron points out in his post, its impossible for one person to realistically test two different approaches to the same problem – since any second attempt is polluted by knowledge gained in the first.


For the record, I also enjoy test-first. Particularly on really complex problems, or on simple ones when I’m suffering from writer’s block.

What I object to, and feel uncomfortable with, is the common implication that there’s only one true way to build software. People differ. Projects differ. Elements within projects differ. We should embrace those differences, and draw on our full range of tools – including up-front thought.

Stories and Social Capital

The telling of true stories crops up again and again as a useful interaction technique. It’s easier to raise a dissenting view if you do so my telling a true story; and it easier for others to listen to you. Compare “Your idea won’t work”, with, “At my old job, we tried something similar and found that it was really hard to write queries against the data because…”

Some years ago I enjoyed reading the book In Good Company.  It highlighted the power of stories.  Now, years later, I can still remember key examples that were mentioned in the book. (Which illustrates another benefit of stories – they are memorable.)

From the back of the book:

“In Good Company is the first book to examine the role that social capital — a company’s “stock” of human connections such as trust, personal networks, and a sense of community — plays in thriving organizations.”

Sharing stories are a key tool in building social capital.  But there’s also much more to building social capital; much more that can and should be done to build up trust, personal networks and a sense of community.  The authors admit that many of their suggestions can seem like common sense.  But like many common sense ideas, they are not so commonly followed!  I’ve been lucky enough to spend the last few years in a team with excellent social capital… and it’s been a huge boost to our success and happiness. This stuff really matters!

Tame the spaghetti meeting

At the start of my last project, we found ourselves not with the infamous “spaghetti code” but with it’s interpersonal equivalent: spaghetti meetings.  While the group was discussing a topic someone would inevitably say, “Oh, that reminds me of…” and launch into a description of some related, but different, topic that.  This was disruptive and cut off those that were still waiting to speak on the initial topic.

Eventually I encouraged the team to use a technique which I’ve been using myself for some years.  When a related topic pops into my head in a meeting, I usually

  1. Note it down on a piece of paper
  2. Let the discussion on the current topic run its course. This allows everyone who wanted to speak about the current topic to get their chance, and the group to benefit from their thinking.  It also feels more inclusive. Once we’ve finished with the current topic…
  3. …then I introduce my new topic.

This simple technique seems to make a big difference.  Of course, it requires people to bring pen and paper to meetings and informal discussions.  With paper for notes there’s no need to blurt out something “just before I forget”.

You might notice that this is similar to the “parking lot” some meeting facilitators put up on a whiteboard.  Personally, I believe the pen and paper technique is even better.  With each person silently running their own personal parking lot on paper, there’s no interruption to the group at all.