Stop Starting, Start Finishing

The phrase in the title is a well-known agile phrase, but perhaps not well-enough known.

In one way, it is saying: minimize WIP.  Work-in-process or work-in-progress.

In another way, it is saying what my friend Mike Vizdos says: Focus. #Deliver.

***

But let me tell a story that gives a different meaning.

A few months ago, I was giving a class in Toronto, in the usual hotel I use there.  There were 3 of us talking after the class. One of us (an attendee) was a smart woman from a fairly well-known company.

I forget exactly what we had been talking about, but in a kind of segue, she said: "You know, two nights ago, I got home and put my stuff down and started to think about whether I had gotten anything accomplished that day.  I mean, I had worked hard that day.  Many meetings. Many emails.  Phones calls. I had been very, very, busy all day.  But: had I accomplished anything?  And I was sad, because my feeling was that I had not.  And in fact, I often have that feeling."

***

In my view, this is a terrible way to live. Well, terrible is maybe over-blown since people can and do live in much much worse ways.  But it is not good.  At all.  Especially since we know ways to live much better.  She could be living a better way now, I think.

One idea is: Stop starting, and start finishing.

A way to apply this is: Decide in your 'large' department (of 30 to 300 people) to prioritize the major sets of work.  Dedicate people to one team. (That means 100%.) And have each team work on one and only 1 set of work until it is 'complete.'  Meaning: everything useful is delivered to the customers.  (Useful means probably only the top 20% of the work, if you ask Pareto.)  Then, once they have delivered it,  give that team the next most important set of work.

People have satisfying lives when they see customers get the product and enjoy it.  And they see that frequently.

 

 

Balancing the work in the Sprint (coding vs testing)

Dean asks:

Greetings Joe,

 

Your Lean Agile Training website content has provided some great insight in helping me improve my agile principles and practices.  There is one thing I haven’t been able to clear out of my mind.  Perhaps there is a principle I’m not applying or a lightbulb that hasn’t come on.  Maybe I haven’t come across the right advice in a book or blog.  My conflict is keeping my full team ‘busy’ through out a sprint.  We typically apply a 3 week iteration and there seems to be a pendulum from coding to testing.  Those strong on testing don’t have full capacity during coding and coders aren’t at full capacity during testing.  Coders doing work at the end of the sprint won’t have their code tested and therefore don’t meet the DOD.

 

Is this a common mistake or have I missed the boat on something?

 

Joe replies:

 

This is a common concern.

 

Let me assume that you are the ScrumMaster.

First, it should not be your concern particularly that the Team is occupied all Sprint.  The Team should care about that.  Because the Team should have a mission that they feel they must accomplish promptly.  Or they are not really a real Team.  They are a Team INO (in name only).

Next: We do not want to think of the Sprint as being in two parts: (1) coding and (2) testing.  Rather, for a 3 week sprint (I prefer 2 week sprints) with a Team of 7 people, we have at least 13 stories.  And we think of each story in 2 parts (coding and testing, in very simplistic terms).

For each story, the coding and the testing work can begin at the same time.  First, decide how much info will be know beforehand (Ready Ready Criteria).  Then the coder starts to figure out the code (he thinks) while the tester figures out the tests (he thinks).    They work in parallel.  The tester should be building automated tests (of course….won’t explain why here).

The key concept from Lean is ‘single piece continuous flow’.

Then, when the code is ready, the tester tests it (automatically mostly), and of course there will often be bugs.  And then those are resolved quickly.

The simple rule that Jeff Sutherland uses is “No code can be written in the sprint that will not be tested in the spring.”  Among other things, this means that if the testers get behind, the coders must help them (if only by fetching the iced tea).  And vice versa.

Again, they win as a Team and they fail as a Team.  This is a key idea that they really must believe if they will do Scrum professionally.  (It is a sport for real Teams.)

Now, if they will help each other, they may have to learn new things to be able to help each other effectively.  This is a good thing.  And what knowledge workers naturally want to do.

Talk through these ideas with the Team.  They will help figure out the details, such as exactly how to help each other, what to learn, etc, etc.

One push back:  Well, actually some ‘teams’ have many push-backs. First is often some variation on ‘we don’t want to work as a team’.  Understandable in the sense that they have not ever been asked (for 5-10 years) to really work as a Team.  And some (few) people do not (ever!?!) want to work in a Team.

But a key push-back is: This seems like a lot of extra work for us. It would be more efficient if we did the work in big batches (usually, as they are doing today).

The penny game is one big way to convince them about this.  (I have written about this on the blog.)  In a certain sense, what they feel is somewhat correct.  What they are not seeing is all the savings that accrue when doing the work this way.  Mainly since the ‘bad news is not getting worse with age’.

Enough for today?  Comments? Questions?

Kanban: Taiichi Ohno quote

As David Anderson notes in his book, one of the best things about Kanban is improvements, continuously getting better.

Taiichi Ohno invented the Kanban idea in the 1950's when he visited Piggly-Wiggly, an American supermarket.  He explains most of this in his book, Toyota Production System.

The book has one short section titled: Kanban Accelerates Improvements.  In that section one reads this wonderful quote:

It is said that improvement is eternal and infinite. It should be the duty of those working with kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage.

Earlier in the book, he mentions many comparisons between sports and business. He mentions baton passing and rowing, two of his favorite metaphors.  Then he says:

I feel the most important point in common between sports and work is the continuing need for practice and training.  It is easy to understand a theory with the mind; the problem is to remember it with the body. The goal is to know and do instinctively. Having the spirit to endure the training is the first step on the road to winning.

Wonderfully insightful words.  As are many many more comments he makes in this brilliant work.

Courses Coming Up

We have several courses coming up.Certified ScrumMaster (CSM) course – This is the basic course, which we recommend for everyone and for teams. We are now almost always including a 1-Day workshop (on Agile Release Planning). Strongly recommended. And, occasionally, a 2-Day workshop.Places: New York, Toronto, Nashville, Montreal, Charlotte, Durham, Charleston, etc.
Intermediate Certified Scrum Product Owner (CSPO) course – In this course we want people who are experienced with Scrum — either notable experience or a CSM plus some experience. And it deals with more advanced topics. And we also include a workshop (on Agile Release Planning).

Places: Charlotte, etc.

Scrum 201 – This is an intermediate course for any team member or manager. We must have a CSM and some good experience with Scrum. With a workshop.  (With the workshop, it gives you 22 SEUs toward the CSP certification.)  The purpose is to help you move to the next level. And to try to answer (or help you answer) all the detailed questions that come up when you implement Scrum.

Places: Atlanta.

For more details (dates, etc.) see: LeanAgileTraining.com

We like to do in-house courses, and we could do any of these courses at your firm.
And we have other courses in the works.

Some of these courses are co-taught with my colleague, David Muldoon. He brings a different viewpoint and a wealth of experience leading an agile transition at a large corporation.

And don’t be shy about asking me or Cassandra Wagner (cassandra.wagner@leanagiletraining.com) questions.

Lean-Agile Resources

We have put together some Lean-Agile Resources on this page. Please give us your feedback and suggestions.

High Interrupt Work in Scrum

Imagine that you have a lot of new work, high priority new work, that gets identified every sprint.  During the sprint. 

In other words, you don’t even know about many of the stories or issues or tickets until after the Sprint Planning Meeting.  A support team is a classic example of this.

How do you organize things in Scrum to handle this?

First, question whether all the so-called high priority work is really high priority. It often is not.

Second, go to the root causes of why the high priority work is being identified so late. Example: If the quality is low when we release to production, let’s fix the quality issues (maybe caused by lots of interrupts to the Team).

Third, shorten your sprint length.  Maybe from 4 weeks to 2 weeks. Or from 2 weeks to 1 week.  Note that the so-called Scrum overhead of the meetings adjusts proportionally to the sprint length.  So, it’s a 4 hour (max) Sprint Planning Meeting (SPM) for a 2 week sprint, and a 2 hour SPM for a 1 week sprint.

Fourth, in the SPM set up a box of velocity, say 5 story points out of your total velocity of 20, for ‘to be discovered’ work.  The PO has to manage the usage of the box against ‘tickets’ as they arrive.

Fifth, as an alternative, substitute items. Example: Plan for the full 20 SP, but if a high priority ticket comes in, substitute that 2 SP ticket for the 2 SP story at the bottom of the Sprint Backlog.

That means: We have the Sprint Backlog items in priority order.  We complete them in priority order.  And we story point each new ticket. Just as we have story pointed each user story we took into the sprint backlog.

Principles

What are the key ideas behind all this?

Minimize disruptions. It is demoralizing and wasteful for the Team to be disrupted. It may still happen, it is part of life, but the Team and the firm should try hard to minimize disruptions.  And explain any disruptions that remain. Making the Team ‘happy’ is not the sole and only value in life, but it is important.

Mura.  A lean principle (Japanese).  Mura is the negative, the lack of an evenness of flow.  So, we want an even flow through the system. This is reflected, in part, by having all the Product Backlog Items in a Sprint Backlog have about the same size.

Muri.  Another lean principle (Japanese), in the negative. Over-stressing the system. And this never helps. (It does help to challenge the Team. Idea to discuss in another post.) Never ask them to do more than they can in a Sprint. It only reduces their capability. But, after they have completed everything they ‘committed to’, then they can start another story at the end of the sprint.

Do the most important thing first. (Enough said.)

Understanding business value is difficult. So, in this case, just because someone says this new ticket is very very important, we do not have to believe that person. The Team should judge for itself, based on benefit/cost ratio and other factors, whether that items deserves to ‘interrupt’ the sprint backlog.  Many contribute, and if the decision is not obvious, the PO makes the final decision. Note: The main thing the PO is trying to do is maximize the business value out of the Team.

Scrum and Kanban

Some people have recommended that you use Kanban for high interrupt work.

I do recommend Scrumban.  Where Scrum and Kanban are combined. Much as Toyota uses Kanban within the broader context of all the Lean ideas and tools.

I recommend converting the basic Scrum board (which already includes Kanban board ideas) into a fuller Kanban board. Once you have some good experience with Scrum. A good Kanban board executed well by a strong Team: that’s a wonderful thing.

Now, setting up a truly good Kanban board is hard. The best Kanban boards have high requirements, and are not suitable for many situations. A beginning Team or a difficult situation may well be better served by the basic Kanban board in the normal Scrum board.

And, especially in this case, with lots of high-interrupt work, you should want to convert the Scrum Board into more of an advanced Kanban board sooner.

I do not recommend ‘Kanban’ as I often see it played ‘out there’. Where we have groups of people, not Teams. Where there is no time box (no sprint). Where there is no Sprint Planning Meeting, no Sprint Review, no Retrospective, no Daily Scrum.  No roles, no artifacts. (Or, if they have a few of these, they are much too weak.)

***

Do these comments help? Your comments please.

Kanban ideas

We have been talking about Kanban a bit lately in other venues.

Let's talk about some key Kanban ideas in Scrum. Here.

1. Do the most important thing first.

In Scrum, we want the Product Owner to order the work (the PBIs or User Stories) mainly by Business Value.  (Yes, we talk about 'ordered' now, but this is mainly Business Value, looked at from the 'right' time dimension, not 'let's do the low BV things first.')

2. Pull

In Scrum, we only work on things that the PO has 'pulled.'  We don't do what we want, and hope it will sell.  We don't create 'excess' inventory.

Is this perfect?  Well, no. The ideal is that the PO has received an order from 'the customer.'  But this varies by business and by product.

But at least the PO, on behalf of the customer, says he wants it. Now.

3. Flow

Scrum has flow for each story. Anytime flow is stopped, as shown by the Scrum Board, then that impediment should be fixed.

It is true that flow stops for the 15 minute stand-up each day.  This is not really a problem.

How does Toyota do it?  Toyota (Taiichi Ohno) says that the Team must be in sync. As in crew, they must row in sync. That's his metaphor.  Scrum has the same concept, in part as shown in the Daily Scrum.  Toyota does not have 'every single minute' flow. In fact, Toyota is very famous for 'stop the line', where flow is purposefully stopped in a major way. To fix a defect.

So, Toyota and Lean are very mindful about when to have flow, and when to sacrifice flow for other values.

Using a Team that is in sync also enables greater flow. Example: If one person is stuck in any way, the other teammates are there for immediate help. And have every incentive to help, since they want the team to 'win' or be successful.  So, the team concept increases the flow.  Yes, there is a small 'price' perhaps in the Daily Scrum, but it is small compared to the benefit.

4. Minimize WIP

It is good for everything and everyone to minimize Work In Process (WIP). I won't try to explain here why that is so.

Scrum does this first by saying, one product backlog to one Team. And an ordered Product Backlog. And then, that the Team should choose for the Sprint the top items from the Product Backlog, but only so many as it can confidently do in a Sprint (whatever the Sprint length might be).

Some of the reasons for using a Sprint Planning Meeting for this are...
(a) to minimize disruptions during the Sprint,
(b) the inter-connectedness of pieces of work, so that the Team can choose stuff that is reasonably inter-connected, in such a way as to maximize the feedback at the end of the Sprint in the Sprint Review (demo) (we always get feedback...many reasons), and
(c) to allow 'chaos' in at the end of the Sprint. And a possible significant change of direction.

This last one also allows and encourages a serious re-think about the whole direction of the product. We _want_ significant mid-course corrections.  In part, based upon the feedback at the Sprint Review.

In addition, Scrum uses the Scrum Board to minimize WIP. Only the top story (PBI) or two should be in progress at any one time. If a story gets stuck, we can put it down, and pick up the next most valuable story.  But in any case, we minimize WIP.

***
I am quite impressed, as I think about it now, with all these Kanban ideas already in Scrum.  I will try to explain them more later.

And also explain how we might change the Scrum Board to be a slightly different Kanban board.

Scrum & Kanban

Jim Coplein today posted a very interesting post on Jeff Sutherland's Scrum Log.  It's title is:  An Alternative to Kanban: One-Piece Continuous Flow.

In the piece Jim discusses the definitions and merits of Scrum and Kanban.

This is a subject about which I too have some feelings.  Not feeling as talkative as Jim, I will summarize them.  This will allow greater room for mis-interpretation, and therefore for greater learning. (smile)  


1. Let's get more results. I am getting to the point where I don't care if we use Scrum, XP, Kanban, scotch tape, or Granma Berthe's Bible. What we use or what we call it means less and less to me.  


Show me the smiling faces. Show me how it helped you or your team or your customers.  In real life. The results are what matter.  The gods who spoke to Jeff and Ken and the scrum community knew this well. 

I better add: I still think Scrum is the place to start, and I don't believe in Scrum-But. But this subject is another 10 blog posts.


2. Lean bias.  I look at Scrum and Kanban as parts of Lean.  And I like them all.


3. Scrum. I think it is an excellent start. About as much as one team can change in a short period of time. And, yes, while it is simple, it takes years to become a master.  


But Scrum is only a framework, and while the team should not subtract from Scrum, stuff must be added to Scrum.  Actually quite a lot of stuff, in my opinion.


Scrum's 'incompleteness' is not a defect but a virtue.


4. Kanban.  The cards in Lean were stolen from Piggly Wiggly (the grocery store).  Which pleases me, since I have been to some of their stores, I like them, and my kids have "I'm Big on the Pig" t-shirts from Piggly Wiggley.


Kanban is one of several tools in Lean.  Kanban may be classed with several Lean practices or tools under a group called "Visual Management." 


Kanban in Lean first refers to the sign-cards stolen from Piggly Wiggly.  And of course to all the 'usage' around that.  Kanban has many purposes in Lean manufacturing. Reduce and manage inventory. Set up a pull system. Enable flow. Enable single-piece flow.  Provide some indicator of stoppages in flow.


It is important to note that Lean uses many other things in addition to the Kanban cards to attain all the goals mentioned above.


5. "Kanban". This is becoming an alternative software development 'framework'. 


It has various definitions.  And there are of course now many implementations. Many of which would no doubt be called "Kanban-but..." by some of the "Kanban" people.


Many good and smart people like the idea, and so no doubt it does some good. 


In Lean manufacturing, the Kanban cards represent things of the same 'size'.  In "Kanban", the cards represent User Stories, but so far as I can tell, there is not a strong discipline yet to keep the User Stories of the same size.  To me, this is a meaningful problem. (Long discussion as to why.)


Related to the size problem, "Kanban" has no metrics.  Thus, it is hard to demonstrate this way that it is successful.  (Yes, it is true that measuring success is difficult in almost every case.)


So, how much benefit "Kanban" provides compared to and separate from Scrum is hard to say. Objectively.


5. Engagement with Business/Management.  It seems pretty clear to me that Kanban tends to be used when engagement with the business side and/or management is not wanted or not possible.


Clearly, to me at least, this lack of engagement is not a good thing.  However, if it is not possible (for now), then perhaps it....is not possible for now.


Still, we tend to believe that Scrum, with for example the Sprint Planning Meeting and the Sprint Review (demo), and with Release Planning and Release Plan Refactoring (technically not a part of the core of Scrum)...Scrum with these things tends to build trust between the Business side and the Technology side.  Admittedly, often they start in a state of mutual distrust. Sometimes severe.  But these practices, if done well, smooth out the distrust and build trust.


6. Our recommendation: Scrum first, then add Kanban.


Some will note that this is similar to ScrumBan.  

We think that Scrum is plenty to implement on Day 1. And the Scrum Board, which comes 'out of the box' with Scrum, is already a very basic Kanban board.


We recommend that later, after the have Scrum working decently, the team use the ideas from "Kanban" and Lean to modify the Scrum Board into a specific Kanban board that reflects their work.  To us, the focus should include:

• Minimize WIP (work in process)
• Do not over-stress the system (a basic principle that deserves 15 blog posts)
• Single-piece flow
• Aggressively identify and remove impediments (eg, stoppages in flow)

Kanban or "Kanban" should not be used to reduce contact with the Business or Management or the Customers.  Rather the opposite.

Kanban and flow should not become a fetish.  (Nor should Scrum purity be a fetish, for that matter.)  There are good reasons to "stop" and do a Sprint Planning Meeting and a Sprint Review (demo), for example.  And to do a Daily Scrum.


If developers (coders and testers) still evince a preference for "Kanban" after these issues are discussed and explained, management needs to consider carefully the root causes. Humans (developers and managers) are of course complex, and many things could be at play.  But our first guess is that management is not aware enough how important it is for the team to have more fun when playing Scrum.


Fun is actually quite key to more creativity.  Which, in our kind of work, is key to higher productivity.

JIT Knowledge Creation

This is our business. Just-in-time knowledge creation. (It is not just-in-time knowledge management.)

Why? And why is it so important?

Well, ultimately the answer is because people are important. Or maybe it is better to say we respect the customer. And the firm's shareholders.

What do I mean, you say?

Let's start from the beginning. A long time ago the Lean people discovered that any Work-In-Process waste (WIP) or inventory, is muda. No, they weren't being silly. All Lean firms still have some WIP and inventory, but they have been relentlessly reducing the ratio of WIP and inventory to sales for 50 years now. And now it is a very small fraction of what it used to be. And they are still not satisfied. It must be reduced more.

And why did they do that? Well, in the auto industry they realized that an unsold car in inventory is trouble. It can only get worse, it cannot get better. The sun can spoil the paint job. Rain can cause rust. Hail can damage the exterior. Time can make it go out of the current model year. In other words, they noticed that the car can decay. (There are other reasons too.)

In software development, our business is knowledge. In the form of working code.

How fast can our knowledge decay compared to a car?

And here we mean not only the final knowledge (the working code), but also all the other tacit and explicit knowledge needed in the course of building the working product.

My opinion, and I usually demonstrate this easily in each Scrum class, is that our knowledge decays exponentially faster than a car. And a car's value will only go down a bit at a time. But our knowledge can lose its value as much as 100% in one day.

So, although no one told you, we in the software industry need to be relentlessly reducing our all our work-in-process and inventory. So, WIP is any work we have done that has not resulted in finished inventory. Finished inventory is fully finished software, that is all but deployed and in use by the 'customer'.

Now, we don't mean you should be foolish. For example, there is a minimum marketable feature set concept that does apply. Although we think that the size of the MMFS is much smaller than we almost always want to believe.

Again, a key goal of how we organize things should be to minimize WIP and inventory. And because there are many reasons for that, we can also organize things to minimize the negative impact of the WIP and inventory we 'must' have. (We will talk later about some of the other negative impacts of WIP and inventory.)

We must have a greater percentage reduction in WIP and inventory than the auto industry. We have lots of work to do to make that happen. Lots of impediments to remove. It was hard for the auto industry, and it will be hard for us. And now we have made the first step -- someone has told you that is absolutely key to your job.

Now, you know what your job really is. To know and not to do, is not to know.

BTW, Takeuchi and Nonaka have written many many pages about knowledge creation. They are the godfathers of Scrum. (A hint, for those who want a hint.)

An Intro to Business Value Engineering

On June 30th, while I was in Montreal giving a CSM Course, I also joined the Scrum User Group and gave a new, somewhat different, presentation on BV Engineering. They seemed to like it more, so maybe I am making the points in a somewhat more practical, concrete way.

Here is the link to the PDF: http://www.slideshare.net/jhlittle/intro-to-bv-engineering-montreal

Thinking for Yourself

Here is a good blog post about why thinking for yourself is important in Lean.

http://bit.ly/iH4tC

Poppendiecks: Designing a Lean Development Process

The Poppendiecks have a new advanced course (all welcome, but people already experienced in Lean-Agile will get more from it).

Designing a Lean Development Process.
Mnpls, June 9-10

Based on their new book (about to be released).
More info: See here.

Productivity Now

The economy is in a bit of a tailspin. Chairman Ben may have his way of helping us. But we can help ourselves. If you wait for the Wizards of Washington to help, you might wait for the wrong basketball team.

How do we get ourselves out of this jam?

We need a simple way of telling if we are productive, if the seemingly "brilliant" ideas are actually useful. And of telling whether this group of people or that or those is productive.

How? Measure productivity by team. The Team is the unit to be measured (not the individual, and not a larger group). There are many reasons to measure by team, but the main one is that only the Team can create enough useful knowledge to create (or produce) a (new) product. 7 people, plus or minus two.

Measure it in short iterations...a week, or two or a month at most.

And ask the Team to improve.

If the Team is not producing enough (say, compared to their cost), disband them and tell each person: "Go join or start another Team." If the same person is on two failing Teams, he probably needs to look elsewhere.

And all those other guys who aren't on the producing teams (or any team), why is it that we need them? What value do they add? (Yes, Virginia, they could join a team doing real work. Since they aren't used to it, we'll give them some time to remember how to do real work.)

So, some Teams can fail. But you will generally find that the Team gets creative and productive. They find something to sell that customers actually want. Even customers now.

To do this well, you have to measure productivity. I know there are lies, damn lies and statistics, but you need a little bit of something to make business decisions.

Translation: What I am recommending is Scrum for the whole business. I would recommend Scrum be in the context of Lean thinking about the whole business (although I did not explain that here at all in this post.)

Get on with it. We have a bunch of people to pull out of this economic cycle. Much as we enjoy Scrum, we didn't get into this just for ourselves.

Kaikaku or kaizen? (2)

I recently did a mail/internet survey, asking people what kinds of training they might be interested in. (If you would like to respond to this, please tell me.)

Someone responded, "how about adopting a continuous improvement approach?" Now, we don't know what the writer had exactly in mind (although maybe I will learn more). One assumes the writer meant something like: "continuous improvement is at least as valuable as more training." So let's play this out some.

In my view, training should be part of Kaikaku...which is a rapid, large, revolutionary change. In my view, there are times to make large changes. For example, when starting Agile. Or perhaps a new project. And there are also times to make small incremental improvements (kaizen or continuous improvement).

The preferred pattern is to have occasional large Kaikaku and many, frequent small Kaizen.

Now in general I am in favor with learning that is closely tied to, and proved by action. Which is to say. "The learner has not learned unless the actions become more effective."

So, training should be used to prepare for action right away.

But let's also talk about what action is. Not as simple as it might appear.

The hardest action is to change one's own mind. The next hardest is to change someone else's mind. (Proper action in the realm of the mind can lead to tangible improvements in satisfaction for real customers.)

Let's look at one example. One can imagine sending someone who is "resisting" agile to an agile course. The resulting action might be no more than a willing suspension of disbelief, so that the team can move forward without active resistance. So, while from a certain viewpoint nothing is accomplished, yet because the team can now be more functional, much has actually changed.

Kaikaku or kaizen?

As you know, kaizen means continuous improvement. Implying a bunch of small improvement over some period of time.

Small continuing improvements have many virtues to recommend them.

But what if we need a big change? What if we can make a big change? What if a big change is the only things makes sense? (eg, small changes in isolation won't show any improvement until bunch of other changes are also made.)

Then we have kaikaku. A rapid, large, revolutionary change (as distinguished from a set of small evolutionary changes...kaizen).

In Agile, one example is a 2-day Scrum course for the whole team, followed by immediately diving into doing Scrum.

Even kaikaku does not attempt to change everything at once. But it does make a group of changes "at one time" that together are major.

All the time, the Agile coach is asking..."is it time for kaizen, or time for another kaikaku?"

What is the scope of impediments?

Last night at Agile-Carolinas we had Israel Gat, VP of Distributed System Management at BMC Software. He spoke on "Leading the Disruption". He is giving this talk also in Austin, TX (and maybe elsewhere). If you get a chance, I urge you to go. Or just contact him.

After that meeting, I had several conversations. And then thought about them this morning. All that results in this post. Or at least, this question?

What is the scope that defines what might be an impediment?

By definition in Scrum, an impediment is anything that keeps the team from being more productivity. And I personally add that everything is imperfect, so by my definition everything is an impediment to some degree, and the trick is to identify the one or two biggest impediments today.

Scrum has also said that the scope is wide, including such diverse things as engineering practices and personal issues.

What I have not seen talked about much is the scope from an end-to-end Value Stream perspective. So, I would argue that anything that reduces the business value of what the Team produces (or the speed with which the value is realized) is an impediment.

So, as a simple case, imagine you have a Dev team in Charlotte and an "implementation" team in Chicago. (In this context, implementation means all those services around the software that make it actually useful in production.) The Dev team completes their work. The Implementation team is not ready (certainly not as ready as the runner to the right). So no business value can be realized.

I am suggesting this is an impediment. Perhaps the top one for that Dev team. And that Dev team (and their ScrumMaster) need to assure it is fixed (understanding that "a dead ScrumMaster is a useless ScrumMaster"). They probably can't fix it themselves, but they can make many efforts to get others to fix it. Perhaps they need to enlist a manager's help.

To me, this is similar to what Toyota found, ie, that to get the full benefits of Lean, they needed to aggressively train their partner firms upstream and downstream from them in the Lean ideas around flow, pull, JIT, etc, etc.

Does this make sense to you?

Mura, Muri, Muda

These are Lean words. In Japanese. And I always get them confused, especially the first two, so I am doing this post partly to have a place to remind me what each word means. They are all in the negative.

Mura: unevenness of flow. Thus, the first thing to do is establish a reasonable pull, an even flow.

Muri: overburdening the system. (System being the overall thing you are talking about; generally not a computer system.) Thus, once you establish a production "pipe", don't try to force more through that pipe than it can handle. As a fluid dynamics person will tell you, if you overburden the pipe, it means even less liquid will travel through the pipe in a given time period.

Muda: waste. This is further defined by Type I and Type II muda. And by the classic 7 wastes. "Muda" is an ugly work in Japanese. Kind of like an earthy but dirty Anglo-Saxon word, I think.

The classic definition of Type I muda is necessary waste, ie, something that does not add value in the customer's eyes, but we feel, as a business, that it is necessary. (Compliance with government regs might be an example.) I call this "waste we have not yet figured out how to live without" (maybe not true of all things in this category).

The classic definition of Type II muda is unnecessary waste. I'll call this obvious waste (as soon as you put yourself in position to see it).

There is of course an inter-relationship between the three (mura, muri, muda).

In general, I find these ideas very similar to things we say in Agile, Scrum, XP, etc.

Jim Womack suggested that Lean thinkers practice those in that order, ie, focus on mura first. Then muri. Then muda. Perhaps this is good advice for Agile. (BTW, if you don't know Jim Womack, get one of his books: Lean Thinking. Recommended.)

Respect People

"Respect People" is a key tenet of Lean. Of course, who wants to disrespect people?! Still, when people study why Lean works in one company and does not work in another company, the answer the some of the best people give is: Respect People is truly realized at the successful companies.

Jim Womack leads the Lean Enterprise Institute. Go to lean.org.

Womack & Jones wrote Lean Thinking, which you must read.

Last December Jim Womack wrote a letter, in which he talked about what "Respect for People" means in a Lean context. Here's a key quote:

Managers begin by asking employees what the problem is with the way their work is currently being done. Next they challenge the employees' answer and enter into a dialogue about what the real problem is. (It's rarely the problem showing on the surface.)

Then they ask what is causing this problem and enter into another dialogue about its root causes. (True dialogue requires the employees to gather evidence on the gemba – the place where value is being created -- for joint evaluation.)

Then they ask what should be done about the problem and ask employees why they have proposed one solution instead of another. (This generally requires considering a range of solutions and collecting more evidence.)

Then they ask how they – manager and employees – will know when the problem has been solved, and engage one more time in dialogue on the best indicator.

Finally, after agreement is reached on the most appropriate measure of success, the employees set out to implement the solution.

This is not simple. It does not say that one person knows everything. And it is not mere consensus building. It is engaged and committed knowledge creation. With some healthy "intellectual fighting".

How does this sit for you with Agile? Does this approach make sense with managers outside the team working with team members?

I will guess that it provides more respect to the team member than many actually get now. And also more engagement with a manager than many get now. At least that is what I have typically seen.

5 Whys: To get better, say "why?"

If you have a 2 year old, or remember them, you are familiar with the word "why". Repeatedly. Now, a more adult way to use that word.

Lean tells us we should ask "Why" all the time. In fact, the 5 Whys. To discover the root cause of a problem. So we fix it once and for all.

Here's how Taiichi Ohno explains it:

It is difficult to do even though it sounds easy. For example, suppose a machine
stopped functioning:

1. Why did the machine stop?
There was an overload and the fuse blew.

2. Why was there an overload?
The bearing was not sufficiently lubricated.

3. Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently.

4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.

5. Why was the shaft worn out?
There was no strainer attached and metal scrap got in.

Repeating why five times, like this, can help uncover the root problem and correct it. ...get the real cause...which is often hidden behind more obvious symptoms.

Do you ask the Five Whys every time you have a bug in your software?

To hear further explanation from Taiichi Ohno, see chapter 2 of his short book:



There are many other great ideas in this book.

Have Compassion

Today I was in a meeting with Business and Technology folks, and I started talking about Customer Collaboration over Contract Negotiation. (Many will recognize this line from the Agile Manifesto.)

And I talked about how, always, there is distrust and tension and misunderstanding between the Business side and the Technology side. Well, at least on day 1 in every client I walk into. YMMV. With luck, we start building trust right away.

In thinking about this on the plane back home, I wanted to say something to those 12 people. And since they are not with me now, I will say it to you.

Have compassion.

What do I mean by that really?

First, the most important thing is that it is more blessed to give than to receive. More specifically, it is not about you. It is about doing for others, most especially for the end customer.

Let me introduce my second point with a story. When I teach Agile I like to start with the story of the 6 Blind Men and the Elephant. I won’t explain that story now, but one reason I like it is because that story is also related to Buddha. The compassionate Buddha, as he is known. And Buddha had great compassion for us, and our inability to comprehend all the knowledge we needed to know, and to figure out what is really important. And I say, we team members should have compassion for each other and how hard our work it, how much we need to learn. We try to solve the problems if a person who almost always is not there, and do it with a system that is abstracted and non-concrete in the extreme. And all the easy projects have already been done. Difficult work. We need compassion.

My third point is more specific. My experience is that most Technology folks have no conception of how difficult it is for the Business folks to see and be accurate about what the business need to do to satisfy their customers. The customers are changing, the competitors are changing, they don’t have time to understand what is do-able. This is extremely difficult work that only a few are truly insightful about. (In our economy, many are modestly lucky.)

On the other hand, the Business folks need to have more compassion for the technology guys. Technology work is extremely challenging, and offers great opportunities for creativity and discovery for those Business folks willing to travel those uncharted seas. And capable of escaping the dense fogs.

My fourth point starts with Deming, who has many valuable insights. Deming said that all problems in business are caused, in simple terms, by two things: “the system” and the people (vices, true inability, laziness, etc.). The “system” was all the things that were (or were not) there to structure the people and the work to get the work done. Initially he guessed that 80% of problems were caused by the system and 20% by people. As he grew older and learned more he revised that. I think he finally said that 95% of problems are caused by the system and only 5% by the people. And a leader's job is to get the system improved.

My point here is that, while you may be frustrated in some ways with your colleagues, most of your frustration is not about them, but about how “management” (maybe yourselves) have structured the system through and in which you work together (or not together).

Have compassion. Have patience. And start improving it today.