The Smallest Agile Methodology That Could Possibly Work

People

You need 3 people, or 1 person with 3 hats, or 2 persons with 3 hats between them:

  • 1 person who knows what they want to have.
  • 1 person who knows about how to provide that.
  • 1 person with enough money to pay for it to be provided.

People Checklist

1) Do you have all 3 people or at least all 3 hats?

A: I don't have someone who knows what they want.

  • Consider a research project instead, in which you try to work out what you want.
  • Otherwise Stop Now.

A: I don't have someone who knows how to provide what I want

  • Find help. Otherwise Stop Now.

A: I don't know whether we have enough money.

  • Do the next 2 steps, Requirements and Priorities, and then do the Budget step. If you cannot afford to do those steps, then you do not have enough money and you should Stop Now.

Requirements

  • The person who know what they want must express what they want in enough detail that the person who is going to provide it can understand what they are supposed to be providing.

This sounds very simple. It is not. Many many conflicts in personal life, disastrous work projects, and famous cockups in politics follow from the fact that helping person A to express what they want well enough so that person B can deliver it for them is a skill that takes time to learn.

Solution: hire a Business Analyst to help person A to express what they want and to express it as requirements that persons A and B can both agree they understand and are happy with

Requirements Checklist

1) Does anyone involved have previous experience of how easy it is is to trip up on getting someone to express what they want correctly and in enough detail for someone to deliver it?

A: No

  • Find someone. Pay for their help.
  • Or, budget for doing everything 2 to 3 times in order to get it right. (Yes, 2 to 3 times is about right for your first ever project. It is not a worst-case.)

Priorities

  • The person who knows what they want must be able to express what their priorities are amongst the things they want. Either based on what they want fastest, or on what they value most.

This sounds very simple. It is. The only two things that can possibly go wrong are:

  • person A changes their mind.
  • you have not broken the work into small enough chunks. A small enough chunk is a chunk that the person doing the work is confident they can can complete in under a week or so.

Priorities Checklist

1) Can the person who knows what they want prioritise what they want and break it down into small enough chunks so that the person who knows how to deliver can confidently say, of at least the top 2 items, that they can do them in less than a week or so each?

A: No

  • Find someone to help with doing this.
  • Alternatively, budget for 2 to 3 times the cost of the first item for working out as you go along how to do it. If you have already budgeted 2 to 3 times cost because of no experience with requirements, that gets you to 4 to 9 times the cost for the first item. Yes, really.

Delivery

  • The person who knows how to deliver (build, buy, borrow, invent, bodge, whatever) what the person who knows what they want wants, does so.
  • [If there is more work involved than they can do in a week or so, they first chunk the work, in strict priority order, into batches of, say, a week's work.]
  • After they have completed as little of the first piece of work that is still showable to the person who knows what they want, they show it. The person who knows what they want confirm or corrects the understanding of what is wanted. The person who is delivering corrects course.
  • After they have completed the whole of the fist piece of work they show that.
  • [Or, in the larger chunked case, after the first batch they show the person who knows what they want, what they can have so far.]
  • The person who knows what they want then says, “yes I'll take that” or “that looks great, keep going” or “please change … <insert detail here>.”
  • If it is not finished, keep going. If it takes a long time, work to a regular rhythm.

Budget

  • After you have requirements and priorities, you may wish to plan a budget. A budget is often counted in money or in person-days of work.

You may think that offering a price for a job is what any experienced tradesman should be able to do. You may, or may not, be right. There are 3 main risks:

  • Nobody involved in the project has enough experience to estimate a fair budget, but no-one wants to admit to not having enough experience.
  • The people estimating the budget are pressured into underestimating the costs
  • The job, for reasons not yet foreeen, will incur unexpected additional costs.

Budget Checklist

1) Make sure you have reviewed each of the 2 to 3 times multipliers for inexperience in Requirements and Prioritisation.

2) Do you have someone on the project with enough experience to estimate a budget?

A: Yes

  • Is that person the person doing the work?
    A: Yes: Then accept their min/max estimates for costs and their choice of a prudent budget
    A: No: Then have them review their min/max estimates for costs with the person doing the work, let the person doing the work provide detail, and let them come to a consensus.

A: No

  • Find someone to help.
  • If you are able and willing to risk the cost of 1 or 2 weeks work, consider simply starting the work and reviewing progress after 1 or 2 weeks. Then, try again to estimate a budget.

Review

  • Whatever you do, review how you are working after 1 to 2 weeks. Ask yourselves questions to help understand your satisfaction and dissatisfaction, for instance:
    • What is going well?
    • What am I happy with or not happy with?
    • What can we do better?
    • What would I like to change?
      Then, make a plan to do at least one of the things you decided would make things better.

Note you are not asking, “is the thing we are delivering good?” You are asking “is the way we are working good?” The two things are closely linked of course, both in the positives and the negatives.

Review Checklist

1) Did you, in fact, do a review after 1 to 2 weeks?
2) Did you, in fact, choose at least one thing to improve?
3) If you are now 4 weeks into a project have you, in fact, improved the things you intended to improve.

Risk

  • A risk is something that might either stop your project or else make you wish you had not started it. Make a list of them.
  • All of the checklists above represent potential risks. If you did not have a whole-hearted pass for each item of each checklist, list that as a risk.
  • Each time you plan a piece of work, consider the associated risks and how you can make the risk smaller. If you don't really know how to, find help.
  • For risks that you cannot make any smaller, are you able to accept the price of that risk happening? Are you clear on who has what share of the price?

Risk Checklist

1) Did you make a risk list?

A: No

  • Stop Now.

2) Do you have someone on the project with prior experience in managing risk?

A: No

  • That is a risk. Get help.

3) Do the things you haved planned to minimise risk really minimise risk or are they just things you can write down even though they might have no effect in minimising the risk?

Considerations

  • It is a fact of craft work that the right answer is often, “Get someone with the experience to do it”
  • Minimalism is of little use to a beginner. Rather, they first need a step-by-step, then later they can understand how to try minimalism.
    This is why complaints that “<insert agile methodology name here> is terrible” are largely futile. All well-known agile methods gives a simple enough way to start off and then require you to review and change how you work.

Conway’s Law & Distributed Working. Some Comments & Experience

The eye-opener in my personal experience of Conway's law was this:

A company with an IT department on the 1st floor, and a marketing department on the 2nd floor, where the web servers were managed by the marketing department (really), and the back end by the IT department.

I was a developer in the marketing department. I could discuss and change web tier code in minutes. To get a change made to the back end would take me days of negotiation, explanation and release co-ordination.

Guess where I put most of my code?

Inevitably the architecture of the system became Webtier vs Backend. And inevitably, I put code on the webserver which, had we been organised differently, I would have put in a different place.

This is Conway's law: That the communication structure – the low cost of working within my department vs the much higher cost of working across a department boundary – constrained my arrangement of code, and hence the structure of the system. The team "just downstairs" was just too far.  What was that gap made of? Even that small physical gap raised the cost of communication; but also the gaps & differences in priorities, release schedules, code ownership, and—perhaps most of all—personal acquaintance; I just didn't know the people, or know who to ask.

Conway's Law vs Distributed Working

Mark Seemann has recently argued that successful, globally distributed, OSS projects demonstrate that co-location isn't all it's claimed to be. Which set me thinking about communication in OSS projects.

In my example above, I had no ownership (for instance, no commit rights) to back end code and I didn't know, and hence didn't communicate with, the people who did. The tools of OSS—a shared visible repository, the ability to 'see' who is working on what, public visibility of discussion threads, being able to get in touch, to to raise pull requests—all serve to reduce the cost of communication.

In other words, the technology helps to re-create, at a distance, the benefits enjoyed by co-located workers.

When thinking of communication & co-location, I naturally think of talking. But @ploeh's comments have prodded me into thinking that code ownership is just as big a deal as talking. It's just something that we take for granted in a co-located team. I mean, if your co-located team didn't have access to each other's code, what would be the point of co-locating?

Another big deal with co-location is "tacit" knowledge, facilitated by, as Alistair Cockburn put it, osmotic communication. When two of my colleagues discuss something, I can overhear it and be aware of what's going on without having to be explicitly invited. What's more, I can quickly filter out what isn't relevant to me, or I can spontaneously join conversations & decisions that do concern me. Without even trying, everyone is involved when they need to be in a way that someone working in a separate room–even one that's right next door–can't achieve.

But a distributed project can achieve this too. By forcing most communication through shared public channels—mailing lists, chatrooms, pull request conversations—a distributed team can achieve better osmotic communication than a team which has two adjacent rooms in a building.

The cost, I guess, is that typing & reading is more expensive (in time) than talking & listening. Then again, the time-cost of talking can be quite high too (though not nearly as a high as the cost of failing to communicate).

I still suspect that twenty people in a room can work faster than twenty people across the globe. But the communication pathways of a distributed team can be less constrained than those same people in one building but separated even by a flimsy partition wall.

References

A Manifesto for Post-Agile Software Development

In nearly 15 years since the Agile manifesto was penned, an entire generation of the software industry has grown up having known only allegedly 'Agile' methodologies. Their experience has not always been positive.

The 'new' criticisms made against agile – by those who have grown up with it, not those who opposed it in the first place – are rarely criticisms of the agile manifesto. They are, often, reactions against the (abusive) experience of being pushed into processes, behaviours & relationships which are unsatisfactory; whilst at the same being stripped of any power to improve them.

We should always react against people being pushed about, and made powerless.

A manifesto is a small thing. It can fall on deaf ears. It can be interpreted to mean the opposite of what was intended, it can be misused to manipulate people. But if we make the effort to keep in touch with each other, and to keep trying to re-state what was meant, it can continue to be a valuable guide. And so I propose a 15th anniversary postscript.

Manifesto for Post-Agile Software Development: A Postscript

  • The agile manifesto was not and is not a prescription for people to impose conformity, nor a tool for controlling people.
  • There is a deeper theme to agile. At the core it is based on trust and respect, promoting workplace relationships which value people. We oppose methods, structures and behaviours which reduce respect and trust, and which reduce people to assets with no power.
  • Agile will always demand shared learning and shared improvement. Without critical reflection and learning – both from their own experiences and from the wider community – teams cannot remain agile. Without improvement based on that learning, 'agile' becomes fossilization.
Manifesto for Agile Software Development: A Reminder of the Original

The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Comment

  • The phrase and much of the bullet point ‘There is a deeper theme...’ comes from About the Manifesto.
  • The emphasis on continuous learning is for some so obvious as to need no explanation. But some are stuck in a so-called “agile” process which they are powerless to change or improve. The irony of naming such an structure “Agile” would be funny if it weren't so painful.
  • Ron Jeffries' response to some criticisms of Scrum was: “The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it.”
  • To cry out that without continuous learning and change there is no agile, can be a powerful tool for the disempowered.
  • Calling for change in a broken process can become a step towards changing broken relationships.
  • Beyond “Deliver working software. In a team.”, I see two essentials to agile:
    • Treat people well
    • Never stop learning
    Each of these two is only truly possible when the other is also practised.

Go Further, Do Better

  • Alastair Cockburn was ahead of the game and has been teaching  Heart of Agile for a while. He has four essentials: Collaborate, Improve, Deliver, Reflect.
  • Ron Jeffries and Chet Hendrickson's post on turning the dials up to 12  starts from, ‘Al Smith once said “The cure for the ills of democracy is more democracy”. We say The cure for the ills of “Agile” is more Agile.”’ and sketches what turning the dials to 12 might mean.
  • Gabrielle Benefield's “Mobius Loop” uses a different language and stipulates a process. At first glance it is much more achievement focussed. The four “corners” of their figure 8 loop are Why & Who; Outcomes; Deliver; Measure & Learn; and the centre crossover of the loop is Options.

An older bibliography

Draft – Comment & Contribution Welcome. Updated September 2019.

The Yes, The No and the Painful: using, and failing to use, estimates for a no-go decision

@AgileKateOneal recently asked for examples of effective estimate use in medium/long-term planning.

Example 1: Back-of-the-envelope Go/No-Go Decisions

Making a no-go decision sprang instantly to mind. Many such decisions are casual and quickly forgotten: the back of an envelope calculation which says that an idea is well beyond what we can afford; and the conversation moves on. But that estimate may have saved you from months of wasted effort.

An NoEstimator might object that one could profitably try out something rather than nothing. Which is sometimes true, but creative thinkers in commerce & IT can always generate a hundred more ideas than a team can try out. You can't try out everything.

Example 2: Small UK charity looking at CRM options

in November last year I worked with a small UK charity, www.redinternational.org who were badly in need of some kind of CRM software to keep in touch with supporters and project partners. They were running largely on spreadsheets built from downloaded reports from virginmoneygiving.com / mydonate.bt.com etc. They also had an Access database with a fair amount of donor & similar data in it.

Question: Is it better to pay for a CRM solution — typical charity starting price £10,000 going up to easily £100k – or get someone to do enough work on the Access database to make it a usable solution?
My Answer: I first spent some time discovering and documenting their main use-cases (to clarify: their 'business' use cases, that is the things the charity had to do whether manually or with IT). I gave that picture to the CRM providers so that they could give us a sensible proposal. And I worked out an estimate for extending/developing the Access database. Based on that, we could see that a CRM consultancy/solution looked like £10-£20k (5 year cost) and the DIY-option about 200-400 developer days.

Even with this level of accuracy it was good enough to see that DIY should be a no-go. I did not expect this. I thought that the charity's actual requirements were sufficiently small that we could do something useful for a few thousand pounds. But two hours spend going through their use-cases on my estimating spreadsheet showed me that I was wrong. So, I recommended the best value CRM option.

This, I think, is planning 101: a couple of hours working through the detail on paper is a lot cheaper than running the experiment; but can be enough to make a probably-good decision.

Example 3: Provide a system to automate a small team's manual processes for a capped price

This was for a financial services company in 2013. The team were working on PPI claims for an insolvency practitioner (obliged to pursue potential claims that might bring in some money for their clients' accounts) and had about ten thousand potential claims with hundreds per month being added. They had been working manually on spreadsheets for over a year.

I spent 4 days on analysis and listed a set of use-cases that covered the processes end-to-end; and I estimated that a suitable system could be done for about 40 days development work. The estimate cost about 3 or 4 hours on top of the analysis.

The contract to provide was capped-price. The customer was not open to a no-estimates approach. And I accepted being bargained down to below my estimate (Doh! I hear you say. Quite so). The actual cost came out close to (but above) my original estimate, but could have used another week's work to make it user-friendlier.

The better course would have been to use the estimate/budget mismatch to declare a no-go rather than accept a reduced budget. This might have resulted in the client agreeing to go ahead anyway (which might in turn have led to a no-estimates approach to the work). Or it might have led to no contract. Either way would have been less painful and more controlled than over-running the budget.