DMAIC

Anyone who has heard of Lean Six Sigma has heard of DMAIC. Its a method of root cause analysis for solutions that are not already known.

Regardless of what you think of Lean Six Sigma, I thing the tools are worth while having in my mental toolbox.

For some reason, L6S (Lean Six Sigma) likes its acronyms. You have DOWNTIME for waste and SIPOC for Suppliers, Inputs, Outputs and Customers, but today I’d like to talk about DMAIC. DMAIC is another variation of a feedback loop, much like the OODA loop, PDCA and the Lean Startup Loop.

DMAIC Stands for (if you haven’t got it from the title)
Define – Define the problem
Measure – Work out how you are going to measure the problem and its variation then get a baseline measurement.
Analyze – Analyze the process that the problem is under. Collect the data and determine the root cause, the defect or any other form of problem such as waste.
Improve – Develop and implement a solution to remove or diminish the problem. Confirm your improvement with data using the method determined in the Measure phase.
Control – Maintain the gains. This can be done by documenting the improved process and continuously monitoring to make sure that the problem doesn’t surface again.

Lets go into these in a little more detail.

Define

In the define phase, you try to gain a little more clarity on the problem that is occurring and what you are trying to improve. This helps determine the focus of the improvement efforts.
Here you write down exactly what you want to achieve. In L6S, they recommend doing what they call a Project Charter. I’m not going to focus on this. I’m just going to focus on the basics.
The first thing that I think is important is to state your problem. Now, a good problem statement does not propose a root cause or a solution.  So for example, “Implement Automated testing” is not a good problem statement. Nor should you blame anyone for the problem. “John continuously makes more errors that Jane” for example.
A good problem statement will answer the following questions.

• What is the problem or issue?
• What is the measure that you are trying to impact?

So a poor problem statement may be:
We have too many defects during the development process

A better one may be:
Since the project began (when), We have an average of 15 defects (Magnitude) per sprint that cause significant delays to the delivery of the product. (Impact)

As you can see, I have used 3 terms to put into context the problem. When, Magnitude and Impact.

The next thing to try to determine is a goal.  Using our defect example, a goal may be:
To Decrease (verb) the defect (what) rate from an average of 15 per sprint down 50% to 7 per sprint (improvement) within the next 2 sprints (timeline).

Again, I have highlighted sections of the statement. The verb, to describe what you are trying to achieve. The what you are focusing on, the improvement, or expected results and finally a timeline that this “experiment” will take place.

There are a few more sections that are part of a problem statement from L6S, but I’m not going to go through them here.

Measure

The measure phase is where you determine how you are going to measure the current state and the effect.
Here you determine if the problem actually exists by gaining a baseline measurement and try to understand exactly what is happening.
By using the same methods that you used to determine the baseline, you are able to determine the amount of improvement that has occurred and whether or not you have reached your target.
So what can be measured?
In our example, we are just using “defects”, but you could also use

• Cycle time
• Days
• Size
• Currency (Such as Dollars, Pounds, Pesos etc)
• Any other type of measurement relevant to the problem.

The key here is to collect meaningful data that will help you understand the problem and help you determine if you have made an impact during your “Improvement” phase.

Some questions that may help you determine a measurement may be:

• What are you trying to measure?
• Why do you need it?
• Where in the process does the measurement exist?
• How would you define the measure?
• Where is the data sourced from?
• How will the data be collected?
• When will the data be collected?
• How will you make sure that the data is valid?

We then may want to graph the data in a histogram for example to get a visual idea on the problem.

Analysis

In the Analysis phase, we have had our measurements going, now its time to determine the root cause. Given the data retrieved through the Measurement phase, we use techniques determine the root cause. This requires investigation. Probing the data, playing around with the data. Trying different things to see the effect. These can be determined by using techniques such as process mapping, brainstorming, the fishbone diagram, 5 whys,  even Trial and Error. Basically any problem analysis tool.

The whole idea of the Analysis phase is to prove the root cause rather than jumping to conclusions.
Sometimes you need to think outside the box to find the root cause. Something what seems obvious, may only be a symptom. Its worth while digging deeper just in case.

Determine a hypothesis for the root cause. This is a theory, opinion or guess as to what the problem is. Then research your hypothesis and prove it with data, but don’t get caught in “Analysis/Paralysis” where you continuously analyse without actually doing anything. You have to stop sometime and giving yourself a time box can help with that.

Questions you can ask yourself after the analysis phase is:

• Has the root cause been verified by process analysis and data analysis?
• Has enough been targeted?
• Would additional analysis cost more that what it is worth?

Improvement

The improvement phase is where you address the root cause and try to correct it.

The improvement may not be implemented straight away. You may decide to run a pilot or Proof Of Concept to determine if the solution actually fixes the problem, but ultimately the problem should be fixed or reduced.

Using the techniques developed during the Measurement phase, you can determine whether or not the improvement has actually worked and whether or not you have reached the target. This is important as this is part of the feedback loop. We have a tendency to implement “improvements” and not verify them. They are in – great! now move onto the next thing. The problem with this thinking is that you do not know if the improvement actually worked or not. This is common sense, but common sense is rarely implemented.

If you have reached or exceeded your target – excellent! If not, then maybe you need to tweak or rethink your solution and try again.

Control

The control phase is making sure that your improvement remains. Here you need to determine a clear plan for maintaining the process. The system will need to be monitored to make sure that the problem doesn’t surface again and if it does, what countermeasures will be needed. This is to determine long term success.

We do not need to have the same degree of measurement that we had during the previous phases as the root cause has been determined (We are no longer fishing for the problem) we just need enough information to determine that all is well.

Questions that should be answered are:

• What is to be measured?
• How will the measurement be checked?
• How often will the measurement be collected?
• Who is responsible for gathering the data?

You may also want to document the process taken for the improvement plan showing the problem, the root cause analysis, the improvement taken and what controls are in place to prevent the problem from happening again. This could be used for future reference.

In Closing

The DMAIC process seems intensive, it is. There is also quite a bit of the DMAIC process that I haven’t covered in this post, but it does formalise the problem solving process and its implementation of the resolution and for that, I think it is worth trying. Even just for an experiment.

For more information on Lean Six Sigma, I recommend doing the free Yellow Belt Training at Go Lean Six Sigma.
In order to get the “certification” you need to pay and take the test, but the training itself is free and free education is always good.

I’m currently reading Tim Harford’s Messy and the Chapter on Collaboration I found interesting. Especially the section on the Robbers Cave Experiment. I find psychology experiments interesting. They show a lot about the human psyche that seems to get ignored.

This particular experiment took place in 1954. Eleven boys of around the age of 11 and 12. All Caucasian, all being protestant and middle class. This was on purpose to reduce the number of variables for the experiment.
The boys were then taken to Robbers Cave State Park in Oklahoma US. Named because Jesse James and other outlaws used it as a hide out.

The First Stage – Bonding

The first stage was the bonding phase. Before the boys boarded the bus, many of them started to make friends. Other activities during the camp of the first week such as swimming and hiking took place. The groups themselves took a name. The Rattlers from a rattle snake that entered the camp. They boys became good friends.
We see this type of bonding happen with teams that are thrown together in a working environment. I’ve seen this happen many times. There is one particular team that I worked with. We were a whole bunch of contractors back in 2005. We worked together on a project and every few years we get together for a lunch to catch up. There is no other team that I have worked with that does that.

Now, little did these boys know, was that a second group of eleven boys. Also aged between 11 and 12 and they were doing the same thing on the other side of the park. Their name was the Eagles. They bonded just as well as the Rattlers.

The Second Phase – Competition

This leads to the second phase of the experiment that took place on the second week. The Competition Phase. Teams started to compete with one another in such activities as Baseball, Touch Football, A Treasure hunt and so forth. Each team was pitted against the other to cause friction. The camp councilors manipulated things to cause an adversarial relationship between the two groups, but a lot of it ended up not being needed. The boys started hating the other for the simple reason, the other group was not “Their” group. Name calling, Fights started, vandalism of the other teams property occurred.  Things really got out of hand (but no one was seriously injured as the councilors stepped in when required).
As adults we see this type of thing happen all around us. Many wars have been fought and continue to be fought on the same premise. In the office, we see this as a rivalry between teams. An us against them. Workers against Management.  IT department against the Finance Department. We do not see things get out of hand (At least a majority of the time) but the friction is still there.  Actually, the story of how NUMMI started out is a good example of how conflict between workers and management can get out of hand. Things got so bad at the GM plant that workers would sabotage cars, drink and take drugs on the line among other things.
In many work places, an underlying rivalry is normal, although usually ignored because it is done in a civil way. For example, every time you think a department is useless, or incompetent, but your team is great and faultless. We have all done this at some point, it is human nature, but we are propagating the rivalry.

The Final Phase – Reduce Friction

The final phase of the experiment was to reduce the friction between the two teams. This was done by bringing the two groups together in non-competitive activities such as watching movies, campfire sing songs and so forth. These types of activities did not work – as expected. Even in the real world, we have team lunches to try to reduce tension and friction within a team, team activities like laser tag, or those team building camps I keep hearing about, but never attended. These types of activities do not work. Yes everyone has a bit of fun during the period, and if your team is already working well, they are great, but as a method to get a team in friction to be a more cohesive whole, they are pretty much useless. My thoughts are simply that these situations are social situations. Completely different to the work situation. They do not build up trust.  If there is no trust before the activity, there will still be no trust after the activity.
In the experiment, the only way the two teams got over their differences was to work together to solve a mutual problem. For example, the councilors unbeknownst to the boys sabotaged the water tank and water supply. They boys had to work together to try to solve the problem. Another, a truck got stuck and the boys had to work together to get it out.
I’ve seen this many times in my career. I have always said, “If you want people to get together, have them work together”. In this situation, provided everyone is treated equally, you gain a mutual respect for one another.  In the book “Team Of Teams by General Stanley McChrystal“, McChrystal talks about how he got the various military forces to work together. They would take someone out for example, the Army and place them within a Marines unit. They would stay there for 6 months of so if I remember correctly. Enough time for the unit to work with the new member, and gain each others trust, which is difficult when lives are on the line. That member would then return to their original unit.
What this achieved was a reduction of the degrees of separation between anyone within one military force to another military force. Taking our Army/Marines example, if the Army needed something from the Marines, intelligence, co-operation for an exercise etc. Normally each “silo unit” would resist politely. But after this method of seeding, the Army would approach the soldier who spent time with the Marines. They would then contact their buddies who would help out a friend. The same thing vice versa. Now, where you had rivalry, you now have co-operation.

 Applying The Lessons

If you want your people to work as a team, then you need to give them all a common problem or goal to work towards. A goal that is simply to get the work done just won’t cut it. Not if you want a high performing team, and what Manager doesn’t want that. The goal has to be greater than the team. Something that will inspire.

I am reminded of the story of the 3 bricklayers.

Once there was 3 bricklayers. Each one was asked what they were doing. 
The first one responds grumpily, “Laying Bricks”.
The second one responds indifferently “Building a wall”.
The third one responds enthusiastically, “I’m building a cathedral”.

It is managements job to find a way to inspire their people so that they feel that they are building a cathedral, not simply laying bricks.

In Scrum, the process of having everyone in the team work towards a common goal is written in the guide. This hasn’t been added for show, having people working towards a common goal is a proven way to get people to work well together, and work together well.

The second lesson is to remove the reasons for friction between two groups. In Scrum, there is the concept of “Servant Leadership” where management is there to “help” and “guide” the workers much like a teacher or a coach. They do not order people around like traditional management. Ordering people around creates a sense of “us and them”. Whereas servant leadership promotes a sense of collaboration and uplifting.

The third lesson is to make sure that every team works together, and trusts one another, even if it is just one representative from each team for a short period. It may only take as little as a week for people to bond. Encourage collaboration and your people will do great things.

For more information on the Robbers Cave Experiment see
5 Minute History Lesson, Episode 3: Robbers Cave

In a previous post I briefly mentioned the 5 Whys technique as a method for problem exploration. Today, I would like to explore it further.

The 5 Whys Technique

The 5 Whys technique is another simple technique to explore and try to find the root cause of a problem. The premise is quite simple. As the name suggests, you ask “Why” 5 times. The thing is, that you do not ask the same “why” every time. You delve deeper.
How do you do this? Well, you have an undesirable effect. This is your problem. You ask “Why did this problem occur?”. This is your first “why”. You then answer this question. This answer is your “cause”, but is it? It could be another undesirable effect masquerading as a cause. So you ask again “Why did this cause (Now an effect) occur?”
This is our second “why”. You then repeat the process until you get to the actual cause. Sometimes you might get to the real cause straight away, sometimes you have to delve a lot deeper, but the premise of the technique is that you have to ask at least 5 times to really root out the cause of the problem.

An Example

Lets have a look at a completely made up example:
Undesirable Effect : John didn’t update the documentation.
1st Why : Why didn’t John update the documentation?
Cause : Because he forgot to update it.
2nd Why: Why did John forget to update the documentation?
Cause : He wasn’t prompted to.
3rd Why: Why wasn’t John prompted to?
Cause : Because there is no list of tasks on what to do after completing development.
4th Why : Why is there no list of tasks on what should be completed after development?
Cause : Because there is an underlying understanding that certain tasks would be done.
5th Why : If there is an underlying understanding of the list of tasks that should be done, then why did John still forget?
Cause : Because John is human, and the human memory is fallible.
6th Why : Why is something so important so reliant on something fallible?
Cause : Because if something is forgotten, it is easier to blame rather than look for a method to make sure that something is never forgotten.

In this example, 5 whys didn’t seem to get to the root cause. Rather than give up, keep going deeper. In this made up example, something as simple as forgetting to update documentation has a more deeper cultural issue that should be addressed. You could have stopped at the first why, and just have told John to update the documentation. Problem solved – at least until someone else forgets to update the doco. The next time it might not get cause, and thus your doco is out of date. Instead by looking deeper at the problem you start to think of ways to have the documentation tell you it needs updating. For example using Concordion, Fitnesse, Cucumber or simply a list of things to check off to make sure you have done everything needed, or even get innovative and find your own solution to the problem.

Where do Trees Fit in?

Now, from the previous example, you can see that there is a more systemic issue than the one initially presented. The thing is, that a number of the problems you are having, might actually be caused by the same root problem.

If you map these out, then you might find that the structure resembles a tree. You might see that one root cause is actually creating a whole heap of undesirable effects and by simply addressing that root cause, you may resolve a whole heap of underlying problems.  Creating a Current Reality Tree is very hard work. The more problems you start out with , the longer it will take to drill down, but be prepared through, you may find something you won’t like.

Summary

The 5 Whys and the Current Reality Tree are a couple more methods to determine the underlying cause of issues and problems that you are having. The problem is that you may not like these causes. As humans, we do not like to hear that something that we are doing is fundamentally wrong. Therefore we tend to ignore the issue and solve the more simple problem. I myself am guilty of doing that on numerous occasions. That is ok, you may not be ready for whatever reason, but what is important is that you are aware .

There are many leaders and managers out there that think that the purpose of leadership is to direct people on what they should do. These sorts of leaders think that their job it to tell, and then have their minions follow. To some extent they not only tell their minions what to do, but also how to do it. Now, there is a time and a place for this sort of leadership, but there is a price. The price isn’t necessarily paid by the leader, but by those that are under them.
This is especially true where those “minions” work under positions that require high demand. There have been many studies that show the link between low control and high demand jobs and how unhealthy they are, but a study released in November 2016  linked the demand of the job to the amount of control of the job to the mortality rate.

What it found was that those in high demand, but low control jobs. The type of job where the leader is directing you, there is a 15.4% increase in the mortality rate than those in low control, low demand. The surprising thing found was that those under high demand, but high control, where you have a say in how you work, there is an 34% decrease in the mortality rate. High control leaders are literally killing their people. Not to mention increasing the chances burnout, stress or other unhealthy psychological issues.

I hear you say that the demands on a leader are high too, yes they are, but, so is the control. The price of bad leadership is paid for by not by the leader, but by those under them.
This is not always the case, some people have a high tolerance for no control, others may not. If you combine this with an environment where you cannot discuss issues, openly, where the culture is to hide rather than make open then the higher price is more likely to be paid. Especially if those that are under strain hide it well, then no one at work will know, not until things really boil over, then it may be too late.

I have no doubt that leaders of this type have good intentions. It may be to make sure the work is being done. Make sure that the work is being done right, but the question I ask is “Is it worth the price?”

So how do you give control to those under you while still getting the work done? One answer may be to set the outcome required, the constraints, make them clear, but leave enough wiggle room for those doing the work to do it how they want. Not how you want. Let them make the decisions on how they do the work.Those under you may fail, they may do the wrong thing, but make an environment where the damage is limited.
Let people figure out problems themselves, if they ask for help, don’t take over, give them enough to lead them in the right direction where possible.
This helps those under you learn. They learn to make the right decisions. They learn to do the job better. They work because it benefits them in the form of mastery, they become more engaged This benefits the leader too. No more managing everything, you have more free time. Stuff gets done quicker as people do not have to wait for your input and decisions.

This may be one method, but I suggest thinking through your own way to give your people more control. Dare I say it, include your people in the discussion. Let them help you figure this out.

This is a big step. You yourself are going to fail, your people will stumble, and there will be temptation to go back to controlling everything, it is so much easier to do. It may take months or even years to turn, but the benefits can be worth it. What you had previously was leadership through fear. Those under you feared losing their jobs, peer pressure kept them from speaking out (although it may not have stopped them from talking about you behind your back). What you are building now is leadership built on trust and trust can be hard to gain in this circumstance.

For further reading, I highly recommend:
Turn The Ship Around by L David Marquet
Team of Teams by G Stanley McChrystal
Multipliers by Liz Wiseman
Leaders Eat Last by Simon Sinek

 

Some people think that Agile is a process that you follow. You do the stand ups, have the board, ceremonies etc.  Even if you do these things, even if you follow Scrum, Kanban, Lean Software, Crystal, DevOps or whatever, you are only looking at part of it. Even if you follow these procedures to the letter, you are still only looking at part of it.

One of the other parts that gets missed, but is implied in these new ways of working is the psychology. It is the human factor. It is looking at what motivates us to work. What makes us want to do our best, what gives us drive. Then there is the other side, what demotivates us. What makes us unhappy, in a state of despair. What makes us grumble about our work and how we can get away from that and get back to being happy.

I’m not talking about being happy little vegemites (here is the meaning, I’m also one of the few Aussies that doesn’t like Vegemite) mindlessly happily working like we have drunk the Kool Aid, although that is part of it. It is also not working hard because of a strong work ethic, although that is part of it too. A person with a strong work ethic will keep working even if they are not happy with the work. No, this is something that transcends that. It is working for a purpose.

Purpose and Control

For those Gamers out there, you know the situation. You are playing a game, you spend the whole day (or night) playing. Totally consumed, totally unaware of the time. You look up, its day, you look up again it’s night, you look up again and its day again – where did the time go? You are playing with purpose. You want to master the game. If you didn’t want to master the game and the only purpose was to complete it, set the game to “Easy”. You can complete it in no time. Also, you control when, how and what you do in the game – you are constrained by the rules of the game. But you are still in control.

Yes, it’s only a game, but imagine that drive, that motivation being redirected to work. Not through manipulation, but through a shared goal, vision or belief in what you are doing. This is why in the Scrum Guide there is talk about the Sprint Goal, the Product Vision. In Scrum, it is the Product Owner’s job to firstly have that vision and then inspire the development team to have that shared vision. That same goal, the want to be part of something that will make a difference. When a person has an understanding of the overall goal, and where they fit in the goal, how they can help bring about that goal, that change, that vision, then mountains can be moved.
There are many leaders in history that have been able to lead this way for both good, for example Martin Luther King, and Evil, Adolf Hitler to name but two prominent people.

Fight or Flight

The next human factor is one where we want to do better. It is much much easier to just keep things they way they are. Everything is predictable. The way you did something yesterday will be the same way you will do it today. It is generally how modern day management works. Keep things at steady state, limit the variation and all will go smoothly. There is some variation, you change things slightly if the new way is proven. If it sounds like a good idea, and feasible, but doesn’t really change things all that much. This method of working is fine. It gets things done, makes it predictable – generally. Evolution is slow, but still happens.
The problem is that there are some people out there, in the industry that you work in, that are trying to accelerate the work evolution. Not only that, they are doing the equivalent of gene splicing by constantly trying new ways of working. Experimenting constantly. Trying to determine what works, what doesn’t, what is better and then adopting those as their new steady state for the short time before it gets changed yet again. This is one of the ideas behind the “iteration”, but we are talking human factor here, not process or procedure. So how do you get that drive to constantly try new things, get better? One way is through crisis. One way to deal with a crisis is to accept things are going to happen and just live with it or run away. What will be will be. This is not the attitude we want. It is the equivalent of laying down to die.
The other way to get through a crisis is to fight it. Those that fight will try to find a way out of the crisis. When the odds are against them, these type of people try to find unconventional and innovative means to fight back.
In Scrum, this is the Scrum Masters role. To inspire the team to fight back constantly against an enemy that may be a competitor, another team or even themselves. The team must fight back using unconventional and innovative means to get the work done better and quicker. Never to be content with the current situation, or be taken over by the enemy.

Strength

The final human factor I wish to talk about is using people’s strengths. Too often people are brought in to fit roles. Most of the time, these same people can offer much more, just not in the role that they have been placed in. To make things worse, these people are overloaded with work. This invokes a situation that Liz Wiseman in her book Multipliers calls “Over Worked, yet Underutilized”.
This is very demoralizing for a person. I remember a story from 2 second lean, where Paul Akers talks about an engineer who gets an award for 30 years of service. (The details may be sketchy as its from memory). The Engineer sits down and cries. When asked why? He says, “They had the work of my hands for 30 years. They could have had the work of my mind for free”. People have ideas on how to make their work lives easier. Not all of them revolve around them shirking work.
I bought this book Strengths Finder 2.0 a while ago. It comes with a test you can do online. You answer a number of questions honestly otherwise it doesn’t work and you have wasted your money, and based on your responses, it works out what your top 5 strengths are.
Mine are to summarize...
Learner – I like to learn stuff.
Deliberative – I take care of making decisions.
Ideation – I am fascinated by and constantly have ideas
Connectedness – I can find the links between things.
Intellection – I am introspective and appreciate intellectual discussions.
These pretty much sum me up quite nicely. Freakily so.
Another type of test is the Briggs-Myers test. I personally haven’t done this one, but it gives similar responses.
Having team members do these types of tests can help identify their strengths and thus be able put them to use. Since you are utilizing the specific strength of a person, people feel better utilized.

Engagement

A significant number of people who work are not happy with their jobs. If you do a google search on “How many people are disengaged with their jobs” you start to see numbers around the 70% mark. This means you have 70% of your workforce not giving their all. This ultimately affects the bottom line. You can’t order these people to give their all, they need to give it willingly. You could try to compensate with the “Carrot and Stick” approach by giving bonuses, but this only works for a few and only short term. It also disengages people more if the bonus is removed. The only way to get full engagement is by creating an environment where people are inspired to give their all (while taking into account their circumstances such as family, work life balance etc – we are not slave drivers) can only help. Look at the open source community, Wikipedia, etc. people are so inspired that they work for free!
Ignoring the psychology of the people, means people are not as motivated to do their best. Some may have even worked in this situation so long that they may not even know what their best is. The problem arises that more resources will be required. This means more expenditure. It also means that those companies that do do take into account their people get the upper hand over you as they do more with the same amount of people. This. Hold mean that your company’s actual survival may be at stake, which is not good.

One of the many things that is common between Lean and Agile is that they make problems visible. Most of the time when we as humans see a problem, we look for the most obvious solution and implement that solution. Sometimes, especially with complex problems, the most obvious solution is not the best solution. Sometimes you have to dig deeper to get to the actual root cause.
There are a number of techniques to analyze problems and try to get more information or a better exploration of the issue. The most common is the 5 whys method where you ask “Why” 5 times. Another method which I would like to discuss is the Fishbone diagram, also known as the Cause and Effect diagram.

The fish-bone diagram is a graphical method to view possible causes of the problem. It does not help you solve the problem, only identify potential root causes. You can then experiment to determine the actual root cause and possible solutions.
The diagram gets its name from its shape. It, well, looks like the bones of a fish.
To draw the diagram is quite simple. At the head of the fish is the problem, also known as the undesirable effect. It is better if you phrase the problem as a question rather than a statement. “Why did <problem> happen?” rather than just “Problem”. Sometimes phrasing things as a question gets a better thought process than just a statement. Once you have the head, then you have the spine and from the spine, the ribs which represent the groups of causes. The causes then branch off the ribs.

As you can see, the diagram is quite simple and quickly shows how potential causes relate to one another.

There are two popular brainstorming methods to getting the fishbone diagram.
The first is to brainstorm possible causes and write them down on “Post-It” notes on a wall. Group the post-its together by relationship to one another. Those relationships become the ribs of the diagram.
The second method is to pre label the ribs. An example may be to use “People”, “Process” and “Technology” (You don’t have to have an even number of ribs). This method helps focus on possible causes, but can limit thinking to only within these groups.

Below is a completely fabricated example where the problem/undesirable effect was that a calculation of 2 numbers led to the wrong value.

As you can see, there is no “solution” to the issue. We are just looking at possible reasons as to why the defect occurred.
The next step in the process is to discuss, and analyze the possible causes and then find ways to mitigate them from happening.

The Fish-Bone diagram is a simple but effective method to help view problems in a new light. This can lead to better root cause analysis and innovative solutions.

I got to thinking, how do you know when you are agile?  The following is a list I came up with in a brainstorm.

Optimizing the work

This is about getting the most out of the work that is being done. Most of these are covered by Scrum and Kanban frameworks. I consider this to be the start of being Agile, but not the end game.

• Backlog is in priority order
• Backlog is groomed regularly so that items can be worked on straight away
  • Items are of a reasonable size
  • Details added, but not details on how to accomplish the task, but the outcome desired
  • Acceptance criteria
  • Discussed with Team
• Team picks items off backlog/Sprint backlog (self organizes)
  • Items are Not assigned
  • Not grouped by project
  • Everyone works on everything
  • No handovers as not required
• There is a greater goal to work towards for the Sprint
  • Not just work to get things done, a real goal
• Ability to change with little to no disruption to flow, although productivity may suffer
  • Eg loss of a team member to a project.
  • On leave
• Definition of done exists and is adhered to
  • Determined by whole team
• Team has principles to guide work along with goal
• Standards change frequently as they improve
  • Standards are not fixed but reviewed and questioned regularly
• No silos/roles (cross functional)

Improvement and growth

The second important thing that I think when you become Agile is that you take care of your team’s and the members of the team’s ability to grow. You no longer just do the work. You are trying to find ways to increase the skill set of your team. The team itself becomes a learning team. Mistakes are seen as opportunities to see gaps in knowledge and teach.

The team itself becomes a learning team.

• The Team measures in such a way it can determine if there is improvement
• Everyone continuously looks are doing things better (continuous improvement as often as possible – daily)
  • Small (save 2 seconds) to large improvement
  • Improving quality
  • Reducing waste including processes.
  • Learn to see/Open mind
  • Optimizing flow
    • Work is done by single piece flow.
    • Improve cycle time
    • Limiting work in progress
      • Getting things done before moving onto the next thing. Ie no multitasking.
        • For this to work, task sizing must be optimal
• Experimentation encouraged with measurable results
• Self learning is encouraged
• Team reflects on the work done regularly
• Information is shared openly.
  • Team teaches/trains each other
  • Skills and techniques are shared
  • Information is shared
  • Lack of knowledge is seen as an opportunity to teach, not berate
  • If someone doesn’t “get it” change teaching technique. Everyone learns differently
• I intend… very well. Members do not have to ask permission to do something. They just need to state what they are doing and be trusted to do it. See “Turn the ship around“
• Problems are seen as challenges, not issues
• Autonomy, mastery and purpose fulfilled

Teamwork and Emotional Stability

The final section is where the Team and its members feel safe to express their differences and those differences are explored rather than suppressed.

• Team is happy.
• No blame
• No fear of failure – fails frequently (means we are pushing the limits, and learns from the failure)
• Trust within Team
  • Can openly discuss without being shot down
  • No idea killers. Ideas are explored – even the crazy ones
    • Experiment to rule in or out on merit, rather than rash judgements

This is my list of what I think being Agile is. Doing Scrum or Kanban or SAFe or any other framework alone does not make you Agile in my opinion. Learning and having an environment where you can explore, try, fail and discuss is also just as, if not more important. Myself, I am not there yet, but I am trying. It is also possible that this is an impossible goal. That may be so for some organisations, but my thinking is that you need to keep trying. It is the trying that is important, not the achieving.

It is most likely possible that when all the above is achieved, there will be more criteria. This is not suppose to be a list that must be adhered to to say that you are Agile, but a guide to help you get there.

At least in my opinion.

Let me know what you think in the comments.

No post this week as I have written an article that has taken all my time for the Scrum Alliance.

Please keep a look out in a few weeks time for an article on Work Groups and Teams on https://www.scrumalliance.org/community/articles