Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more. No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner. But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity. And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in. I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

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.

Applying Little’s Law

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

We reduce the number of people in the queue (We limit WiP) or
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

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.

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.

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.

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.

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.

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.

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.

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.
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.
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.

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.

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.

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.

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.

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)*

Over-Production
Inventory
Transportation
Over-Processing
Waiting
Motion
Defects
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.

Weeks of coding can save hours of planning

In the context of Lean manufacturing there have been numerous studies that estimate that the proportion of value adding time in a production cycle is around 5%. The other 95% is deemed to be waste. These studies also conclude that by far the biggest waste is overproduction.

Anecdotally I think it is a very similar story in Software development although my fear is that the proportion of value adding time is even lower.

Waste takes many forms but broadly speaking effort as a team/company fall in to three areas:

1 . Valuable Effort – Value adding activities, these activities cost time and money, and there is a consequential opportunity cost but they add some value. However, the value may be able to be realized more effectively.

2. Obvious Waste – Non-value adding activities that are evident. These activities cost time and money (and opportunity cost) but add no value to the product being created. Examples are vacation, breaks, sickness.

3. Valueless Effort – Non-value adding activities masquerading as Valuable Effort, they cost time, money and have an opportunity cost but add no value to the product being delivered.

Waste Reduction is Not Your Goal

I will be covering the wastes in more detail but it is very important that waste reduction is NOT the focus 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. But identifying waste can aid in your efforts to improve your bottleneck so is a great tool to support your other activities.

The 7 deadly sins

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

Overproduction
Inventory
Tranportation
Over-Processing
Waiting
Motion
Defects
Wasted Potential of People

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Overproduction

Overproduction is considered the worst of the wastes and ultimately it is this particular waste that is the basis of much of the Agile Manifesto for Software Development. Which is why systems thinking is a topic I keep coming back to.

Agile is founded on the premise that at the start of the product we know the least and lack of flexibility is the biggest constraint in the success of software development. Traditional methods plan, create, test and support endless features that were unnecessary, the cost of this waste is unfathomable and big enough to trigger the Agile movement and challenge the way we work.

Overproduction was also the primary waste identified in the book “The Goal” by Eli Goldratt, and if you haven’t read that book I would heartily recommend it. The book is . great primer for the Theory of Constraints and for understanding Lean thinking.

Planning is Waste?

But Agile has not completely fixed this problem, and in my experience development teams regular and persistently develop unnecessary features. With many teams choosing to work without sufficient time spent planning; story writing; prioritizing; and without consideration for whether the work they are doing adds any value now or more significantly adds the most value next.

Road mapping, planning and even story writing are often incorrectly perceived as ‘waste’ and the avoidance of waste is used as a justification to get back to coding on something that is likely not valuable and almost certainly not the most valuable activity to be worked on next, which is a far more insidious waste than the planning ever could be .

Features “not needed yet” are implemented on the basis that it will save time later, or features are added because “We know we will need it later” – (7 words I dread to hear.)

We work to look or feel busy, in our minds we translate activity as being productivity when there is little correlation between the two in the context of software development. In software, creativity; problem solving and planning are far more valuable efforts than unfocused coding.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln

In most cases features have no value until they are in the hands of a user and being used for productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.

Writing extra features that are not used or rarely used extends the production time but brings little or no value, it also compounds all of the other wastes because by it’s nature production of something of little value needs to go through the system thus exposing an unnecessary feature to all the other wastes.

When you next start work on something ask yourself: “Is this the next most valuable activity for our customer?” If you cannot confidently answer that question then maybe you need to spend more time planning so you can spend less time coding something that is not needed.

The worst case scenario

In software the biggest risk to any project is that it will be cancelled or obsolete prior to being used by your customers. This may sound obvious but if a project is cancelled ALL of the features are/were waste. All that effort produced no value for anyone. That time, effort and money could have been spent elsewhere. So getting your product right is only any good if you get your product delivered.

Delivering value to your customer quickly is the best way to mitigate the risk of your efforts being wasted, and Done is not really done unless it is in the hands of a customer and actually being used for a productive purpose.

Overproduction is a big topic and deserves a little extra focus so I’ll delve deeper into the other wastes another time.

Applying the Theory of Constraints to Agile Software Delivery

In ‘Agile’ circles there are certain topics that come up frequently, such as Kanban and Scrum, so much so that we often forget that Agile is a mindset rather than a small subset of methodologies.

As the saying goes there are a great many ways to skin a cat, but limiting ourselves to only a few may constrain us from opportunities to improve. The Theory of Constraints is one of these overlooked options.

The Theory of Constraints (TOC) is often assumed to only apply to industry and manufacturing, which is very sad. TOC is in my opinion the very example of an Agile mindset applied to industry and the techniques can be applied very effectively to Agile Software Delivery.

Some common applications of TOC

Ongoing Improvements
Improve flow
Incremental delivery
Smaller batches of work
Reduced Work in Progress
Focus on maximizing customer value
Reduce firefighting
Reduce inventory of undelivered ‘finished’ work
Reduce speculative work
Reduce reaction time – ability to pivot sooner
Identify potential productivity improvements
Expose underutilized capacity
Identify skills shortages
Identify blocker clusters
Identifying new markets or new ways to engage with your market
Using cost of delay principles to prioritize work

System Thinking

TOC starts and ends with system level thinking, your organization as a whole, not just your team, the whole market, not just your current customers or your current market. TOC requires you to look up and around rather than just looking down.

The Theory of constraints uses the term ‘theory’ in the scientific sense, it is a well defined set of practices that have proven to be very successful when applied appropriately.

The guiding principle is that improvements to anywhere that isn’t your bottleneck is worthless. Think of adding a third row of seats to a car that only ever has one passenger. and that improvements to your bottleneck improve your entire system as a whole so should not be measured in isolation.

This can often feel confusing and counter intuitive, it can sometimes result in decisions that increase local costs and even reduce local efficiencies. Say shipping by air may seem far more costly per item, but results in an increase in sales that far out strip the increase in costs. Shipping got less efficient and costs went up, profit per unit went down. All seemingly unwise decisions when considered in isolation. But the result was that sales went up and so profits increased faster than sales.

And that is the heart of the problem, most organizations create silos and fail to consider the impact of opportunity cost on the organization as a whole. This mindset leaves the shipping department seeking to reduce costs without considering the impact on sales.

In IT this may be seen as saving money by sharing an expert between two teams which means their utilization is high (they are perceived as efficient) but they are not fulfilling their purpose in a timely way to their teams which actually costs the company far more in opportunity cost. Sadly opportunity cost does not show on a balance sheet and so cannot be seen unless you look for it, and understand the significance of it’s impact.

Having dedicated resources with built in slack often causes traditional managers and PMs to have kittens, they cannot bear the thought of costly resources being underutilised, they only focus on cost, not on the value that people bring and that thinking could be crippling your organisation.

Contrary to popular belief your company’s goal is not to keep all workers busy all the time, it is to be the most profitable it can be now and in the future. That means effective use of people and not maximum use of people. The two are not the same and until that is understood your company’s profits will suffer.

In agile we suggest dedicated teams and to minimize multi-tasking, limit WiP and so on, this often leads to under utilized resources(people) but far more value to the customer and generally more profits.

Dependent Events

Another key principle is the impact of statistical variation on dependent events. That is a bit of a mouthful but basically it means that in any given time period, output from a person or a machine varies, neither people nor machines are consistent, we have good days and bad days, some tasks take longer than others, we encounter problems and so on.

The results is that variation in output of one item in a chain impacts on the next and so on, and the longer the chain the more stages are impacted and the more variation disrupts the flow.

This is hard to explain without a demonstration and few people get it until they see it for themselves. Goldratt explained it really well with a game in the book The Goal, but sufficie to say balance is a fallacy.

Balancing the items in a chain (people, processes or machines) does not solve the problem, TOC explores techniques for managing flow to mitigate these problems.

Agile teams apply many of the flow management techniques TOC advocates – training T-shaped people, reducing hand-offs, buffering work, smaller stories, more paths through the system, continuous delivery. These are all techniques that come directly from the Theory of Constraints and have been adopted by Agile development teams.

Summary

You would be surprised at how many good ‘Agile’ ideas have come from the Theory of Constraints and yet we continue to consider it to be for industry rather than software. Think how much more we could be missing by not applying the thinking processes.

I’ll try to cover some of the aspects of the Theory of Constraints in future articles with some ideas of how they can be applied to software development.

Henry Ford – Master of flow

I have recently been presenting a talk on WiP limits and as part of my research I spent some time looking into the history of Henry Ford as he was one of the most influential pioneers of what today we would call Lean or Kanban. He was the pioneer of almost all of our current thinking in industry, and I think was a thought leader in how Agile Software Development is now done.

Theory of Constraints in action

What really struck me however, was how he exemplified the thinking processes behind the Theory of Constraints in all his actions. Everything I read drew me back to that thought.

Ford reduced the average time to produce a car from over 12.5 hours to just 93 minutes.

Ford and his team (I won’t get into the debate as to who had the ideas) created a production line and improved upon it, first by making it a moving production line to keep the focus on flow. Initially simply a winch and rope to pull the vehicle and conveyor belts to deliver parts to the workers. This simple change alone saved hours, previously the workers had dragged their tools along the line of static vehicles as they were assembled.

At one stage the production line for the Model T took 12.5 hours but over the next 5 years Ford reviewed every procedure and managed to cut the production time to just 93 minutes, he cut 11 hours of waste out of an already efficient and profitable system.

Ford cut nearly 90% waste out of an already efficient and profitable system.

Was it a big deal?

Was it really that big of a deal? Yes! In 1914 Ford produced more cars than everyone else, not just more cars than his competitors but MORE cars than all of his competitors in the world combined.

He also produced more with far less, Ford employed 13,000 employees, his competitors combined had 66,000 employees, so the productivity of his employees was 5 times the rest of the industry average. That fact alone makes you sit up and take notice.

In 1914, Ford’s 13,000 workers built around 300,000 cars — more than his nearly 300 competitors managed to build with 66,350 employees.

Continual Improvement

It seemed like no improvement was good enough and Ford was continually pushing for the next improvement, 5 years of asking What’s next. Identifying every bottleneck and then the next bottleneck, his obsession for improving flow must have been relentless.

Fighting against local optimization

But Ford was not understood by his peers who’s focus was on Local Optimization, and even his own sales team who couldn’t understand his desire to simplify the design or reduce the price, they wanted options and variety. Ford wanted a car that was affordable to everyone.

Over the years Ford reduced the price of the Model T from $850 (approx. $22,000 in current terms) to just $265 which was less than 3 months wages for his workers.

The price of the Model T reduced from $850 to just $265 as a result of improvements.

His vision was to have a car available to everyone, but especially farmers, and the Model T was designed to be an effective Farm tool, and could easily convert to farm equipment.

I will build a car for the great multitude. It will be large enough for the family, but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary will be unable to own one — and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.

Henry Ford

People Problems

One of the biggest issues that Ford faced was with his workforce, factory workers were unreliable and his new method of simple repetitive tasks and his desire for rapid growth meant he had high turnover and lower quality workers.

The manual processes Ford devised for assembling the Model T were not complicated but benefitted from training and consistency, so the lack of reliability and consistency of workers was an issue for him.

His solution was to double the average pay of factory workers, Ford offered $5 per day, he reduced the working day to 8 hours and the working week to 5 days, he also offered a form of tenure (on his terms) to all employees.

Ford quipped that it was the best cost saving decision he ever made, with a massive reduction in turnover the cost of training plummeted and productivity soared, and what was really a marketing bonanza his workers could afford his cars.

Blunder or Crime?

This decision was national news. But much of the press despised him helping the poor, seeing it as a social policy rather than a sound business decision. The press too seemingly had no comprehension of the Theory of Constraints or system level thinking.

They believed he was hurting business, with one major paper calling him a ‘class traitor’, and commenting that he shouldn’t bring “biblical or spiritual principles into a field where they do not belong.” going further suggesting that paying factory workers that much “was a blunder, if not a crime … against organized society“. That is pretty harsh for a man just wanting to pay people a little more so he could build cars.

Ford had the last laugh though, employee turnover declined radically, and profits doubled to $60 million in 1916 two years after the policy was introduced from $30 million in 1914.

Any customer can have a car painted any color that he wants, so long as it is black.

Henry Ford

Was the Model T only available in Black?

This for me is the most interesting story of all. Some say it is simply a myth, as the Model T was available in many colors over the years, others say it was a metaphor for his policy of being lean, others that it was a metaphor for his dominance in the field and how he could dictate what the customer wants.

Ford himself claims he made the statement in 1909, and yet he didn’t limit production to Black until 1914, and oddly in 1909 you couldn’t get the vehicle in black, it was not one of the 6 color options available. So the quote does have an enigma quality about it.

However, In 1914 Ford restricted the option to only Black and it remained that way for 14 years before expanding to 14 color options shortly before the Model T was replaced with the Model A.

Cost saving?

I have read that the decision to limit to black was a cost saving exercise, with a suggestion that the unit cost of black paint was less than the color options but I have been unable to validate that claim and frankly I find that very hard to accept. Unit cost considerations have not played a part in any of his other major decisions – the wage decision being a clear example of how flow was far more important to him than unit cost. Cost savings were a consideration at a system level only and certainly not a factor if it impacted on flow.

It is all about flow

From what I can deduce from applying lean thinking myself to the situation, Ford would have switched to black even if the unit cost had been significantly higher. Japan Black paint was completely different to the other paint methods and had two distinct qualities that would have appealed to Ford, the first was that it touch dried very quickly and secondly it baked hard in 48 hours, compared to 14 days for the other colors.

Increase flow and reduce Cycle-time

Because the paint could dry quicker it would improve flow and so a production line was able to complete a car every 3 minutes (with 3 minutes effectively being the slowest process on the line).

Reduce Inventory and reduce Lead-Time

For Ford, being able to ship cars from his factory 12 days sooner than previously was massive, he could reduce WiP, but more significantly it enabled him to reduce his inventory of finished goods by 85%. in 1914 at any given time he would be sitting on over $5 million (retail value) of stock, by switching to Japan Black he was able to ship more and more-sooner. That decision would have been an instant injection of over $4 million dollars (that is over $100 million dollars in 2017 terms). And by 1923 if he had still been offering colors that inventory cost to him would have been over $30 million ($750 million – 2017 value). Not to mention the space needed to store 80,000+ vehicles while the paint dried.

Using only black paint was a $750,000,000 Decision

In essence the decision to ONLY offer the Model T in black was a decision worth far in excess of $750 Million in todays terms, and yet very few people understood the ramifications of that decision and many opposed it or ridiculed it, and many still don’t understand it, even with the results being self-evident.

What is Productivity?

Business is a lot of numbers, and I don’t want to bore you with figures but the improvements that Ford made to flow and cycle-time and lead-time all went straight to the bottom line, by focussing on flow rather than local optimization, and by focusing on the throughput of the whole system rather than on keeping one worker busy, Ford was able to get his workers to be 5x more productive than the competition by doing less work.

Thinking is the hardest work there is, which is probably the reason why so few engage in it.

Henry Ford

Ford showed the correlation between effort and productivity is a myth, and it is about working smarter not harder. He passed his efficiencies on to the customer, as his productivity went up the price of the Model T came down. Eventually to just $260 in 1925 which is a mere $3600 in 2017 terms. A car truly affordable to the masses.

System Thinker

Ford seemed to understand Systems Thinking and the Theory of Constraints long before either were recognized, and he did so to a level that few of us will ever be able to comprehend and in the face of public and private pressure against this way of thinking and he was often vocally opposed for his decisions.

Ford changed not just his own organization but his actions changed an industry and likely even the economy of a country. He balanced profitability with altruism, although some of his values and politics were questionable and some of the rules he imposed on his workers would be unthinkable today. But for me he is the pioneer of Lean, Kanban, and the pioneer of the Theory of Constraints, everything since then seems to be built on his shoulders.

Do you know ‘what’ your problem is?

The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on what we are doing both in our work and in our product, and far too little on why we are doing it.

Failing to understand the why

The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.

There is nothing so useless as doing efficiently that which should not be done at all.

Dr Peter F. Drucker

Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice

We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?

The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value. It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.

Refactoring gets sacrificed when throughput is the priority.

Stories focus on the what not the why.

We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’ rather than actually asking why or giving it proper thought and effort into understanding the real why.

Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods. We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.

It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.

Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.

Taking a little while to do it right could well pay dividends. Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.

Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery. Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.

The customer should be your focus

Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.

When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.

UX is an afterthought

When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX. The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.

The goal of a story is NOT to minimize development Effort, it is to maximize customer Value

A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.

A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer. If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome. Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.

Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.

Acceptance Criteria is a substitute for thinking and conversation

We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.

Being busy is not your goal

It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all. Keeping you busy is not the goal, delivering the best product to the customer is.