Blog Archives
Agile Retrospectives = Reflection
In an earlier post I mentioned the similarities in agile and lean from a problem solving perspective. Lean and agile are also the same when it comes to the learning cycle.
One of the principles of lean that I have learned is Create a Learning Organization through Learn-Apply-Reflect. This principle helps drive home the importance of reflection. Many people and organizations do a great job of learning something new and then trying to apply it. Where most people and organizations fail is forgetting to reflect. The reflection step is where all the learning and applying comes together to understand how what was learned can best be applied in the organization. What worked? What didn’t work? What should be kept? What should be changed?
A sign an organization is doing this well, is the reflection is planned and not a reaction because something went wrong. The reflection is part of the project plan and will is scheduled upfront with no agenda but to learn and improve.
Agile has a methodology and a term it uses for this reflection and learning. It is retrospectives.
Agile uses planned retrospectives, usually once a week, to take a time out and gather the team to understand what is working and they should continue doing. As well as what is not working and should be changed or thrown out. It takes a monumental act to cancel a retrospective. These retrospectives are ingrained in the methodology and help the agile teams continue to improve on their process and work.
This is a great of example of Lean-Apply-Reflect. The agile team takes the learnings from the week, apply them and then have a planned reflection time a week later. The agile methodology does a great job of fostering the principle of creating a learning organization.
Do you have any examples of planned reflection in your organization?
How Problem Solving and Agile Both Drill Issues Down
I have been learning about agile as of late. I know how agile has gotten its roots from lean thinking as it is applied to software development. It has been very interesting and fascinating to learn.
One common thread problem solving and agile have is making it important to break down the issue.
Good problem solving breaks down a large problem into smaller and very manageable problems to solve.
Agile does the same. It is important to break an epic story (or very large story) down into manageable stories that can be built and tested in 2-3 days.
Click to enlarge
This is just one similarity between lean and agile I saw as I was in my class. Seems simple but it really takes team to master to bet able to break stories and problems down to the appropriate sizes.
Root Cause and Guns
Normally, I don’t dive into the hot politically charged topic of the week, but the gun issue has really struck a cord with me. I don’t care which side of the issue a person falls on, right to own a gun or very strict laws almost preventing gun ownership. Everyone has a right to their own opinion.
The issue I have is with people, more accurately politicians, using tragedies to further their own agenda without understanding the true root cause.
Sandy Hook was an enormous tragedy. I went home that night and hugged my kids and didn’t let them go the entire weekend. What happened shook me at my core.
What has happened since then has been upsetting also. Laws are proposed and passed on gun control that do not address the root cause of why these type of mass shootings are happening. Guns are being obtained legally and with background checks. A lot of these people are not any system as having “issues” or being arrested or whatever the case may be, so they will pass a background check.
Stricter background checks can just cause people to get guns illegally. It is just like making alcohol illegal in the U.S. Prohibition in the 1920s didn’t stop alcohol from being made or consumed. It just made it illegal. People went into business with distilleries and crime went up because of it. Not just the making and consuming of alcohol but people robbed and killed over it to build empires because no one would call the cops if a criminal stole from a criminal.
If a person wants a gun bad enough, they will get it.
The question is, “What is causing people to want to do these acts?” How do we prevent people from wanting to do something like this? Do we need to work harder on stopping bullying? Do we need to help to make people better aware of how a stable family can help?
I don’t know what the answer is, but I do believe that what has been going on for years with just looking at controlling guns is not the answer. It hasn’t’ worked since the Columbine shootings and I don’t see it working moving forward.
What are your thoughts on helping to prevent the root cause of gun violence?
Understanding Single Piece Flow
One of the first concepts that pops up when learning about lean is single piece flow. This is a great concept and should be considered when it is appropriate. Cooking my french fries might not be the time to use single piece flow, but downloading songs may be.
My wife runs a small business of her own. She sells products online through her website and Etsy as well as events in our local area. Selling online and brick-n-mortar poses problems from time to time. One issue is wanting to provide a wide range of scents for customers, but not having large amounts of inventory on-hand because of the batch process of making the soaps in loaves.
After a year and a half, we think we find a solution to this issue. Most of her requests for custom scents come through her online sales. Typically, she has the fragrance available but can’t justify making 8 bars in a batch because the other 7 may sit for a year or longer. She has found a mold that works very well and is the size she needs that allows her to make one soap at a time. My wife can now fulfill the requests of her customers and offer more fragrances to her line in her online shop without the expense of carrying a year’s worth of finished product.
What about the live events to sell the inventory?
Good question. The events are always in the Sept – Dec time frame. So, if a customer orders a special scent in January, the rest of the finished goods would sit until September at the earliest. She could have used the raw materials for other products. The soaps that are high volume sellers and do well at the live events can be made in batches right before the event. Any finished product that is leftover after the event season can be sold online.
It is a good mix of using single piece flow and batch processing when it best fits the situation. It is about understanding your business needs and trying to meet those needs. Not forcing everything to one solution whether if fits or not.
What makes sense for your business?
Happy Thanksgiving!
Image courtesy of David Castillo Dominici / FreeDigitalPhotos.net
Today is Thanksgiving Day in the U.S. A day to stop and give thanks for things in life.
I would like to pause and thank Joe Wilson for joining Beyond Lean this year as an author. He has made great contributions. Here are just a few of my favorites:
I also want to thank all the readers. Without you, Beyond Lean wouldn’t be here. Thanks for taking time out of your day to read what we post here.
Have a Happy Thanksgiving!
Data Collection Thoughts
One thing that seems to come up a lot in terms of continuous improvement activities is the need for data. Sometimes there isn’t the right data, sometimes there isn’t enough context to the data, and sometimes there just isn’t any data recorded at all. I’ve written about data in terms of metrics and measurement systems before, but this time I’m more talking about getting your hands on information that becomes clues to solve your production mysteries. I don’t believe in substituting data for observation, just in using it narrow the observation lens.
So…what are some of my key thoughts for getting data to make sure you are working on the right stuff?
- First, make sure your data tool can tell you what you need to know. If it’s a log sheet of some sort, does it capture major sources of variation such as time, position, cycle, machine, tooling set, etc.? If it’s a measles chart (or concentration diagram or whatever name you may use), can you really tell the difference in defect locations on it?
- Next, be willing to sacrifice some clarity in some areas to get an overall picture of the process. I like to start by targeting about 75% of the data that I’d like to have and adjust it from there if need be. Most of the time I find that the extra detail I thought I needed wasn’t really necessary at this stage. I can always build additional data collection if I can’t get what I want from the reduced set.
- Also, try to make it as easy as possible. If you can extract what you are looking for from existing shift logs or quality checks or some sort of automated means, go for it. Adding a layer of work can sometimes lead to reduced data quality for everybody!
- To go along with the previous item, remember data isn’t usually free. If you don’t need the data collected indefinitely in the future, set an expiration date on the activity and free up the resources.
- Lastly, to paraphrase myself, data isn’t a substitute for going to the gemba and seeing the problem for yourself. Double check the data against what you are seeing with your own eyes to make sure that it can really help you. This data won’t solve problems for you, but it can help you know which ones are the biggest.
I’m sure there are some other key points that I’ve left out, but there are a few for starters.
Now, I’m sure some of you are asking, “Why waste time on this and why not just go observe the process at the start?” Good question. I think this is more of a helping hand to make the best use of time for some operations. If there are limited resources (and who doesn’t have limited resources?), deploying this in advance of a deep dive can help speed up the search for solutions. If a process has a long cycle time or unusual frequency, something like this could help identify repeat issues vs one-offs. I am always looking for the best way to use what I have at my disposal and sometimes it doesn’t fit the textbook methodology.
Failing a Test Can Be a Good Thing
Too often we look at failing a test as a negative thing. The word fail has such a negative connotation, but it doesn’t have to be negative. Fail can tell us what something isn’t or where we need to improve.
Failing part of a knowledge test can tell a person where their knowledge gaps are. Knowing the gaps is the first step in gaining more knowledge. Filling the gaps leads to better output.
Another way fail is look upon negatively is when testing a condition. When trying to determine the point of failure or the root cause of something tests are run to verify the hypothesis.
Typically, when a test fails people are disappointed and can even get frustrated. The assumption people make is they should know everything in their world. Be the expert. Being the expert means knowing where the point of failure or root cause is right away. That can’t always be the case. If it was, then a lot of the problems would be taken care right away or wouldn’t exist.
Taking the perspective of learning, failing the test and not confirming the hypothesis means you have a better understanding of what it is not. That is valuable information to know. Knowing what it is not helps to narrow the search. Getting you closer to the answer. Ruling things out is the next best thing to finding the point of cause or the root cause.
Like a doctor. You go in sick so they test for the flu. It comes back negative. You are still sick but at least you know it isn’t the flu.
Concentrate on learning from all tests and failing won’t be such a bad thing.
Asking Why 2 Times
A couple days ago I was reminded of a problem solving aspect I hadn’t personally dealt with in a while. I guess being engaged in other things, I kind of forget one of the fundamental questions in problem solving.
By now there probably aren’t a lot of people unaware of 5-Whys. But, what about the 2 Whys? No this isn’t an attempt to be clever by turning 5-S into 8-S or “8 Minute Abs” in to “7 Minute Abs”. It comes down to addressing the two fundamental paths of how defectives get to the customer. “Why Make?” and “Why Ship?”. In simple terms, “Why Make” is pretty self explanatory in terms of understanding why the defect was produced in the first place. “Why Ship?” becomes a much more nuanced question about why defects were allowed to be passed along to the customer (internal or external). It brings along questions about how you build quality at the source or at the least how you detect it and prevent it from being shipped.
I used to get these questions asked all the time by a friend who worked in Quality at Toyota. I guess back then, much like now, I spent much more time on the “Why Make?” question than on the “Why Ship?” one. Part of that is that I work in a different industry where product is less likely to be shipped anyway. The other big part of it is that I just find it much more interesting to chase the kind of problems that follow “Why Make?” questions. That is kind of unfortunate because looking in to why your systems didn’t prevent, detect, or reject bad stuff sometimes offers some holistic views of the operation that you may not always see. It was kind of fun to have the reminder to ask “Why Ship?” more often.
Hopefully this can be a little kickstart for those who hadn’t heard that or a reminder for those of you who may have put that on the back burner.
Chicken and Eggs
This doesn’t have anything to do with poultry, but more with the age old question of which comes first. (Although, if you’d like to talk about actual chickens, let me know.) When pushing forward a continuous improvement mindset, one of the first obstacles is in understanding where your biggest problems are. This is often an issue because the structure doesn’t exist to gather, compile, and filter data from the operation. Using an A3 format as an example, it becomes very difficult to get past the first step if you can’t quantify where you are in relation to your ideal state. Or, if you can’t quantify the relative impact of potential causes on the outcome you are measuring.
In general, this leaves you with a couple of choices. Choice A is to go forward with what you have and make changes based on what information you have available. Choice B is to put the brakes on for a while and focus your improvement efforts on improving the measurement and reporting systems. Both of these options have upside and downside.
If you follow the path of Choice A, you can start down the path of training people in the methodology and mindset of Lean problem solving. Those are good things, plus you get the visibility of “implementing Lean”. The downside of this path is that you really don’t have a good idea of the relative scope of issues and you risk working on something that isn’t that impactful or has to be undone when seen in better context.
Following Choice B, you will most likely end up with a more whole understanding of what you should be working on and why. However, you run the risk of losing support as others don’t see anything happening and people start to question when the “real work” will start.
So…which comes first…the problem solving or the measurement system? The short answer that I have come across is this: It depends. In theory, an effective measurement system highlights the problems that need to be addressed and is a must to have in place. In practice, not all organizations are patient enough to build the core of the metrics system without pushing the ‘execution’ phase along quickly. One of the skills involved in leading Lean (or, really, leading anything), is the understanding of where you may or may not have cultural (or individual) support to be patient or you need to “just do it”, building context of the picture on the fly. As uncomfortable as it may be, your people, your culture, and your environment trump the textbook roadmap almost every time.
Bruce Lee and the Ideal State
Today, I have the pleasure of being a guest blogger over on the Lean Leadership blog by Christian Paulsen while he is away on vacation.
Christian always has good quotes from historical people that seem to relate to lean. I thought it would be fitting then to center this post on a quote.
“A goal is not always meant to be reached. It often serves simply as something to aim at.”
—Bruce Lee
When solving a problem, whether it is designing a new process, eliminating defects or developing a strategy, it is necessary to have the ideal state in mind.
You can read the rest of the post by clicking on this link.
