Scrum | Detecting waste

Waste elimination is key to Lean. Nevertheless is the approach to detecting it completely different from traditional cost cutting techniques. The latter one detects waste by appointing certain persons or committees, who's job it is - yes you guessed it right - to detect waste.

An approach which will not uncover the true problems of an organization...

Lean is all about creating an environment that makes it easy to notice problems. If people are on the alert to detect problems, and the environment is created that makes it easy to notice problems, the supply of creative idea "seeds" will not run out.

Our job as Scrum Master or Lean Leaders is to help create that environment and inspire everyone to act, to take action, to make improvements.

Scrum already provides one key ingredient to continuous improvement by stating that at the end of every Sprint a retrospective should occur. Two things are important in the previous sentence. The first one is that there is a meeting, an environment, created where all team members can look back at what happened, what went well or would could have went better and last but not least that the intention of the meeting is to create action points to improve upon all things that could have went better, dividing them between things that can be solved by the team and those that fall under the jurisdiction of the company. Secondly you should notice that it clearly states that the meeting should be held after each Sprint, the fact that this is a rule, a standard will help in the process of detecting problems. The team will exactly know when to address their issues. Short iterations will only help in quickly exposing impediments.

One of the Lean principles I try to apply on projects is Kanban, the art of visualizing everything that is going one. A Scrum implementation of this is the Scrumboard and the burndown chart. But don't stop there:

• get that full project burndown also up there


• keep the result of each previous retrospective on the wall especially when it contains impediments that need to be solved by the team or organization


• Don't waste too much time on making detailed UML driven technical design, grab a big paper, make some design sketches and put them up there


• technical issues which don't belong on the product backlog can be kept as a separate Technical Backlog on the wall by adding each technical issue as a post-it on it


• your application consists of a web front end than take a print of the screens hang them visible for everyone so that they can be discussed at any time, also having them around will make you get used to the screens and will help in detecting inconsistencies or improvements

I can go on for a while but you kinda get the picture. Get it up there, visualize it, so that everyone can start talking about it...

Lean | Quote of the day

"If you see a snake, just kill it - don't appoint a committee on snakes."
-- Henry Ross Perot

Lean | Keeping idle workers busy at Toyota

Lean states that your management decisions should be based on a long term philosophy, even at the expense of short term financial goals.

But how does Toyota, mother of Lean principles, apply these rules in financial uncertain times? Times where car manufacturing is dropping all over the world and workers need to be laid off.

The Wall Street Journal wrote an article on how workers are kept at the plant, not send home or fired when there isn't any work for them for a while. The employees spend their days in training sessions designed to sharpen their job skills and find better ways to assemble vehicles.

Some article abstracts...

Toyota is using the down time to hone its workers??? quality-control and productivity skills. The company has pledged never to lay off any of its full-time employees, who are nonunion...

Jim Lentz, president of Toyota Motor Sales, the company???s U.S. sales unit, said the company believes keeping employees on the payroll and using the time to improve their capabilities is the best move in the long run. ???It would have been crazy for us to lose people for 90 days and [then] to rehire and retrain people and hope that we have a smooth ramp-up coming back in,??? Mr. Lentz said...

In Princeton, senior plant manager Norm Bafunno said he can already see the benefits of the training. Mr. Bafunno cites a Teflon ring designed by an assembly worker during the down time that helps prevent paint damage when employees install an electrical switch on the edge of a vehicle???s door...

Mr. Mason, a 40-year-old former firefighter, added: ???One of the major things that everyone is grateful for is that they thought enough of us to keep us here"...

Toyota continues to show intelligence, long term thinking and respect for people in their management decisions.

Lean | Quote of the day

"The most dangerous kind of waste is the waste we do not recognize."
-- Shigeo Shingo

Lean | Quote of the day

GO SLOW TO GO FAST

"Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly"
-- Toyota Production System

Scrum | Ban local optimization

Traffic jams, we all know them, we all hate them!
But perhaps there is an important lesson to be learned from them...

While I was sitting in my car, listening to the same old cd, not in the mood for an overdose morning-radio-happiness-whether-you-like-it-or-not, my mind started to drift of and before I knew it a couple of miles passed by without me even realizing it.

How did I get there?
When did I started to accelerate or brake?
Where did the people in front, next to or behind of me go?

I just got there, how I got there, or how others had got there is based upon individual driving decisions. The only rule we have is that at some point it is best to follow the herd. Each driver individually can decide when and how fast he moves from A to B, he does what he think is best, what he does, what he is allowed to do are local optimizations.

Trying to kill the time remaining in traffic I started thinking. Traffic jams are a strange phenomenon, they have been analyzed thoroughly but solving them seems to be tricky! Why is that, are traffic jams that unique from other optimization problems in different industries? Can a simple every day problem like traffic jams inspire us enough to think about related problems in our organizations? Perhaps...

To maximize throughput, all cars need to adhere to a speed limit, preferable the exact same speed. Car drivers are required to optimize only for themselves which causes the system to break down and everyone finds himself caught in a traffic jam.

This problem can be solved by synchronization of all participants. This means all cars need to have the exact same speed and its flow should never be interrupted (continuous flow). A separate acceleration / deacceleration zone allows cars to get up to the exact speed before entering the highway. At no point, not while getting on the highway nor during traffic individual drivers should be allowed to manually manipulate their speed. Comparable with an automated railway system.

Don't compare it with traditional train railway systems, they have even more bottlenecks than the highway system, up to you to detect them...



To conclude, a problem not to be solved overnight! Key to remember is that the root cause is allowing individual drivers to do local optimizations.

SkyTran is a futuristic example of such a fully optimized system.

So we learned that local optimizations are bad. Not really an innovative idea because it has been around for ages in manufacturing methodologies like Lean. Lean has taught us that optimization should take place at the project level, not at the level of the individual people or processes. Local optimization weakens the overall process.

So what about local optimization within an organization?
What about implementing Scrum on a single team within a traditional organization? Aren't those local optimizations?

Many of you who have been using Scrum have probably asked yourselves: 'How does Agile / Scrum scale?'. Can it work even when it is not supported by the the enterprise (team level)? Is it sustainable within a traditional organization?

At least that's a questions that keeps popping up for me!

Scrum equals optimization, local optimization in most cases. The companies that have implemented Scrum or Agile project methodologies fully from top to bottom or a few. Organization adaption is a hot topic during Scrum Master trainings, do we need to do it top-down or bottom-up? My experience has taught me that most companies get familiar with Scrum bottom-up (thanks to all the smart developers) but it gets stuck somewhere in the middle or even at development team level ... equals local optimization. Better would be that the vision comes from above as we have learned from Lean (aka Philosophy level), a clear vision on company wide optimization! One goal envisioned from above!

If you are using Scrum in an otherwise traditional based organizations you'll probably spot some of the typical problems ...

• No support for a Product Owner
• Waiting for resources
• Conflicting resources
• Planning requirements
• Lots of noise
• Strange deadlines
• ...

Typical problems a Scrum team has to deal with because the rest of the organization is not aligned with the Scrum vision, the way of dealing with change. The same reason why if one person in the team does test driven development it will fail, this one person is doing local optimization which are not sustainable on the long term.

I love Scrum / Agile but they only tell you part of the story, it is too fully focused on single projects, it never explains the bigger picture, the real issue, how to optimize the organization. That's why I love Lean, Lean is the bigger picture where methodologies like Agile / Scrum fit in nicely. Lean will teach you about local optimization problems, about the higher organization cause, about Kaizen, about dealing with multiple projects.

Scrum does scale, but only if an organization is prepared to adhere fully to Lean methods!

Don't stop with Scrum, it is great, but don't stop there, learn Lean, because only then you'll see why Scrum can work on organization level. Learn how to create that sustainable organization wide vision, learn how to grow that vision...

Afterwards you'll never questions yourself again whether or not Scrum will work for 1 or 50 projects.

Optimize the organization, not the projects.

Scrum | Stop the blame

Today I want to talk about something that I find particularly common for teams that are adopting Scrum for the first time ... blame.

Let's start by defining blame:

"To blame is to hold another person or group responsible for perceived faults, whether these faults are real, imagined, or merely invented for pejorative purposes. Blame is an act of censure, reproach, and often outright condemnation. Blame is used to place responsibility and accountability for faults onto the blamed person or group."
-- Wikipedia

Key to the definition above is accountability something which you will also find in Scrum, but different. Accountability within Scrum means that not a person is responsible for failure but the team as a whole.

Like any team sport, you win or loose as team. Like they say there is no "I" in team. But reality teaches us that when we loose we feel the need to make someone accountable for the loss. Even worse, blame is basic to hominid behavior. Studies have showed that blame seems to be an essential part of human development. When language skills develop, one of the first practical things which can be done with them is to apply them to blaming others for one's own misdeeds, and getting them sanctioned, or punished, while one simply continues with more of the same.

So don't get all cracked up on the fact that your team start blaming during the daily stand-up or even worse during the retrospective after a 'failed' sprint. We can't help it, it is in our nature ... see, we can even blame the fact that we blame solely on being human :-D

So why is there no place for blame within Scrum? Actually for this we need to look beyond Scrum and look at its daddy called Lean. Key to Lean is waste elimination which is achieved by continuously trying to improve the process, also known as Kaizen.

Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work, and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

To be most effective kaizen must operate with three principles in place:

• consider the process and the results (not results-only) so that actions to achieve effects are surfaced


• systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view) in order to avoid creating problems elsewhere in the process


• and a learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent will allow the re-examination of the assumptions that resulted in the current process.

Blaming is wasteful, a simple truth but just because blaming is part of our nature so hard to achieve. So don't go expecting team members to stop blaming from day one but guide them into the magic world of getting things done like a team. Guide them towards spotting waste, guide them towards process optimalization and continuous improvement, help them to stop thinking about blame.

I make mistakes, I do things wrong, I don't know the answer to everything, but so don't you! That's life!

An example

During a retrospective a member of the team put up a post-it saying "Commitment?" and said "I think this needs no further explanation".

You kinda get the idea that such statements are not very constructive nor are they identifying waste = the real issue. So what should have happened and what was behind his frustration?

The frustration was actually caused by team members working on tasks in parallel, doing multiple stories at the same time. And by doing so they started blocking each others work, tasks depending on other tasks. And even worse the guy that had put up the "Commitment?" paper in the first place was working on multiple tasks in parallel, blocking a complete story and was not willing to give some of his tasks to someone else and by doing so unblocking the ongoing work.

Everyone in the team got frustrated because they could not proceed, and the one doing the multiple tasks was frustrated the most because he felt he was doing all the work. Causing him to sit behind his desk until late at night.

So during the retrospective he felt frustrated and blamed the team not being committed. Should he have kept quiet? Hard to say, yes and no. Because he was new to Scrum he could not really pinpoint what went wrong so yes I believe he was in his right to do so. But then it is up to the team members to react and explain what really had happened, not that he was blocking everything but that as a team they made bad some bad decisions upon dividing the workload on the task board.

During the daily, the moment everyone was grabbing the tasks he will be working on the team or at least the Scrum master should have reacted and warned about the fact that they were starting on multiple tasks in parallel ... so actually they failed as a team.

In the story above the person should have concluded that failure of the sprint was due to the fact of badly implementing Scrum, doing multiple stories / tasks in parallel and not the fact that there was no team commitment.

It isn't always easy to spot waste, nor process inconsistencies, nor is it to keep your emotions under control! A learning, non-judgmental, non-blaming environment in which we continuously try to improve ourselves isn't something we can achieve in one day, but by practicing Kaizen we take each day a little step towards this goal.