Category: LifeUniverse&Everything

The Smallest Agile Methodology That Could Possibly Work

People

You need 3 hats. That might mean 3 people, or 3 groups of people, or 1 or 2 people wearing more than 1 hat:

  • 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 someone to wear each of the 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.

You’re Only As Good As Your Last Backup

… is a necessary rule of thumb for computer-based knowledge & design workers. But add the lesson of cloud computing:

Backups: If you don't have 3 copies, you aren't serious.

The standard redundancy for cheap cloud storage options is 3 copies. Anything less is reduced redundancy, sold at discount. You should have at least 2 backups, for instance both a home backup disk and a cloud drive or repo.

A big win, when you plan for multiple copies, is that you no longer need any of them to be highly reliable. What matters more is, how fast can you make another copy if one copy goes down?

The Isomorphism is not the Terrain

—Draft—

We do not often think of mathematical models as tools so much as the embodiment of a theory. We take formulae such as f=ma to be the theory, not a tool for understanding the theory. Yet mathematical formalisms are chosen for their user-friendliness —their tractability and solvability— just as much as for their correctness, which suggests that theories which rely on them may be calculable yet less than true.

Shannon's Information Theory, for instance, provided a tractable solution to the problem of what is the very best rate of message transfer we can achieve over a wire, and has been so widely re-used one might think that all the world's an abstract communication channel.

By contrast, Sundman's 1912 infinite series solution to the three-body problem languishes in obscurity not because it is wrong, but because it is incalculable. Instead, dozens and hundreds of models of special cases of the 3-body problem have been published since then, each having the virtue of user-friendliness: you can actually use them to calculate something.

With a theory such as Shannon's, usability leads to enthusiastic adoption and enthusiastic adoption leads to a sense of well-being and belief we can solve all the things with this one simple trick.

What it does not lead to, is a careful enumeration of assumptions made in the adoption of a model.

This is fine for the engineer who just wants to calculate and get a result. It is less fine when the scientist enthusiastically declares that their mathematical model solves all the philosophical problems too.

For the philosophical problems are rarely captured in the mathematical model. They are more usually either captured or carefully avoided in some well-worded definitions and assumptions in the preamble and the prerequisites of the model.

For instance, Shannon defines a measure of information: “If the number of messages in the set [of all possible message you might want to send] is finite then this number or any monotonic function of this number can be regarded as a measure of the information produced …”

The monotonic function chosen is the logarithm and leads to a definition of Shannon Information as the negative log probability of choosing that message out of all possible messages. This definition has been extremely usable because it is tractable: you can compute with it.

Sadly it has only a tangential relationship to the meaning of “information”, as Shannon noted: “Frequently messages have meaning … These semantic aspects of communication are irrelevant to the engineering problem.”

Imagine for instance, you drive from Durham to Barnard's Castle and lost at a crossroads, ask a farmer for directions. He draws his fair 6-sided die from a pocket, tosses it, and reports, “It's a 6.”

Per the mathematical model, the farmer is rather informative. He has conveyed 2.6 shannons of information. Had he instead said, “Ah yes, for Barnard's Castle you want to turn left here” that would have conveyed barely 2 shannons of information (less, if “do a U-turn” was not on the table) and so been less informative.

The model is not reality. Information in the model is not information in the real world. Rather, information in the model is something that is isomorphic to something that is quite close to information in the real world.

The model definition of information — negative log likelihood — is certainly good and very usable for a definition of the maximum possible information rate achievable over a communication channel. It has also turned out to be very … usable … in related applications. Because the idea of an abstract communication channel can be used for a wide range of natural phenomena, and so a theory of them is widely useful.

But usability of a mathematical model leads to enthusiasm and enthusiasm may lead to completely ignoring niceties such as the relationship between the model and reality.

We could go with the flow and allow the model definition of information to override our previous understanding, and declare that information is negative log likelihood of selecting a particular message from a finite set of messages. It's tractable so it's true. After all, no-one likes to be stuck with intractable problems. Sundman's result was big at the time, but no-one remembers him now.

A mathematical model is a structure. A particular structure is picked out because it is user-friendly and because an isomorphism exists which maps onto it something that is close to something we are interested in. Shannon information is tangentially close to real information: there's a vanishingly small place where it's an exact match, a fuzzier area where it's very close and lots of places, such as en route to Barnard's Castle, where it's just wrong.

It seems an elementary mistake to say, “this structure lets us calculate stuff and therefore reality is exactly like this” yet it happens all the time. As people learn a result calculated using information theory, or Turing computability, or Bayes theorem, they go into the world convinced they're seen the light.

They've seen the light of a structure that is isomorphic to something that is close to something that interests us. They may never notice the assumptions and definitions required for the structure to count as a map of reality.

The isomorphism is not the terrain.