Agile thinking in ancient Rome

I found a number of quotes from a popular writer and favourite of Julius Caesar :- Publilius Syrus that I thought were so appropriate to Agile thinking today, it is fascinating how these lessons have existed for millennia and yet we still frequently fail to follow what would seem to be common sense.

Here are some of his maxims:

On agility in planning:

“It is a bad plan that cannot be altered.”

On commitments:

“Never promise more than you can perform. “

On quality:

“Nothing can be done at once hastily and prudently“

On multi-tasking:

“To do two things at once is to do neither “

2000 years later and the old Maxims are still relevant.

Understanding the 5 focusing steps

The Theory of Constraints (TOC)

The Theory of Constraints complements Agile software development extremely well, it is about applying a mindset of ongoing improvement to your organization. It contains the notion of applying efforts to improve to the areas that will have the most impact and offers some practical techniques for achieving this.

When we talk about the Theory of Constraints what is often thought about are the 5 focussing steps. The steps are not always easy to understand and the wording can be confusing. I’ll attempt to explain the steps with a few examples, where possible I’ll use examples more common to software delivery organizations.

What is a constraint?

Firstly a constraint is neither good nor bad, it just is. Your system has a constraint and no matter what you do, it will always have a constraint. You may say that in a perfect system the constraint is the external demand for your product or services, but even then there are ways to increase demand or open new markets, and markets have a tendency to change over time.

Do not treat a constraint as a bad thing to be eradicated, awareness and understanding of the constraint is the goal, what to do with that knowledge is a secondary consideration.

Constraints:

A constraint limits the useful output of your system, so any improvements to the constraint will directly impact on the total output of your system.

Conversely improvements to an area that is not a constraint will have no impact on the output of your system.

example:

Let us consider a simple system. I can build 3 units a day and I can ship 1 unit a day.

Shipping is my constraint, Building is NOT my constraint. If I make improvements to shipping and can now ship 2 units a day I have doubled the output of my entire system.

If however I improve the building aspect of my system and can now build 4 units a day, it is wasted effort as I can still only ship 1 unit. The over production is stuck there.

Any effort to improve any part of the system that is not your constraint is wasted effort. You should instead focus on improving your constraint.

This sounds obvious, but when your organization breaks areas into silos and measures managers on the performance of their area alone you tend to see this a lot. Teams striving for improvement and additional output when they are not the constraint. The result is make-work. Things that “you know will be needed later” building inventory and so on. Sadly cost-accounting supports this dysfunction by rewarding the behavior by classifying work in progress and finished goods inventory as an asset when in most cases it is a liability.

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Eli Goldratt

What is the system?

Our goal when applying the TOC is to identify constraints or rather the constraint in your system. But that begs the question what is the system?

As a very broad rule of thumb, the system is all that is within your (organization’s) sphere of influence. It is not limited to just one area of the business.

Note: Your sphere of influence should include your market and potential market, and your supply chain, which includes potential recruitment candidates. Anything within which you have authority to influence.

The 5 focussing steps

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

Step 1 Identify the System Constraint

The three most obvious signs of a constraint are:

They are always busy
Work is piling up in front of them (in the case of people this may be requests for help)
Work downstream is starved, people that are dependent on them are regularly waiting

Note: busy work or excessive Work in Progress can mask these signs, so the first step is to stop any non-essential work, anything that is not needed immediately or cannot be traced to the top priority. By reducing work in progress it will help reveal where your constraint is. All too often your constraint is busy doing something not needed.

Once you have identified where you believe your constraint is, we move on to the next step.

Step 2: Exploit the constraint

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

Peter Drucker

As we identified earlier any improvement to the constraint improves the output of your entire system. but the converse is also true. Any time your constraint is not working then your entire system is not working, any effort your constraint spends on something that is not immediately needed to deliver value to your customers is output lost to your entire system. It may not be obvious but this is a key aspect to understand.

Your constraint should be considered in that manner, we say exploit the constraint in the sense that it should be used in the most effective way possible. This means doing the very best you can achieve with what you currently have.

Exploit your employees that are constraints to get the maximum value (NOT EFFORT) exploiting a constraint isn’t about a death march, it is about getting the most value from them in the long-term. A happy employee working a sensible number of hours will deliver far more value than an overworked employee.
Work to keep your employees engaged, engaged employees deliver more value.
Pay well, your constraint(s) are your company’s most valuable asset, pay them well, they are worth far more to your company than their salary. replacement, training and adjustment of new employees to replace a constraint directly impact the output of your entire system, learn that cost and value are not the same thing.
Only work on the highest priority items, make sure you understand the concepts of cost of delay and opportunity cost. Maximize Value !
Ensure there is a buffer of work before the constraint so that there is no idle time, idle time is time lost to your entire system.
Avoid multi-tasking, context switching is waste, better to complete one thing at a time, so ensure tasks for the constraint are prioritized properly.
Ensure your constraint is not working on anything that could be done (even less efficiently) elsewhere.
Ensure your constraint is not working on anything that is not directly leading to immediate value. Is your constraint booking their own travel, or filling in time sheets, or even making coffee? Or are they busy on a feature that you think will be valuable later? All of those tasks are directly impacting on the throughput of your entire system, could they be done by someone else (or not at all).
Does your constraint have all the materials they need, do they have access to the information they need, the right tools and the right support, the right training. Your constraint should have the right tools, the best tools available. Your development team should have the fastest computers and the best software for the job, skimping here is one of the most costly errors a company can make.

This leads to a mini-debate on the use of admin assistants and Scrum Masters. There is a trade-off between the ability for people to solve their own problems, and do their own admin and generally have a broader skill set. Having an admin to do certain jobs can be a form of exploiting your constraint, but can also create a new constraint if you become dependent on them. Same goes for a Scrum Master, they are a great example of exploiting the constraint that may be your development team: Someone to handle blockers; chase things down; and generally ensure the team is enabled to be most effective all of the time by taking non essential work off them and keeping them focused on delivering value. But again the risk is that they become the constraint. Everything is a trade-off.

Step 3: Subordinate everything to the constraint

This is generally the step that is the most confusing. What we are saying here is that all decisions you make in your system and for your system should be made based on understanding where your constraint is.

Quality, your constraint should not be working on things that are poor quality and may need to be reworked. Ensure work handed to the Constraint is of the best quality it can be.
Identify and anticipate problems, if there are dependencies or potential blockers or risks ensure that they are mitigate BEFORE the work gets to the constraint, blocks at the constraint are blocks to your entire system. Have questions answered in advance where possible.
In the case of story writing, it may be that getting the input from the development team upfront at story writing time leads to fewer problems later, focus on flow and using valuable time effectively. This is not an excuse to silo the constraint, this is about thinking of ways to use the time in the most effective way possible.
The rest of the system should work at the pace of the constraint, work should flow, sensible buffers of work should be maintained but no overproduction. Identify a cadence and have the whole system work to that rhythm.
Have non-constraints use the inevitable slack time to work on tasks at the constraint. Developers should be testing, testers coding, anyone and everyone should use their slack to alleviate the work at the constraint, regardless of how inefficient they may be – so long as they are not introducing errors or knowledge gaps that may cause further demands on the constraint later. This is where encouraging T-shaped people can enable us to maximize flow through our system.

As you can see the importance of understanding your constraint and making decisions based on that

Make the bottlenecks work only on what will contribute to throughput today … not nine months from now. That’s one way to increase capacity at the bottlenecks. The other way you increase bottleneck capacity is to take some of the load off the bottlenecks and give it to non-bottlenecks.

Eli Goldratt

Step 4: Elevate the Constraint

Once we believe we have done all we can to Exploit the constraint and to subordinate everything to the constraint and we still want to improve further then the next step it to elevate the constraint.

Up until now the efforts have been without investment, it has been to utilize what you have in the best way possible, elevating the constraint will generally require an investment of some kind.

Hiring more or better people to support the constraint (only hire for the constraint)
Purchase more machines to support the constraint
Training or coaching the constraint(s) to improve their skills and effectiveness
Purchase better software, faster machines, better tools, conferencing equipment, more meeting rooms.
Team building activities, or other ways to improve effectiveness of teams that are part of the constraint.
You can consider more drastic options such as switching to a different tech stack, if that enables solutions to be solved quicker or may make hiring easier.
Moving to a new location.
Entering a new Market or creating more (diverse) products.

Remember all of these options should be undertaken with the specific constraint in mind.

Step 5: Repeat

Once you have worked through these steps it is expected that you will have been a catalyst for change, it would be good to have a measure of the impact if you can. But the end result is that your constraint is less of a constraint, allow time to see the impact of the changes and re-assess where your constraint is now. It may be in the same place or a new constraint may have been identified. But in either case repeat the steps and see if further improvements can be made.

Repeat again

The Theory of Constraints is a process of ongoing improvement, if you stop improving entropy sets in and things will get worse, these steps should be repeated and repeated indefinitely and frequently

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.

Monte Carlo Syndrome

Monte Carlo Method

Monte Carlo Forecasting is a method for creating predictive forecasts based on a technique of repeatedly running random simulations of the samples to see a range of possible outcomes, and then to use those outcomes to forecast results of larger (or future situations). The predictive model offers a percentage probability of being in certain ranges.

It can be a very effective tool for statistical analysis of data, and there has been a surge in it’s use in Software delivery Forecasting. It can be a useful tool even with small sample sizes but it relies on three very crucial premises.

The sample data MUST be reflective of the forecast situation,
The data must be also be statistically independent (results of one event does not impact another).
The greater the sample size the more reliable the simulation will be.

Monte Carlo Fallacy

Rather amusingly there is also a psychological condition called the Monte Carlo Fallacy where we assume past results impose a probabilistic bias on future events. “The last 5 spins of a roulette wheel came up Black therefore the next is more likley to be Red as the odds must balance out.”

That is the fallacy. In a fair roulette wheel the odds of being black or red never change no matter how many times you get one result, any combination of outcomes has the same odds as any other. In fact it is far more likely that the wheel has a physical bias towards Black than the odds righting themselves, probability has no memory.

Applying the Method to the Fallacy

Amusing as it is the Monte Carlo Fallacy is the act of using observation to misinterpret probabalistic based statistics assuming the probabilities have memory, and the Monte Carlo Method is using observed events to create probabalistic forecasts by assuming (often dependent) events have independence.

Just as a point of interest. If you used the Monte Carlo Method for gambling on ‘fair’ Roulette Wheels you would likely have no difference to any other ‘system’ – probability cannot be influenced, it would simply be using a ‘method’ to compound your Fallacy.

However, in theory the method could be used to identify faulty Roulette Wheels or other unusual variations from probabilistic results (e.g. to spot cheating), or to predict gamblers’ behaviour.

Applying precision to inaccurate data is dysfunctional behavior. It is using the fog of precision to create an illusion of accuracy.

The Fallacy of the Monte Carlo Method

As you have probably surmised I have some grave concerns about using the Monte Carlo Method for forecasting software delivery. In my opinion the Monte Carlo Method applies a huge degree of precision to an inaccurate forecast. And applying precision to inaccuracy is dysfunctional behavior. It feels to me that we are using the fog of precision to create an illusion of accuracy.

The weaker the data available upon which to base one’s conclusion, the greater the precision which should be quoted in order to give the data authenticity.

Norman Ralph Augustine

Applying to Software Development

In software projects we tend to apply the reverse of the Monte Carlo Fallacy, we make the assumption that the past accurately predicts the future, so accurately we can give a percentage confidence level. By doing so we are making certain assumptions.

The sample data MUST be reflective of the forecast situation.

Future stories are similar in size, scope, complexity, and effort to the sample data. E.g. early stories are similar to later stories.
Future stories are impacted similarly by external events (we don’t learn or fix problems)
Our ability to do the work is constant
The team does not change, either in size or skill set
The team’s ability to work together does not improve or degrade

The sampledata must be also be statistically independent (results of one event does not impact another).

The future work is not made easier by learning from previous work
The future work is not made harder by adding to a growing code base
We are not creating more rework later than we did at the beginning
Testing, feedback or support do not change as product grows or ages.
We do not improve our skills, or knowledge of the domain.
We do not mitigate problems to prevent recurrence.
We do not learn.

Would you feel comfortable giving that list of caveats along with a Monte Carlo forecast?

Where does Monte Carlo Work?

Monte Carlo Method and the simulations have many useful applications, googling brings up a whole bunch of options, but it works best where observations of sample data can be used to predict behavior. As an example: parcel delivery time, whilst it may change over time it will likely be static enough to predict times based on certain volumes. Or to set reasonable SLAs for an IT help desk where the work is likely consistent in variation.

Where does Monte Carlo NOT Work?

Where it does not work very well is in situations where the sample is small or is not likely reflective of the event being forecasted. Or where past events influence future events, if you learn, or improve or grow, or become over loaded or congested

Monte Carlo magnifies the significance of the sample data. Say you took a sample of 10 items and a 1 in a 100 event occurred Monte Carlo would apply a 1 in 10 significance to that event despite it being 1 in a 100. In software terms an unusually large story or small story or abnormal blocking event can throw off the results by magnifying the significance.

Quick example,

I ask 100 people to solve a puzzle and measure the time each takes.

If I use Monte Carlo forecasting based on the results, it will likely give me a pretty good projection of how the next 100 people will take to complete the puzzle.

If I apply Monte Carlo to forecast how long it will take those same 100 people to complete the same puzzle again it will likely get it completely wrong as some of them will likely get quicker learning from the first attempt.

Forecasting is Hard

The problem is that in most cases Software delivery is uncertain, most software products are complex and the complexity varies from story to story. Work varies, early stories differ in composition, size and scope from later stories, we don’t order work in a manner that balances effort or delivery time, we order based on maximising value. Work evolves, we respond to feedback and we update. We learn, the first time we see a particular problem we may struggle but the next time it is a breeze. As a consequence forecasting is very very hard to do.

NoEstimates helped a lot, we discovered that upfront estimating stories only gave us a marginal gain in accuracy for an upfront cost, and that by simply counting stories and measuring throughput we can get an adequate level of predictability, if we accept and understand the limitations.

Whenever I see a forecast written out to two decimal places, I cannot help but wonder if there is a misunderstanding of the limitations of the data, and an illusion of precision.

Barry Ritholtz

Accurate Forecasting of Software Products is Snake Oil

I am being a touch cynical but it is my experience that in most cases of people using Monte Carlo Simulations for software delivery forecasting it is being used by people that do not fully understand the tool, and the results are being presented to people that do not understand the limitations.

I see people repeatedly tweak the settings until they get the answer they want,
others excluding data they don’t like
others making forecasts based on sample sizes of 6 stories
Many more based on backlogs or stories that include work that will be broken down at the point the work starts
or on backlogs excluding the possibility of new work being added (customer requests or bugs)

And those receiving the predictions believe that when the results say that there is a 90% confidence of hitting a particular date that they are completely unaware and uninformed of the assumptions behind that 90% figure or how it is calculated and there will be a great deal of expectation management needed to fix it later.

K.I.S.S.

I much prefer a simple moving average based on story count, nearly anyone can understand the numbers and the expectations and assertions of precision are absent so the expectation of accuracy is reduced. Good healthy conversation is invited about what might impact the product and it is very easy to see what could be done if the resulting forecast is beyond expectations.

Other than for a desire to dazzle someone with smoke and mirrors or to create false confidence, I struggle to see many situations where Monte Carlo adds any value over and above that which can be achieved with simple calculations. For me there is far more value in everyone understanding the calculation and limitations.

Final word

In the right context and for the right audience the Monte Carlo Method and the simulations are hugely valuable and can be used to great effect. But ensure you understand how and when to use them.

A forecast is only useful if it is data that can be used to make an informed decision to take action.

If you do not fully understand how Monte Carlo Simulations work (including the assumptions and limitations), OR if those you are presenting to, do not fully understand how Monte Carlo Simulations work or it’s limitations then be wary that you are not simply baffling your audience with graphs rather than presenting them with valuable information they can act on. They could be making ill-informed decisions.