Category Archives: lean

High Interrupt Work in Scrum

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by

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.

 Subscribe in a reader

JIT Knowledge Creation

Posted on by

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.)

 Subscribe in a reader

An Intro to Business Value Engineering

Posted on by

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

 Subscribe in a reader

Productivity Now

Posted on by

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.

 Subscribe in a reader

Kaikaku or kaizen? (2)

Posted on by
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.

 Subscribe in a reader

Kaikaku or kaizen?

Posted on by
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?”

 Subscribe in a reader