Category: Theory of Constraints

Tic Toc – Productivity Experiment

Have you ever noticed that late projects only ever seem to get later?
Why is it that any gains get absorbed and delays get compounded?

builder + plumber

Let’s say I have a mini-project where I have a builder adding a kitchen to a house, he will construct the walls and then I’ll have a plumber come in to install the pipes and fittings. The builder estimates 4 days and the plumber 4 days.

If the builder is done sooner, say after 2 days, that gain is lost as the plumber was expecting 4 days so is not available until the originally planned date. If however the builder takes longer – say 6 days then this impacts on the plumber and at best delays him by 2 days, but more likely he has other commitments so it may result in delays beyond the 2 days ‘lost’ by the builder if he has to reschedule.

The only way to avoid this is for the plumber to build in slack before and after the planned job which is not practical unless he significantly inflates his fees to enable that level of flexibility.

That is a very simple example of a single dependency between two variable events. The majority of systems have chains of dependencies, each compounding this problem for every additional link in the chain.

Just think about your Doctor, they make appointments every 15 minutes throughout the day, if the average appointment lasts 15 minutes then it is likely by the end of the day as any appointment that runs over will delay the next appointment but any time they get ahead the patient hasn’t arrived yet. By the end of the day they may be running a long way behind and relying on your slack time to ensure you get seen. These are just a couple of examples of the Theory of Constraints in action.

Team Activity/Experiment

I’d like to share an activity I have been using in training classes to help people understand the impact of variability, constraints and dependencies on a system – including and especially software delivery. The principles are not limited to software or manufacturing but apply to any system where you are dependent on someone or something. It also shows how improvements in the wrong area do nothing to help your team.

I find learning is best cemented when you can take a group and have them look at a problem in a particular way so that they discover the solution and form their own understanding. No matter how respected the teacher offering solutions is they will never have the same impact as when you discover the answer for yourself. This is why I love teaching in a way that involves experiments.

The Experiment

The activity is best played in groups of 4, this gives everyone a role (and a roll of the dice) and enough opinions to have a debate about the implications.

Each team starts with 4 workstations or 4 stages in a workflow.

Each team starts with a backlog of work (a pile of blocks) and each block must flow through each workstation.

Tic Toc slide 1

In any given iteration, each person in the workflow has the same potential output/productivity and is represented with the roll of a dice.  The dice roll simulates a perfectly balanced system and allows for the variability of work: some tasks are easier or harder than others and some days we are more productive than others, but in this simulation we are all – on average – equally capable, we are perfectly balanced.

We run for 10 iterations. Each iteration is started with the first person will perform their work by rolling the dice, moving blocks, and passing the dice on to the next person. Any unmoved blocks remain in progress until the next round, and so on until each person has completed the work for that iteration. Each person in theory is capable of producing an average of 3.5 units of work and after 10 iterations the system at worst case will produce 10 units at best it will have produced 60.

Over 10 iterations, each workstation has an average capability of 35 units, all workstations have identical potential capability. If everyone worked at average productivity the system should be capable of producing 35 units of work.

Planning based on potential capability

This is very similar to the planning process in Scrum where planning is based on estimated times for all tasks. With planning based on the sum of the duration of all tasks being equal to the amount of time available in the sprint. E.g. 10 days worth of team effort in a 10 day sprint.

In the game, we ask the teams to predict the system output, and challenge any team that predicts a system output of less than 35 to justify why they are expecting their workers to be working at below their average potential.

This can be an interesting debate. Some suggest that people are not as variable as dice, or that stories are not as variable, but this usually results in debate and finally agreement that in fact people are MORE variable: tired, hungry, sick, bad day, good day, vacation, level of experience or familiarity with the job at hand etc. all result in huge variation in the person’s output on any given day. Stories can be split to be a smaller size to reduce variation in theory, but the complexity varies. Some need input from 3rd parties, some will go smoothly while others will hit issues, some take longer depending on who is working on it and so on. We take steps to reduce variation but we cannot eliminate it completely. We rarely know everything, so there will always be some surprises.

This conversation is crucial to understanding the the problem that most of us routinely overlook or choose to ignore despite the massive impact on throughput. We allow this conversation to flow to help people understand the fundamental variability in any system.

By the end of the conversation normally there is consensus that variability is the normal situation and a dice roll is an adequate metaphor, albeit real life is far more volatile.

First Iteration

In the first iteration, the teams will be set up so that each player rolls the dice and passes the appropriate number of blocks to the next player, and then that player rolls and passes, and so on until all players have ‘worked’ for that iteration(cycle).

We then repeat for 9 further iterations(cycles) and observe the outcome.

You can run this experiment for yourself and play along here: Tic Toc Game

In general, the result will be an average output of around two-thirds or a little more of what would be expected – e.g. around 23-27 out of an expected 35.  Sometimes more, sometimes less, as you would expect when introducing variability but the average for the room is typically in the ~25 range.

We ask the teams to explain why they are running at 70% efficiency and what is going wrong. This usually results in one person being identified as being unlucky or consistently rolling low numbers, but generally there is some understanding that there is a reason for it.

At this point you can dive deeper but usually there is sufficient belief that luck is a factor so you may need them to play again for some to accept that it is not luck.

Conclusion

By running the experiment a few times people generally begin to realise that the nature of variability and dependency have a pretty significant impact on one another and that creating a balanced system is actually pretty futile. We can improve the situation by reducing the dependencies, cross training people or giving them more autonomy – one of the principles of agile is to have a team with everyone needed to get the job done – this is because of this situation. Dependencies have far more impact on productivity than most people are willing to accept. The other factor is variability, whilst there is no way to remove variability completely, we can strive for smaller stories. This is one way of limiting variability. When it comes to humans it is even harder to remove variability, but if we strive for a sustainable pace and a good working environment, this reduces variability even if it doesn’t remove it entirely.

Tic Toc – Cumulative Flow diagram

Second Iteration

This experiment shows what will happen with a perfectly balanced system, but what is the impact when you have an unbalanced system or add WiP (Work in Progress) limits to a system? And have you ever wondered what the financial cost of big deployments was, we can experiment to see the how much it costs to have daily deliveries compared to monthly or quarterly deliveries.

In the next iteration we can explore the impact of an unbalanced system, where your system has a bottleneck and how you can deal with it.

Advice on splitting stories

One of the most common reasons we reject people interviewing for coaching or product ownership related roles is an inability to grasp the purpose and value in splitting stories effectively, especially lacking an understanding of vertical slicing.

This is also a commonly requested topic for me at the meetup or speaking engagements. Yet it is a topic I have struggled to effectively explain. The conversation often ends up as a narrow technical example on certain techniques, or difficult stories or becomes too abstract for people to apply. In short it is a large and complex topic.

But this video sums up the notion of story splitting and in particular vertical slicing and the ‘why’ behind the method so perfectly that I felt I had to share it.

“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”

Russell Ackoff

Dr Ackoff sums up the issue with the analogy of the parts of a car, if you assess the purpose of a car to get you to a destination then an engine alone is worthless, even the best designed and most efficient engine cannot get you to your destination. Until it is connected to the minimal set of features to achieve the user’s purpose it is useless and remains useless.

Building any feature that does not work end to end adds no value, and building any feature that does not support the purpose of the user also adds no value. But more crucially it is often the interaction between layers or between components that is the most complex aspect of any development, be it a car or software. and the notion that we can build an engine, and a gearbox and fit them together later and expect them to work seamlessly is laughable. But I hear it all the time in software design.

A system must have an aim. Without an aim, there is no system.

W. Edwards Deming

We’ll build the database first then add the other layers, or we’ll work on an API layer 3-6 months in advance of the front end. It is as if we assume that the integration is the easy bit and worse is the assumption that we have anticipated every need of the user (and omitted everything they don’t need) before we design and build the interface, and before we ask for any feedback. And yet as software designers; planners; and project managers we repeat this error over and over, never learning from the pain of not using vertical slicing for splitting stories.

I believe our fundamental attribution error is the focus on the blocks of functionality (the components of the car) rather than the interactions, and rather than focusing on the purpose of the tool and user feedback we plan for efficiency of the workforce. The result is an optimized workforce and an inefficient workflow. We create a sub-par product that has efficient working components but do not effectively work together, and generally this results turf wars over interfaces that do not match the use cases and last ditch efforts to fit square pegs in round holes.

We can learn so much from Dr Ackoff, software alone is not the system, software is a tool, it becomes a system only when it is in use. The only way we can know if the software is efficient is by putting working software in front of a user and for them to use it and give feedback. So the only good way to split a story is in such a way that you are able to get feedback from the user that helps shape the design or to assist in making decisions.

If a story cannot lead to feedback or use, then it has no value, it becomes inventory or work in progress, it is a liability rather than an asset. That Database or API layer that is built with nothing utilizing it is not benefiting you, it is waste, it is an over engineered liability and the pain comes when you integrate it with other components. This extends to unused data fields or unused end points, “we know we will need them later” is a poor excuse for creating additional WiP (work in progress).

Learning is not compulsory… neither is survival

W. Edwards Deming

We as Agile practitioners can learn so much from Dr Deming and Dr Ackoff we are building systems, and the development process itself is a system, if we applied a little more systems thinking I believe we could be far more effective.

But as Deming said “Learning is not compulsory… neither is survival ”

Explaining Herbie…

I have been asked by a friend to write an article explaining the concepts of Herbie from the book “The Goal” in a more accessible way. The book itself is amazing but in my opinion the language used in the 5-focusing steps has tried too hard to be scientific and precise that it makes it harder to understand. My annotations simplify the terms but likely lose some of the precision of the wording, I offer this as an introduction to the topic but encourage reading the book to get the full impact, I cannot do it justice here.

DHO_0coVwAEzcDl

Herbie is a character from the book “The Goal” he was used in the story as a metaphor for a system constraint and the impact it has on your delivery. I’d highly encourage you to read the book but hopefully it is not essential to be able to follow the explanation, the purpose of the metaphor was to make the thought processes relate-able, hopefully this helps.

TOC 5 Steps

The 5 focusing steps

  1. Identify the system constraint
  2. Exploit the constraint
    (Make the best use of what you currently have)
  3. Subordinate everything to the constraint
    (Make decisions based on the constraint, the system should run at the pace of the constraint)
  4. Elevate the constraint
    (Make improvements to the constraint)
  5. Repeat the steps

Step 1: Identify the constraint

We need to figure out which part of the system is holding us back the most – limiting our ability.  We should know that only an improvement at the constraint makes a difference.

Herbie: In the example of Herbie, he was observed as holding everyone back he was slow and the rest of the group had to regularly stop to wait for him to catch up or were racing ahead.  In the case of Herbie the constraint was evident through observation.

download2

Reality:  There are different ways to identify a system constraint sometimes observation and experience is sufficient, or metrics can help.  The simplest way is to look at your work is it piling up somewhere? Do you have a lot of stories in Dev Done, or waiting on PO approval or needing wire-frames? Piles of work are a sign of a constraint.

Another common constraint are blockers, if you are consistently waiting on another team, another person or another resource this is a sign of a constraint, we may use blocker clustering or other root-cause technique to see if there is a common theme to delays.

The third most common technique is to review cycle-time for stories, look for stories that are taking longer than others see if there is a pattern, common aspects, this could be a constraint that may be improved.

Step 2: Exploit the constraint (Optimize)

Before we consider adding capacity, we should make the best use of the capacity we already have. We ‘Exploit’ in this sense means doing everything possible to use the constraint to its fullest capacity. This is also the easiest and generally cheapest improvement you can make to your system.

Herbie: In order to maximise the performance of Herbie, the contents of his backpack were shared out so he could concentrate on the most important task of walking.  Making the others slower (less efficient) by carrying his stuff was unimportant as Herbie sets the pace for the entire group.

We could also have ensured that he got his lunch first so could start sooner, and others could have covered his chores so he was more rested – our goal is to get the best out of Herbie on his most important task – walking.

Reality: In our systems we need to identify what the most important task is, typically this is getting a story to done and the software in the hands of the user.  So when you identify your constraint look for anything they are doing that is not helping to move stories or for anything they are doing that someone else could do. Are they filling in paperwork that someone else could do? does this task really require their expertise? Could you make them a coffee so they could focus. (This is not encouragement to over-work, breaks socialising and generally a healthy working environment always takes priority).

WheresHerbie

Step 3: Subordinate the non-constraints

The job of all non-constraints is to subordinate their decisions to the constraint’s needs.

That sounds extreme wording but essentially it means that no mater how fast you go, if you are dependent on someone slower you are wasting your efforts, so work at the pace of the constraint, you have reserves so you can catch-up if necessary.  Use the time saved to help optimize the rest of the system.

We do this as step 3 because it is more disruptive and more costly than step 2.

Herbie: In the story Herbie was put at the front and the rest of the group were told not to overtake him. When Herbie was able to go faster there was no one in front to delay him so we got the best from him and as the others were able to go faster overall they were able to make up any delays. The goal was only achieved when everyone was done so there is no benefit in getting ahead.

Reality: Don’t let work pile up, if we limit Work in progress we focus on flow rather than utilization, put effort where it has most impact on the whole system.  In the case of dependencies on 3rd parties, could you give them advance notice so they are better prepared and can respond sooner. If you are dependent on a 3rd party could you see if there is a time/day they can respond more quickly, could you tailor your process to be more convenient for them? Tailor your process to maximise the effectiveness of the constraint, and this is the tough bit – even if that means making the process worse for others.

Tailor your process to maximise the effectiveness of the constraint,  even if that means making the process worse for others.

Step 4: Elevate the constraint

Only once we’ve completed the previous steps does it make sense to add more constraint capacity, and thereby increase system performance. Because adding capacity is tremendously expensive in terms of time and money, we do it as a last resort, not a first step.

Herbie: In the case of Herbie, we could get him doing fitness training so he is quicker, or buy him a bicycle.

Reality:  This is typically where you spend money, hire more people, get better/more equipment. Invest in training or education. Remember improvements here improve your entire system so the investment must be calculated based on system income not local costs. Maybe you ship parts by air, maybe you fly in an expensive expert, maybe you lose money on this aspect of a project so that the project as a whole makes more money. Keep the focus on the gain to the entire system and not get distracted by the cost at one stage.

Step 5: Return to step 1

The inevitable result of the first four steps, and the reason this is a “continuous” improvement method, is that the constraint will inevitably move somewhere else.

This step insists that you start back at the beginning, and don’t let inertia become the constraint.

choosing-a-doctor

A second example of the steps being applied…

Identify

Access to overworked Doctors in an emergency – constraint is a shortage of Doctors:

Exploit: Make the best use of what you currently have

  • Ensure Doctor is not doing any activity that someone else could do. All admin work is removed, prep work done by nurses or other staff.
  • Vacations/time off is deferred,
  • Doctors may work overtime so long as it doesn’t risk the patient or cause the Doctor to quit

Subordinate: Make decisions based on the constraint, the system should run at the pace of the constraint

  • Any non-urgent treatment is stopped until emergency is over.
  • Cases are prioritized so Doctors are only working on the most urgent cases.
  • Patients are only ‘prepped’ according to the capacity of the Doctors.
  • Patients are prepped in advance so that the Doctor is never waiting.
  • It may be quicker for a Doctor to move between patients rather than them coming to the Doctor.

Elevate: Make improvements to the constraint

Now we look to increase the number of Doctors or their effectiveness

  • transferring Doctors from other areas withing the organisation
  • recruiting more Doctors even at inflated rates or short term contracts,
  • any increase is an increase so we can hire someone that is semi-retired or part-time.
  • We may automate activities or buy tools to improve the efficiency and effectiveness of the doctor.
  • We could train Nurse to perform some of the Doctor’s activities

Repeat

We look and see whether the Doctors are still the constraint or whether there is a new constraint.

Summary:

There may be a little ambiguity with some of these improvements, e.g. A Doctor moving between patients may be considered elevating or subordinating, but it doesn’t matter it is an improvement, it is a thinking process and some changes don’t neatly fit into one category, don’t let that distract you from the thinking process itself.

9780815385134

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

What does agility mean to you?

It seems like there is a very personal level to what Agile Software Development means, as far as I can tell there is no consistent common understanding of what agility means. Some see it as a framework, others as a mindset.

Why-Agility-is-Critical-for-Soccer-Players-STACK

For me it means two things.

We have agility in our planning. We expect and encourage our plan to change as we better understand what we are delivering.

And

We have agility in our operations. We expect and encourage our tools processes and methods to change as we discover better ways of doing things.

Planning

Agility in planning means making a plan: ‘failure to plan’ as they say is ‘planning to fail’, and that failure is probably more certain than than it was when we had an inflexible plan.  There is a great deal of value in planning, we learn a lot and by setting a sense of direction we create focus.

The trick is that if we understand what we are planning and why we are planning, we can do it in the most efficient and effective way. We don’t need a lot of planning or a lot of detail, planning doesn’t need to be a massive overhead.

If we limit the granularity of our plan in relation to how far ahead we are planning then we allow for that plan to adapt as we get more information.  We can get all the benefit of having a plan without the overhead and without being restricted if and when the plan needs to change.

Business-Agility_450

Process

I believe process is vital to success in business, whether we are building software or hiring or in a factory, even sales has a process.  But a process must be flexible, we must be able to adapt when things change and we must be able to react to exceptions.

We mustn’t ever get to a point where we declare this is the ‘best’ way of doing something or ‘if it ain’t broke don’t fix it’   As soon as we stop looking we prove ourselves right, if we only know one way to do something it is definitely the best that we know of. Our ignorance ensures that we are right.  But if getting better is more important than being blissfully ignorant then we must look for ways to improve, we need to observe and we need to experiment. We should never let entropy set in, we should always be seeking to improve.

The very best processes build in opportunities for reflection and improvement, ensuring a mindset that there is always a better way, is far healthier than one of complacency.

One of my favourite ‘processes’ comes from the Theory of Constraints, it starts with the assumption that something can be improved and the first step is to identify the one area that would most benefit from improvement, it ends with a refusal to accept inertia.

TOC 5 Steps

 

Summary

For many Agile is about the framework, or the tools, for others it is the people and their ability to self-organise.  I don’t want to devalue those aspects but I see those as a means to achieve the agility in planning and process.

I’d love to hear your thoughts, what does Agile mean to you?

 

 

 

How do I know I am delivering Value?

Many of us are relatively familiar with the notion that stories should be expressed in terms of value delivered (Why) and how important the “Why” is for being able to maximize the outcome for the customer–

 

Who: As a …

What: I want to :

Why: So that …

 

When we talk of good stories we refer to INVEST as a means of helping validate that our stories are well written, I think this is a great tool for helping write user stories, we may even include Acceptance Criteria to help the team identify that the story has been completed in such a way that the value is best able to be realized, but I’d like to propose going a step further.

success

Expected Vs Actual

Whichever way the story is written the assumption is that the PO has determined the value of the story and prioritized it accordingly, but value is a very nebulous term and encapsulates all sorts of things many of which are assumptions or just plain guesses or personal preferences. We are also making the assumption that the story will successfully deliver the value we intend.  Rather than accepting that it is a hypothesis that it will achieve our goal.

Up to this point we are assuming that the Product Owner is always making the right decisions, and their assumptions of the value delivered by a story are infallible. Speaking as a Product Owner, that is a rather hopeful assumption, often value judgements are little more than educated guesses, certainly they are very subjective opinions on value. Even market research is guesswork to some extent and particularly with new products or internal systems there is little opportunity for effective predictions of value.  I don’t want to take anything away from the PO and their authority on making these judgements that is after all their role.  But as a PO I would very much value a feedback loop which would enable me to validate that my decisions were right or wrong and give me the opportunity to course correct accordingly.

In other words it is necessary for us to make judgement calls but getting feedback on the accuracy or otherwise of those decisions would be hugely beneficial.

download (5)

So what can we do?

We could add to the Acceptance Criteria to include some additional validation. Our Acceptance Criteria helps us validate that a story is implemented the way we intend it to be implemented, it does not however always enable us to measure whether the value is fully realized.

For example:

Assumption: We believe that adding a picture to listings on a product website will increase sales by 10% (our market research says so).

As an online customer,

I want like to see pictures of products

So that I can make more informed buying decisions (and thus buy more products) –

(Business Value: Marketing estimates sales increase of 10%)

 

Our Acceptance Criteria may stipulate positioning of the picture, the size and what to display if a picture is not available. We may even add some performance Acceptance Criteria such as average page load time. But that is not enough to validate that the value was achieved.

missing3

How do we validate that a story delivers Value

But how do we validate that this story does actually deliver the value we expect – whilst we can be confident that having a picture fulfils some aspects of the value – the better informed decisions, it might be that we are missing out by not having the ability to zoom on the picture, or it may be that our users are not bothered by the picture at all and would prefer another feature such as the “lead time” or “quantity in stock”

Validation Criteria

What if as part of this story we not only implement the feature to show the picture but we also include analytic measurements on the page load times, and even a measurement for the number of sales of a product or products per day and then evaluate 50% of users with the new feature and 50% without the pictures and compared the results. Or we could conduct focus groups on this feature or usability studies to get more subjective but detailed feedback.

As part of the story we could add an additional layer of Validation Criteria, this would be similar to Acceptance Criteria but would be a way to measure the value actually realized by the user

download (6)

What do we gain?

Would including functionality or activities that enable us to measure that we have delivered the value we are expecting make the stories better? Would that information help shape our product and build a better product? Would it help us prioritize our backlog as we get a better understanding of value actually delivered vs value expected to be delivered?

We could either add stories for these measurements or consider these to be encapsulated in the delivery of this story.

Essentially we are asking whether feedback is valuable and if it is – how valuable is it to us.

download (7)

Return on Investment:

When discussing this with a colleague the first response was that this is putting more upfront work and that is a challenge for the ‘lazy’. In Agile ‘Lazy’ is a virtue so this is important feedback.

Naturally there is an overhead in this but as with all feedback loops the information is valuable, knowledge is power and we just need to tune our efforts – our feedback volume to the right level to get valuable information with the minimum necessary effort. Another example of an Andon Cord where if the effort is too much and producing either too much information or nothing of value then we need to retune our feedback loops to give us enough valuable feedback to act.

Also many of these measurements will be applicable to multiple stories so the investment may end up being very limited but the feedback may be far reaching, and once automated the ongoing feedback can be tweaked to add extra sensors to give us more and more valuable information.

Some examples of value assessing measurements:

  • Website analytics: hit rates, click through rates, hot spots etc.  The cost of these is minimal and is often something that can be applied even after development.
  • We could write stories to build into our application measurement for how our product is used, or the performance of our product,
  • We could add usability testing or focus groups, surveys of users
  • By using feature flags we could set up effective A-B testing to get feedback on structured hypothesis validation.

Please note that not all measurements need to be software driven – increased subscribers say may be measured entirely independently of your application.

Navigation

Vision

But ultimately the biggest change would be in your initial vision creation, do you know your product goals and do you have a way to measure success.

Is your goal increased sales, or time saved, or efficiency improvements, or increased users or cost saving and regardless of your goals do you have a plan for measuring whether your product is achieving your goals.

This may seem like stating the obvious but I cannot count the number of projects I have been on where the stated aims were cost-saving or revenue generating and numbers were stated and yet after the project was authorized no one ever went back and assessed whether the project was a success or achieved any of it’s aims. Having an aim was enough to get the project started.  Claiming a 10% increase in sales or reduction in costs should be something you can measure so measure it.

Ironically being able to map a story to one of your stated goals for the product could be another way to filter unnecessary stories if the expected impact is not one of your product goals.

Summary

This is a very simple change to your story writing process – an extra little consideration that could have significant implications to the success of your product, the addition of a very valuable feedback loop on value delivered (rather than value expected)

As a …

I want to …

So that …

And I can verify this by …

 

Post Script:

I presented this notion to a Product Ownership Meetup and the response was amazing the conversation was full of so many great ideas, and examples of how some of the product owners are already putting this in to practice – not explicitly but have made usability and measuring usage a key part of their Product Ownership methodology. I love the conversations this group has each month, but this month I came away with so many new things to think about.

The highlight of which was Goldratt Users stories – which will be the subject of my next blog.

Tell me how you measure me and I’ll tell you how I will behave – Eli Goldratt

Practically Agile

As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.

Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.

  • Systems Thinking
  • Community Context
  • Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.

At the very heart the manifesto is about getting better at delivering software.

“We are uncovering better ways” – it is a journey of discovery, we do not have all the answers.  “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.

Systems Thinking = YOU are not the center of the universe

The goal is effective Agile Software Development, solving a problem for a user, with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .

Transformation failures

In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed.  The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.

An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster.  High performing teams arise when we learn that we are more that the sum of our parts.

The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally and this is the pillar that binds it together and makes it so strong.  We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.

As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.

We challenge our thinking, we question our beliefs and we look for ways to grow.

We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.

If you always do what you’ve always done, you’ll always get what you always got

Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.

5-focusing-steps-113297

Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.

Summary

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.

 

WiP Limits and Velocity

I recently presented at a conference on the topic of Work in Progress (WiP) limits, and in particular Little’s law.  As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

little

Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

  1. We reduce the number of people in the queue (We limit WiP)  or
  2. We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

Note:  When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works.  This works in mathematics, but maybe not so much with people in reality.

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

Work in Progress Limits will directly impact Cycle-time

Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens.  The real world is far more complex and there are many more variables.

In the real world

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits,  but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

 

 

 

Motor City – A Kanban Game : Overview

JSY_1323

Game Overview

The game is designed to reflect a simplified operating of a delivery pipeline for a car manufacturing plant.

The player accepts orders from customers, chooses which products to make and allocates resources and manages the plant to deliver cars to customers in the most effective way possible.

JSY_1267

Kanban

Each player manages a separate board representing a factory, the board is laid out as a Kanban board and the production is tracked as it moves across the board.

JSY_1279

Wip Limits

In the core game WiP limits are optional. Players may choose to apply WiP limits to manage flow, or just use their instincts.

If played for fun the WiP limits are not explicit, but if using this in a training environment I’d encourage explicit limits and for them to be strictly enforced to enable the class to evaluate the impact of WiP limits on the game.
I’d also suggest that each player experiment with different WiP limits to compare the impact with each other and discuss the results.

JSY_1276

Accepting Orders

At the start of a shift a player may choose to review and accept an order, once accepted an order must be delivered and if the player fails to complete an order they will be penalized.

Sourcing Materials

Each shift all players may choose to source materials for their production, this is done by selecting vehicle cards from the available selection, only 4 cards are visible and players may only choose from those available – this adds some competitiveness over resources, and an element of understanding your constraints and dependencies.

JSY_1264

Production

At the start of each hour within a shift one player rolls dice to determine the available production points for all players (all players get the same to make this game about the allocation of resources rather than the luck of the dice.

Each player is allocated a quantity of Manufacturing, Assembly and Quality production points which they can allocate over the course of the hour. Unused production points are discarded. The player also has the option to trade production points of one type for another but at a 4:1 ratio to indicate the impact of repurposing machines.

The vehicle cards are pulled through the system and production points are allocated as they progress through the system.

JSY_1305

Bottlenecks

There are a number of potential bottlenecks in the system and how you manage these will heavily impact the result of the game.

Game Success

Ultimately the winner will be the one that manages the production most effectively to meet their customers’ needs. It is hoped that applying Kanban and Theory of Constraints Practices will be rewarded, although there is an element of game mechanics and chance.

Purchasing the Game

The game is for sale at $120 + postage and is available now.  Game contains 4 game boards so is suitable for 4 players (or 4 pairs).

Please email me at john.yorke@yorkesoftware.com to arrange to buy the game.

Thank you for your support and encouragement.

JSY_1308

 

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

  1. First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it.  It was not a game in that sense, it was much more of a training tool/prop.
  2. The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
  3. Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

motorcity_Board-1

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail.   One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

Rulebook_cover

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game.  That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints.  You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

box_bottom

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

motorcity_logo

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

boxbase sm

Identifying Waste in Your Processes

I think as agile practitioners we can learn a lot from Lean thinking and there are a number of concepts of Lean that I think apply very well to Agile Software Development.

This is the second part of a blog attempting to convey the Lean concept of waste and I have introduced some ideas for how we can help mitigate waste in an Agile environment.

The 7 deadly sins

Lean identifies 7 wastes  (recently adding an 8th Waste)*

  1. Over-Production
  2. Inventory
  3. Transportation
  4. Over-Processing
  5. Waiting
  6. Motion
  7. Defects
  8. Wasted Potential of People*

 

Over-Production

explored in more detail here.

 

Inventory / Work In Progress

In manufacturing the physical properties of inventory are obvious, piles of raw materials, stacks of part built products, warehouses of finished goods are all big and obvious, but in software, inventory is harder to see, it is intangible to the casual observer.

In software, Work in Progress takes many forms, most obviously this is in the form of code, any code not deployed to a customer is Work In Progress, that code cost time and money to create, the raw materials are developer thought and effort.

But Inventory is not just code, it is also knowledge, it is thought and problem solving, unrealized ideas and even experience and learning.  Code is the manifestation of thinking, problem solving and planning. WiP/inventory is also the consequence and ideas resulting of conversations with users, usability testing, marketing. All of these are the efforts needed to create a product. But until those efforts are turned into a product it is all potential waste: time and money that are spent but until released to a customer are not providing value.

If we can learn to manage our Inventory/Work In Progress to limit it to only what we need and only what we can benefit from in a reasonable timeframe we can cut back on excess Inventory which in business terms this can have a major beneficial impact on our cashflow. Reducing Work In Progress also has the added benefit of making it easier to see  other waste.

Effectively managing your WiP is probably the second biggest opportunity for waste reduction and the act of limiting WiP will help identify other wastes in your system.

Transportation

In manufacturing, there is deemed no value in transportation. Moving a product does not add to it’s value and may even damage it with wear or breakage. reducing the distance between workstations or distance from your raw materials or the distance to customers can reduce the cost of time or effort and reduce the risk of wear or damage.

In software transportation could be best viewed as hand-offs, handing off work to another person or team requires effort, bringing them up to speed, co-ordinating, sharing the work. All this time and effort does not add any value to the software. But worse there is consequential loss of knowledge when there is a hand-off, and each hand-off results in a greater loss as the knowledge becomes fragmented and dispersed. Vital information may not be passed on leading to poor decisions, this is equatable to a breakage during transit.

Limiting hand-offs can reduce waste, having a team that contains all the knowledge and skills necessary to complete the work can help.  Steps to improve and enhance communication so that less knowledge is held by a small number of people can mitigate the loss of knowledge during a hand-off.  E.g. have all members of the team involved in story refining meetings so everyone is apprised of the intent of a story and can ask questions.

Over-Processing

In manufacturing this is making a product to a higher standard than is required or spending longer on something than is necessary, or in using a tool that is over powered for the job at hand.

This is similar to Over Production in many respects as is it unnecessary work, but in software it is obfuscated.  A feature may be needed, but we have over engineered it, spent more time and effort on it than is necessary.  This is not an excuse to cut corners, but development and test effort should be reflective of the customer need.

TDD – Test Driven Development can help here, by writing the test first and limiting coding to passing the test can help reduce over-processing.

However, many developers engage in EDD – Ego Driven Development where they write unnecessarily complex code to solve a problem so they appear clever to their peers.  Or RDD – Resume Driven Development where they introduce a shiny new: tool, technique or gadget, because… ” it is shiny and I wanted to try it out” or “It will look good on my resume” rather than because the product needs it.

EDD – Ego Driven Development where developers write unnecessarily complex code to solve a problem so they appear clever to their peers.

There is another form of Over-Processing and that is writing software to solve a problem that could be done more easily another way.  We have a great desire to automate everything but sometimes the solution costs far more than the problem we are solving.

The waste of this seems obvious when described here but can be difficult to spot in the wild, pairing and TDD can help keep the focus on the goal and limit the opportunities for over processing.

Over-Processing – Re-Learning

Another aspect of over-processing is the act of re-learning, if you have solved a problem once you should not need to solve it a second time, or if someone else has solved a problem can you benefit from their learning.

We can reduce this waste with knowledge sharing within the team or having the whole team in discussions about design or story refining so that opportunities to avoid re-learning are increased.

Avoid long delays between first looking at a product and then coming back to it later where you need to remind yourself of context better to only start work on something when you are ready to see it through.

Waiting

Waiting is any time that the product is not being actively worked on, this could be a story that is blocked waiting on someone or some event.  I think most people see that as waiting time, but any card that is not being actively worked at any time is ‘waiting‘.

Any state such as ‘dev done’, or ‘QA done’, or ‘ready for test’ or ‘ready to deploy’ or even stories written but waiting in the backlog are ‘waiting‘. Most stories will spend far more time waiting than they will being worked.

This is often a symptom of having too much work in progress, but items waiting may be a sign of a bottleneck or potential areas for improvement in your workflow. Kanban focuses on flow – minimizing the waiting time, so identifying any area where there is excessive time waiting is a candidate for improvement in the workflow.

Keeping track of repeat blockers, or being aware of areas of your system where stories regularly spend time waiting can help reduce this waste. Challenge any story that is not actively being worked and ask why.

One technique for this is for team members to each have only one avatar and have them place it on the card/story they are currently working on.  Any card without an avatar is waiting.  Only allow one avatar per person.

Motion

Similar to transport in many ways but refers to the operator or the operation rather than the transport of the product, could the workstation be operated more effectively.

In software this is sometimes interpreted as Context Switching which unnecessarily slows down the team, this is certainly a major part of it, but I prefer a broader interpretation, anything that hinders the team from getting the job done effectively, this could be having the right tools, the right environment, the team working effectively together, communication barriers.  But I can understand the desire to focus on context switching such as: support calls, emails, even distractions in the office space are forms of task switching that impair the effectiveness of the team to get the job done.

Identifying ways to improve the work environment and limit the interruptions could cut huge amounts of wasted time from your workflow.

Defects

Defects are another waste that gets compounded as a defect is exposed to all of the other wastes as it goes through the system which magnifies a problem that is already serious.

Defects are waste that grows the longer they go undetected, the problem itself is magnified by time and use, the more time the more frequently the defect occurs and the more users it impacts the more it costs you. That is until reported it is a hidden cost.

The waste is a hidden waste until much later so it can give us a false sense of security until the product reaches end of life and we have a full picture of the total lifetime cost we will not know the true extent of the cost of defects.

Another factor is that the cost goes beyond the impact of the defect itself the longer it goes undetected the less recent knowledge the development team has of the subject and so the learning time goes up.  How often have you been asked t fix code of someone that left the company years ago and have no clue what they were writing.  Once again one waste impacts another if that developer was using EDD you may have code that is so complex the effort to resolve is much higher.

We can try and combat defects with good development practices, such as pair programming, TDD, and comprehensive regression testing.  Any efforts we can find to identify defects sooner or prevent them occurring reduces the waste and the long term impact.

Wasted Potential of People

I have seen this added as an 8th waste of manufacturing, and it goes doubly so for software development.  In software development people are your greatest asset, it is a creative knowledge based activity and so providing the right work environment and opportunities is essential to getting the best from your people.

Demotivated people work slower and with less care, but enabling people to reach their full potential could reap rewards for you and your products.

Summary

Any system will have waste, some is necessary and some is not, but being able to identify what is necessary and what is unnecessary or what is waste and what is slack can greatly enhance your chances of making improvements that really help your software development process.

Often what you thought was waste is actually a valuable activity and what you thought was adding value was just adding waste. Understanding this helps you make the right decisions.

However, please remember – It is very important that waste reduction is NOT the Goal of your efforts,  Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself.

Your goal is to improve the entire system and focusing on one area without consideration for the system as a whole leads to the wrong decisions being made. Waste is just one of many considerations.