I often here phrases like, now when we are agile, can you help me with this now?

Agile do not mean that we shall work ad hock and take in all request that is coming our way, its about;

  • Being able to change direction faster
  • Delivering increments to faster get response back of if we are moving in the right direction
  • Minimizing work in progress, make it possible to focus and not lose valuable time
  • Planning

I am focusing on the planning and moving the release train in this article!

Moving an agile release train forward is challenging, with internal plans and all request from consumers, stakeholders and all other value streams that put pressure on us to deliver what they need.

How shall we plan our work and how do we know what is important, and how shall we cooperate with other sprint teams?

To get more holistically picture we need help with priority from upper part of the organization, but what can we do on our own?

LTP4Scrum can help you sort out what is important and what you shall do now and also plan ahead.

The release train moves you forward and is the way to communicate to stakeholders what they can expect and when they can expect it.

But we are still agile so the content of a release will change due to new facts and new dependencies, with new facts I mean for example knowledge and priorities.

Our cargo is stories from product plans, stories from our product consumers and off course issues and maintenance stories and tasks.

We need to Goal Tree for our product that is built up based our critical success factors that a broken down into all necessary conditions that is needed to make the critical success factors happen.

The Goal tree is readable from top to bottom with the phrases In order to have the Goal we must have the critical success factors, and in order to have the critical success factor we must have the necessary conditions.

We also have product consumers that we shall build small goal trees for and we have issues and maintenances that we also shall build a small goal tree for.

When we have them we can put them all under the umbrella of the release tree.

We use the Release Train to move things forward by planning what each release shall contain.

Colour the tree to indicate what shall go into each release and what is in current sprint and what has already been done.

Your daily sprint work shall be executed via a Kanban/scrum board to assign tasks and to keep sprint communication and documentation going.

A the year of 1984 to important persons release books, Edward Demming a system thinker that helped the Japanese industry recover after the second world war, and many of you have seen the PDCA circle that many is relating to Deming.

Also this year Eliyahu Goldratt that is also a system thinking was realising his first book a business novel called “The Goal” which explains his constrained based thinking and how to use logical thinking tools to identify what to change by first knowing why we shall change.

The concept is simple, first find the constraint and then find a way to handle it.

This means continues improvement where we always focusing on the current constraint we have that is minimizing our capability to improve throughput.

I like to show you a few more books that I think is important.

The Goal and Goldratt has inspired me and many others, Bill Dettmer was teaching Theory Of Constraint for many years for a high school, and in the end he put all materials down into a book “The Logical Thinking Process A Systems Approach to Complex Problem Solving”. I had the opportunity to participate in a classroom training with Bill a few years ago and this was extremely useful for me.

The book ”The Phoenix Project” is a copy of story in “The Goal” but in an IT Organisation, and you that are working in IT will get a lot of laughs when you realise that the characters in the book exists in your own office.

Gene Kim co author of “The Phoenix Project” wrote the book “DevOps Handbook” together with Jez Humble & Patrick Debois all famous in the DevOps communities which takes the inspiration from Lean & Theory Of Constraints into making DevOps successful.

In 1997 or 1998 I stumbled on the newly release book “Critical Chain” by Golratt, I was so fascinated that I started to develop a project management software tool based on the book describing Goldratts project methodology Critical Chain Project Management that is based on constrained based thinking.

On the left side of the slide you can see a few other books that I like to highlight that I have liked, if you look in my book shell at home I am a collector of good books so if you are getting fascinated I can share more interesting hours of reading.

Most of us do not analyse how we draw logical conclusions, I will now show you some difference of result based on how we take decisions.

All logical threads should be readable to make it possible for easy communication.

We have two main types of logical thinking types;

Necessary or need based thinking, which is a top down why of analysing what we need to do to a chive our goal.

This logic build a top down tree that can be read In order to have “this” I must have “this”.

The second logical way of thinking is;

Sufficient or consequent based thinking, which is a bottom up method identifying what will happen if you do something.

This logic is building a tree from bottom up and can be read If I do “this” then “this” will happen.

From childhood your parents and your friends teach you sufficient based thinking and therefor most people have an easy going with using this logic.

If you start thinking about it sufficient or consequent based thinking is very easy to use as you do not have to think the whole but can instead take leap jumps and only detail down the first steps.

I will now give you an exercise to use the Sufficient logic and pick all thinks that we need to do in the order they have to be done with the goal “I am eating pancakes”.

Start from bottom and what do I have to have first and then move upwards.

In then end you shall be able to read the tree from bottom and up with the wordings;

If I have ”this” & I have “this” then I have “this”

This exercise is a bit fun and easy to do and almost always result in the same structure.

We shall use sufficient logic.

Bottom to top, If I have this I can do

Plan by putting the pictures in dependency order

Read it load when you built it

If I have/do this and I have/do this

then I a can have/do this

Lets read the tree from bottom and up, doing so we LOAD will help us validate if we have taken the right decisions, if something comes out wrong then it is wrong.

If I have the ingrediencies, like egg, milk, butter, flour I can mix the pancake batter

If I have a cocker & I have the pancake batter I can cook pancakes

If I can cook pancakes I have pancakes

If I have pancakes & I have knife and fork & I have a glass of milk & I have strawberry yam I am eating pancakes

Now lets do a new exercise and use necessary or need based logic we start from the top with the goal “I am eating pancakes” and then we are asking ourself what is the last things I need to have or do before it is possible to be eating pancakes?

In the end we shall be able to validate this tree from top to bottom by reading it with the wording;

In order to be eating pancakes I must “xx” etc.

This exercise is the same but now we use necessity logic, In order to have this I must have/do this and I must have/do this.

Focus on what you really need it shall only be the things needed to make things happen.

Top down, what is the last things I need?

Plan by putting the pictures in dependency order

Read it load when you built it

In Order to have this

I must have/do this and I must have/do this

In order to eat pancakes I must have pancakes.

In order to have pancakes, I must fry pancakes

In order to fry pancakes, I must have a cocker and pancake mix.

In order to have pancake mix, I must have butter & I must have egg & I must have milk

When we use sufficient logic it is very easy to add in things that we do not need.

When using necessary logic, we focus on the minimum requirements for success.

We need to work with the product consumers to identify what they need so we can build the consumer goal trees.

This is a bit of a challenges as most people brings a wish list and not the list of what they really need so I have a few questions when planning.

  • If I bring this in to the sprint, when will you consume it? When do you really need it?
  • Is this necessary for you to meet your goal?

Asking this questions helps us sort out needed things from winches, if a consumer has a dependency on us they want to remove this dependency as early as possible even if they are not going to use it, but if this work is done to early they prevent more important work from happening.

Now to planning the sprint, select the most important leaf’s in your tree that is planned for this release and bring the in to be planned.

Mark them by changing the colour in the Goal tree so it is clear what is part of the sprint.

Create a sprint plan by using the necessity logic and break down the stories into task and clearly line up the dependency’s.

Read the tree load to validate that you have captured all necessary tasks that has to be done.

If it do not sound logic to you, then something is wrong, missed out by taking a leap jump in the logic or, not added all dependencies or not made the text clear enough.

Necessity logic is done from top to bottom and execution starts from bottom to top

If you now line it horizontally you actually dry run your sprint so you know when things has to be done for the sprint to be done.

It is also very clear when a task is going to block the whole chain.

This can be used for communication, as some consumers are interested in when in the sprint they can expect a task to be done.

In the picture you see two circles and they indicate that we have a slack for the left task, but if it is not done before or latest at the same time the purple circled task it will block your sprint.

Some teams uses a PPT to document and track the Sprint Goal Tree’s, as they often ends up with multiple small trees.

And often like in this case the logic is not necessity based, instead it is sufficient logic used to create the tree.

When it comes to sprint it does not really matter what logic you use when you build the tree, but read it load.

You can actually read it top down or bottom up with the two different wordings for the different logics to help you validate the tree.

Necessary or need based thinking

Top down, by identifying the necessary things you need to fulfil the objective

In Order to have this I must have/do this and I must have/do this

Sufficient or consequent based thinking

Bottom up, identifying what you need to make the parent happen

If I do this and I do this then this will happen

Now when you have this tree’s it is very convenient to use them with colours to visualizing what has been done, what you are working on ad what is blocking you.

And do not stop using your scrum & Kanban board, as it is needed to assign people with and to keep notes of what we do and push a task between team members.

DO NOT USE MAIL to pass responsibility around it will end up in a disaster, where things has not been done, as many key peoples mailboxes are flooding over with information mails.

How do we know we have the right things in our backlog?

We need to build a Goal Tree and plan ahead so we secure we have all epics and stories and that we are aware and working with our constraints.

We need to define our Goal.

If the Goal is not clear, non important things will be prioritised and we actually might have a very low productivity.

Do not be like Alice in wonderland, moving randomly forward, state your Goal so you know where the real north is on your map.

But what is a goal?

The Goal is where your compass true north is, the end point of the game, where you want to be now and in the future.

A simplified Goal is “We earn money now and in the future”, this is a little vague Goal as it do not state the amount we want to earn to for us to be satisfied.

Use SMART as guideline for defining your Goal, but ignore the time bound part and instead focus on a continues state we want to be at the Goal Now And For Ever.

If you run a project then the time aspect must be in the Goal.

The Goal cannot stay on its own, as the Goal “We earn money now and in the future” do not describe how we shall do this, so we need to break it down into all necessary conditions that we need to get to the Goal.

When we break it down we will also take some tactical decisions of how we are going to earn money, the tactical decision might change over time, if it turns out that you see better way of earning money you should change your tactical decision.

But how do I know the Goal is in the boundaries of what I can do?

We need to define the system for which the Goal is going to be set!

The system, if you run a company the system is your company, and if the company is large you will have departments that will have their own Goal, but make sure that the department Goal is helping the SYSTEM the company reach its Goal otherwise you have local optimizations.

A local optima can also happen when the leader of a department is more interested in his/her own career, than the company Goal.

In this picture you can see me, in my apartment that is part of a large house with multiple apartments.

I am in control of my apartment and what I do within it, this is my sphere of control.

Around me I have my neighbours that are rather noisy, drilling in our shared wall, my neighbours are my sphere of influence.

Outside the sun is shining and the sky is blue, this is an example of things I can not control and just has to accept and work with.

When we set our Goal we need to know how our system boundaries are, what do we control, what can we influence and what are the most important things we need to accept as fixed constraints when we plan.

So how does your system look like?

It is time to define your Goal now.

Who can define the Goal?

Only the system owner can define the Goal, he/she/they can off course get help from the staff and other people but in the end it is the system owner that has to take the decision.

Now it is your turn, take the time to define the Goal, you will need it for next step.

A Goal cannot stand on its own, the Goal shall be crisp and cannot contain all details, so we need to add one layer of necessary conditions around the Goal and we call then our Critical Success Factors.

The Critical Success Factors together with the Goal is defining the systems purpose and boundaries, and for a project it defines the scope of the project.

The Goal and Critical Success Factors shall be consistent over time, if they do not then they are not your Critical Success Factors, they are part of your tactical necessary conditions that are children to one or more of the Critical Success Factors, but more on that later.

As a thumb of rule 3 to 5 Critical success factors is good, but put in the ones you need.

An example of a simplified Goal for a company is “Earn money now and in the future”, to make this happen we need to break the Goal down into our Critical Success Factors.

If we read it;

In order to Earn Money now and in the future we must Maximize throughput and minimize Operational Expense and Minimize Inventory.

Maximizing throughput means that we maximize the consumption of our services or product consumption, this controls the amount of money coming into to us.

Minimizing Operational Expense is in balance with what we need to maximize the throughput, and is the cost we have for running the business and produce services and products for consumption. We need enough staff to secure we can maximize the throughput so that this is not our constraint.

Minimizing Inventory is in balance with what we need to maximize throughput, and is the money bound up in materials and other things needed to build and provide our services and products. We need enough inventory to secure it is not the constraint of our capability to maximize our throughput to our consumers.

For a company or department we need a few more Critical Success factors but as a generalized definition, and on an department level you will most likely have this critical success factors as necessary conditions, ether clearly defined or hidden in other terms or phrases.

Now it is time for you to create your own Critical Success Factors.

Do this with your team, select the people you need to have, not only managers but workers as well that will help you identify and clearly specify the Critical Success Factor.

Now when we have the Goal and our Critical Success Factors it is time to break them down into all necessary conditions we need to make them happen.

In above picture the Critical Success Factors are marked as N1 to N4 and broken down with W1 to W7.

The W1 are necessary for N1 to happen, but W1 often can be done in multiple ways, we need to take a tactical decision.

Our Tactical decision has consequences as to make them happen a bunch of necessary conditions need to be fulfilled.

For example if our need is to have a functionality that can be provided with a software, it is likely we will find multiple software that meets our requirements, but when we select one it has consequences, if one is extremely expensive the necessary condition is that we have the money to spend.

Or tactical decisions the W boxes in the picture sometimes causes a conflict, a conflict is when one W prevents a N to happen.

In the picture we see this happen, where W1 is needed to make N1 happen, but at the same time it prevents N2 from happen, we then have a conflict between W1 and W2.

I will who you example on that soon.

But back to creating our Goal Tree.

I have created a focus glass so we can focus in, lets focus in on our Goal and then create first layer of Necessary Conditions.

The Necessary conditions is the needs to be there to full fill our Critical Success Factors, but we have options so the Necessary Conditions are also representing our tactical decisions, what we want to do to make the Critical Success Factors happen.

For example if we are starting a new company, and the Goal is to earn money now and in the future, we need to take a tactical decision in how we shall earn this money, shall we produce cars, sell bicycles?

When we have defined our first layer of Necessary Conditions we move the focus glass downwards to each Necessary conditions in turn and will create the 4th and 5th layers of Necessary Conditions, see next picture.

We move to each of the Necessary Conditions on the in our third layer and break it down two levels into to the need and the tactical decisions.

And we use the necessity logic In order to have the zoomed in Necessary Condition we must have must have 4th layer of Necessary Conditions.

For each of the 4th layer of Necessary conditions we do the same thing but we also take in a tactical aspect.

Why do I propose this?

Because we need to secure that we have all Necessary Conditions in place for a tactical decisions, if all layers are more tactical decisions we will miss out the full necessary aspect of fulfilling the parents as we very likely we take some short cuts.

When we are done and satisfied with our Goal Tree, we should add in measurements, so we can measure our progress to the Goal.

If our Goal is to Earn Money now and in the future, our measure should be how much money we earn, so we can see if we have a dip, and if we have we need to find out our constraint that is causing this dip.

But be careful, I have seen so many measurements that someone else has forced up on a team, that has no relation to the staffs daily work and is just causing issues.

A measure shall help you secure that we focus on the right things that brings us to the Goal, it shall bring value to the team and be a help of guidance and stimulation.

It can be a challenge to meet the expectations of the Measure but it needs to be realistic and helping you.

If we measure how much money we earn, the expected result shall be stated, like we shall earn this amount of money every month by the end of the year.

This is setting an expectation on the result and we also have the mean to find the constraints in our system that needs to be sorted out to secure that we reach the level of expectations of the measurement,

But be aware, by measuring we will enforce behaviour, if we have wrong measurement people will behave wrong.

This quote from Goldratt is expressing it very well;

Tell me how you measure me,

and I will tell you how I will behave.

If you measure me in an illogical way…

do not complain about illogical behaviour…

O no, we have a conflict, and how shall we handle it?

As I stated earlier, a conflict appears when we want to do something that is then preventing another thing to happen.

In this picture we have Necessary Condition N1 and N2 and we have defines our tactical decision W1 to be necessary to make N1 happen and the tactical decision W2 to be needed for N2 to happen.

In this example W1 prevent N2 from happen and we have a conflict.

How do you handle conflicts today?

Most people used one of following methods for solving a conflict;

  • One side gives up because they don’t want to deal with the problem?
  • One side forces the other side to give up?
  • One or both sides ignore the problem?
  • The sides negotiate a compromise?

All of them results in that at least one side loses, and the worst one that is very often used where we solve it by compromising both sides lose.

When you have a conflict use this graph to visualize it, as just by visualizing it you might find out that you do not have a conflict or you will quickly see how you shall resolve the conflict, in any cases it makes it possible to communicate what the conflict really is about.

This picture helps you understand how you shall populate the graph.

So if you start with the purple boxes and describe what you want to do and how the conflict happens.

You can then for W1 define the N1, by defining what need are we fulfilling by by the action in W1.

We do the same by defining N2.

We now need to find the common objective for N1 and N2, what necessary Condition are they fulfilling.

Use the Necessity logic validate the graph in the same way as you validate the Goal Tree.

In order to have “Common objective” we must have N1 and N2, in order to have N1 we must have W1 and in order to have N2 we must have W2.

If this do not sound logical it is not logical.

But if it sound logical we need to find a way of securing that it is actually correct, we add in all our assumptions.

In each relation and box we can add assumptions but start with all assumptions for W1 and W2.

Use strong wordings in the assumptions like WE MUST, etc.

To give you a real example let’s look at next picture.

My and my family was buying an apartment in Spain and our Goal Tree contains many things as I indicate in the tree in the top right corner, but W1 and W2 was causing a conflict.

My wife wanted the apartment at the beach and I did not, and we can not do both.

So shall we compromise or shall I lose or shall she lose?

No we are both the winning type so we solved it by a win-win solution.

To do so we had to but in strong worded assumptions to find out if W1 and W2 was really valid or if N1 and N2 was really valid.

In the end we replaced the W1 and W2 with new statements that removed the conflict and we have now had an apartment in Spain for 5 years and we are both very happy with the result.

I am not going to show you have we solved it, it is here so you can have a real example of a conflict.

It’s time for you to create at least two levels of necessary conditions in your Goal Tree, take the time with the key people you need to do this before we go into next part, the release train.

We have now defined our System boundaries of what we control, what we can influence and the limitations we have to accepts, the limitation can be laws etc.

We have defined our Goal, our Critical Success Factors and by so defined the scope of the project and the purpose of the system.

We have also broken down and created at least three levels in our Goal Tree, you will need many more levels, but we are ready to start defining our Releases and make the release train move.

Do you want a slow train or a fast train?

If you want a fast train we need to Maximize the Throughput, by increasing the consumption of our services or products, to do this we need to know where our current constrain is.

But more on that later.

What cargo do our train bring with it?

Parts from our Goal Tree, Consumption of what we provide, issues, maintenance and other operational things like support etc.

We want this train to deliver a lot in each release, so we maximize the throughput, we need to plan well.

The release makes it possible for the staff to focus on the short term perspective, it is also a way of interactive with the consumers of your service, products on what they can expect to get.

To make this work you need to have a good cooperation between your release team and other release teams that are depending on your deliveries.

A release shall be fixed in time, so you can communicate internally as well as to consumer.

The content shall be estimated but as we are agile it will change, so the content of the release when first planned will not be the same as you deliver, why?

  • We get new information and have to adjust
  • Organisation and your consumers will change based on the new information they get and will then change the priority for their own work.

A sprint is a sub delivery of a release.

In a sprint we have stories from our Goal Tree, we have issues and operational activities, we have consumer stories.

All this needs to be planned well, so we secure that we deliver what is needed for the future consumption and that we need the needs from our consumers current need.

It’s a tricky mix.

Use the Goal Tree as the core of all planning work, add more branches and leaf’s to it, validate extension request from the consumers against the Goal Tree, shall you add it or not, Goal Tree makes it easier to say no, and also to prioritise things you take in and estimate when you can deliver it.

Your backlog will contain other things that is not in your Goal Tree, like consumption stories, operational task etc.

The best is to create small Goal Trees for the main consumer/stakeholders.

Do not add your whole Goal Tree into the Backlog add the things for next release.

As you also has to prioritise the backlog based on when things shall be delivered.

For example in your Goal Tree you pick to leaf’s and putting them in the backlog of your Kanban system, now you need to order them based on priority of delivery.

The Goal tree do not contain the low level priority, you need to decide that based on the Goal Tree, what is most important to achieve first.

In this picture we have an umbrella node that I call the release train, I use this top level to map in our Goal Tree, left tree in the picture and all small consumer trees and other operation tree’s that we want to get a common overview over.

In my last project I introduced a mind mapping tool to work with the trees, they do not look like a ordinary tree, more like a web, but it does not matter.

Most min mapping tools also have limitation, so as you see in this picture a necessary condition has dependencies upwards to more than one Critical Success Factor , this is not so easy to represent in a mind mapping tool, so I used symbols to represent the dependency between different branches of the tree, one symbol for a dependency to and another symbol for a dependency from, not optimal but good enough.

Colour the stories based on which release it shall be in, and also colour the stories that is in current sprint, and then mark things green when done, you then get a very good overview of the situation and your plans.

Why not just use backlog in your Kanban system?

A backlog do not give you the overview, you need a better tool to visualizing what you need to do as it is a tree based dependency and a flat structure is not helping you with controlling and validation of dependencies.

A Goal Tree is very simple to learn and to use, and it will offer you control, visual overview and a way to communicating decisions and needs to you managers as well as to your staff and your stakeholders (consumers)

And continue use your Kanban board, bot do not flood the Kanban backlog with everything, put in current release, and before next release start add that to the Kanban back log.

Its crucial to plan ahead, plan ahead is one of your Critical Success Factors to make your release train move forward in a consistent speed.

Bad planning causes your train to halt, and go slowly.

So how do we do this?

Drive everything from your Release Tree’s , you have the overview of what you need to do, this is your backlog.

From Release Tree, you pick the leaf’s and populate for upcoming Release, you also identify what’s going to into next release.

You populate the Kanban backlog with the stories for upcoming release.

You then select the subset that is for the sprint, and break it down into task.

You do the same for next sprint, and break it down into task, and if you find task that are external dependencies, you move them into the current sprint.

You now are planning ahead so you have two rolling releases planned all the time.

You also have two sprints planned all the time, and you push dependencies from second sprint to first sprint to secure that they are not blocking you in second sprint.

And we are off course agile so your plan will be wrong and continuedly have to be adjusted so only populate Kanban backlog with things you will do in near time, keep the rest in the tree.

When you plan balance your Goal Tree, with stories from consumers, and the operational work that is needed.

Work with your constraints, the previous picture and way of working handles some of your constraints but you will have more.

So look at what you have in the sprint and identify the sprint constraints, if it is a specific person that has special skills, then remove other work from that person so you secure that time is enough for the specialist work.

Goldratt provides a five step process to work with constraints;

  1. Identify the system constraint.
    • Find the constraint, in any way you can
  2. Decide how to exploit the system constraint.
    • How can we get the most out of this constraint sector
  3. Subordinate everything else to the system constraint.
    • Free up by removing all work that do not have to use the constraint resource, if it is a person remove all other work from that person that is not directly related to the constraint work
  4. If necessary, elevate the system constraint.
    • Add in more resources if needed
  5. Return to Step 1
    • Find next constraint

What kind of constraints can we have?

This is the list of the most common constraints;

  1. Resource/Capacity Constraints
  2. Market Constraints
  3. Material Constraints
  4. Supplier/Vendor Constraints
  5. Financial Constraints
  6. Knowledge/Competence Constraints
  7. Policy Constraints

Resource Constraint is probably one of the most common constraints we have, together with financial constraints.

Watch out for Policy constraints, you might not even be aware of them, some times they are part of your culture, but with open eyes you will spot them.

I think you already understand how constraints affect us, but just to elaborate a little bit more.

All of us is working in a chain of work, things are broken up into steps that are part of your process for delivering, sometimes one step is passed over to another part of your organisation which often causes a longer lead time then if it can be done within the same part of the organisation.

In the upper right diagram we have 4 steps, and we can clearly see that step 3 is our constraint and then step 2 is also slow.

If we let each step utilize its capacity to the maximum, the effect is that we are building up queue further down the chain.

In the lower right picture this is clearly demonstrated that before step 2 will are building up a queue and before step 3 we are building up an even larger queue.

If you are in manufacturing, this will increase your inventory cost as your queue are inventory on the shell that cannot be consumed, which is expensive.

If you are in other business like software development it means that you have a delay and this part of the organisation will most like start delivering based on who is screaming loudest and you will not deliver the most important things.

The picture is borrowed from a Bob Sproull’s latest book.

That was all for now, I hope this presentation was giving you some thoughts and ideas.

And like a friend of mine always says, make the tools yours, it’s you that shall benefit from them in the best way.

Good Luck

 

One thought on “LTP4Scrum or Goal Tree based planning”

  1. One of the best writeups I have seen in recent years. The clarity with which the same subject matter i.e. ‘Eating Pancakes’ is explained using both Necessary and Sufficient Logics is amazingly simple and clear. Many thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *