Agile outside of IT

The Agile Manifesto was created for software development, but there are many lessons we can use outside of IT. This is not to say I think we should “be Agile” in everything.

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

Individuals and interactions over processes and tools

Careers such as counselling and caring are starting to do this more. There is more of a focus on patient-centred leadership. In Nordic countries, there is a great company with 19,000 employees called Attendo, which focuses on empowering the individual in order that:

  • Every individual feels participatory and listened to.
  • Every individual feels they are met with respect and warmth.
  • Every individual feels supported in achieving independence.
  • Every individual feels safe and secure.
  • Every individual perceives that their quality of life is positively affected.

Sound familiar? For any creative workers, this is great for autonomous motivation.

Working software over comprehensive documentation

This one is only literally applicable to software, but the focus on value delivery is relevant as part of Lean Startup, for example. This is a way of running startups to help them be successful and less wasteful. Also notably, the value focus of agile can be seen in manufacturing (eg lean, kanban).

Customer collaboration over contract negotiation

Again Lean Startup advocates this. Big companies are trying to do this more too. For example, Diagio (the drinks company) have a “Customer Collaboration Centre” where they involve customers in their strategies.

Responding to change over following a plan

This area is one where I feel there is a lot of benefit. The world still works on a plan-based mechanism. We vote our governments in for fixed lengths of time, we demand financial plans, and we expect deadlines to be delivered to. Psychologically, embracing change can be hard. According to this random website I found, there are benefits of responding to change:

  • Staying current
  • New opportunities
  • Encouraging Innovation
  • Increased efficiency
  • Improved attitudes

The reality is that everything that survives must respond to changing environment. (Human) evolution is a great example of this. Medicine has always been “inspect and adapt”. Even the most conservative of organisations, the Vatican, responds to change, as demonstrated by their use of new latin translations during Mass. McCain Food, as one of innumerate corporate examples, responded to changing customer (and legislative) demands for healthier food by using sunflower oil, rather than vegetable oil. Creating a culture where we respond to change over following a plan will lead to better outcomes in almost any space.

If you can think of something where following a plan makes more sense than responding to change, or any other good counterexamples, please let me know in the comments below.


DNA sequencing: Creating personal stories

Data matters. A great example of a smart use of data is genetic sequencing. This involves 3 billion base pairs, although scientists only know what around 1% of these do. The arguably most important ones are to do with creating proteins. By looking at people with traits, diseases or ancestry, scientists have been able to pick out those sets of genes which seem to match with those attributes. For example, breast cancer risk is 5 times higher if you have a mutation in either of the tumour-suppressing BRCA1 and BRCA2 genes.

Due to science, there are now commercial providers of DNA sequencing available, such as 23andme. They market this as a way to discover more about your ancestry and any genetic health traits you might want to watch out for. To try this out, I bought a kit to see how they surfaced the data in an understandable way. The process itself is really easy, you just give them money and post a tube of your spit to them.


After a few weeks wait for them to process it, you can look at your results. Firstly, you have your actual genetic sequencing. This is perhaps really only of interest (or any use) to geneticists. As part of their service, 23andme pull out the “interesting” parts of the DNA which have been shown (through maths/biology) to correspond to particular traits or ancestry.

They separate this out into:

  • Health:
    • Genetic risks
    • Inherited conditions
    • Drug response
    • Traits (eg hair colour or lactose tolerance)
  • Ancestry:
    • Neanderthal composition
    • Global ancestry (together with a configurable level of “speculativeness”)
    • Family tree (to find relatives who have used the service too)

Part of what is smart about this service is that while it uses DNA as underlying data, it almost entirely hides this from the end user. Instead, they see the outcome for them. They have realised that people don’t care about a sequence like “agaaggttttagctcacctgacttaccgctggaatcgctgtttgatgacgt” but they do care about whether they have a higher risk of Alzheimer’s. Because some of these things are probabilistic, they also put a 1*-4* scale of “Confidence”: again this is easy to read at a glance. It isn’t very engaging, but it looks something like this:

Screen Shot 2016-09-26 at 16.18.08.png

Perhaps more visually interesting is the ancestry stuff. Apologies that my ancestry isn’t very exciting:

Screen Shot 2016-09-26 at 16.20.14.png
Ancestry, set to “standard” speculation levels (75% confidence)


I hope this has been interesting. Commercial DNA sequencing is a real success story not just for biochemistry and genetics, but also for the industrialisation of these processes and the mathematics and software that makes it possible. The thing that is especially cool, according to me at least, is the ability to make something as complex as genetics accessible, understandable and useful.

Proof: Little’s Law (why to Limit WIP)

Little’s Law states that:

The average number of customers in a queuing system = ( the rate at which customers enter the system ) x (the average time spent in the system)

Typically this might be applied to things like shoppers in a supermarket, but here we will focus on the application to software development. In a software development world, we often write it the same statement with different words, thinking about tasks:

Average Work in Progress = Average Throughput x Average Leadtime

Little’s law is beautifully general. It is “not influenced by the arrival process distribution, the service distribution, the service order, or practically anything else”[1]. This almost makes it self-evident, and since it is a mathematical theorem perhaps this is correct, since it is true in and of itself. Despite being so simple to describe, the simplest generalised proof that I have been able to find (and which we will not tackle here) is however trickier, since a solid grasp on limits and infinitesimals is required. Instead, we will consider a restricted case, suitable for most practical and management purposes, which is the same equation, with the condition that every task starts and finishes within the same finite time window. The mathematical way of saying this is that the system is empty at time t = 0 and time t = T, where 0<T<∞. A diagram to show this system might look something like this:

Tasks all starting and finishing between t=0 and t=T


For our proof, we start with some definitions

n(t) = the number of items in the system at time t

N = the number of items that arrive between t = 0 and t = T

λ = the average arrival rate of items between t = 0 and t = T. The arrival rate is equal to the departure rate (sometimes called throughput), since the system is empty at the beginning and the end.

L = the average number of items in the system between t = 0 and t = T. This is sometimes called “average Work in Progress (WIP)”

W = the average time items spend in the system between t = 0 and t = T. This is called W as a shorthand for wait time, but in software development we might call this leadtime

A = area under n(t) between t = 0 and t =T. This is the sum of all the time every item has spent queuing.

Using this notation, Little’s law becomes

L = λ x W

which we will prove now. The following equations can be assembled from these definitions. We will need to use these to assemble Little’s Law.

  1. L = A/T (average number of items in the system = sum of time spent / total time)
  2. λ = N/T (average arrival rate = total number of items / total time, since every item leaves before t=T)
  3. W = A/N (average time in system = sum of all time spent / number of items)

We can now use these three equations to prove Little’s Law:

L = A/T                                                from (1)  

   = (A/T)x(N/N)                                since N/N = 1

   = (N/T)x(A/N)                                 by rearranging fractions

   = λ x W                                             from (2) and (3)

This is what we wanted, so the proof is complete.

What does this mean?

A trick to getting good outcomes from Little’s Law is understanding which system we want to understand.

If we consider our queuing system to be our software development team, our system is requirements coming in, then being worked on and finished. In this case, W is the development time, and each item is a feature or bug fix, say.

To have a quicker time to market, and to be able to respond to change more quickly, we would love for our so-called “cycle time” W to be lower. If the number of new features coming into our system is the same, then we can achieve that by lowering L, the average work in progress. This is part of why Kanban advocates “limiting work in progress”.

Alternatively, we can consider our queuing system to be the whole software requirement generation, delivery, testing and deployment cycle. In this case, we might have W being the time taken between a customer needing a software feature to it being used by them. By measuring this, we get a true picture of time to market (our new W, which is true measure of “lead time”), and we with some additional measurements we would be able to discover the true cost of the time spent delivering the feature (since our new A is means total time invested).

Outside of the development side of software, we can apply Little’s Law to support tickets. We can, for example, state how long a customer will on average have to wait for their query to be closed, by looking at the arrival rate of tickets and the number of items in the system. If there are on average 10 items in the queue and items arrive at 5 per hour, the average wait time will be 2 hours, since the rearrangement of Little’s Law to  L/λ = W gives us 10 / 5 = 2.

I hope that was interesting, if you would like me to explain the proof in the general case, let me know in the comments. I think it would be about 10 pages for me to explain, so in the spirit of lean I will only do this if there is a demand for it.

Anti-agile conferences

Let’s start by looking at what a conference is…


Definition: “a formal meeting of people with a shared interest, typically one that takes place over several days.”

Agile On The Beach Conference (2013)

The features:

  • Topics shape the audience
  • Rigid program
  • You know what you are getting
  • Often high profile expert speakers
  • Accessible for old-school thinkers
  • Can be expensive for participants



Definition: “A loosely structured conference emphasizing the informal exchange of information and ideas between participants, rather than following a conventionally structured programme of events.”

Manchester BarCamp 7 (2016)

The features:

  • Audience shape the topics
  • Flexible (unknown) program
  • Lean
    • Not so much preparation for speakers
    • Law of two feet: If a session is not useful to someone they will leave, which is less wasteful
  • Variable quality speakers
  • Everyone participates, which is more effective for learning
  • Often cheap/free for participants

Which is more agile?

I will now attempt to show that agile conferences are a paradox. I know it may seem odd applying agile (for software development) to something like a group of people communicating, but let’s give it a go. Perhaps we can compare some traits of Conferences and Unconferences to the Agile Manifesto:

  • Individuals and interactions over processes and tools
    • Unconference is more agile, since unconferences are attendee-led
  • Working software over comprehensive documentation
    • Arguably both styles similar with an Unconference perhaps slightly better, since conferences often document lots in their preparation
  • Customer collaboration over contract negotiation
    • Unconference is certainly better here, since unconferences are attendee-led (and the law-of-two feet means that “customers” don’t get what they don’t want)
  • Responding to change over following a plan
    • Unconference is massively better here

I put it to you that as agile evangelists, we shouldn’t be encouraging traditional conferences, which are prescriptive, irresponsive, contractual and process-driven.

Instead, we should support unconferences, perhaps by organising, participating or sponsoring them.


Pilates changed the way I run

I tried a Pilates video a few weeks ago. I know that might not be very manly, but I thought I would try something different to shake things up. I hoped it would be a bit like yoga, and help with my core strength.

It had an unexpected benefit… I discovered Lateral Breathing. This involves breathing deeply and engaging core muscles, in order to maximise oxygen exchange. I’d strongly recommend it, it feels great! There are apparently lots of benefits, and the main one I’ve noticed is to do with running. And it isn’t just in the way it feels (since I track everything I have data):

  • Over the same course…
  • My heart-rate is very similar…
  • In exchange for a 1% higher cadence…
  • And 30secs/mile faster speed.
  • This is much more than the improvement I usually see in a similar 2 weeks of training.

So yeah, try it!

Smoggy running in Chongqing last year

You might be wondering why I’m talking about this. Well, it feels like innovation. You might’ve read last week’s post about Active Procrastination: you never know what might help you approach a problem in a different way.

Innovation often occurs at the crossings between two disciplines. Some varied examples:

So I suppose this blog post is a little nudge for encourgaging doing something different, outside your normal zones, in order to experiment and learn.

Go on, do something weird. You never know what ideas it might spark.