Public Impediment List !!! - 2

There is a good Scrum trainer who thinks that a public impediment list is not important.  So, if he can mis-understand, then we all can.  See here is a yet better explanation.  I hope.

****

I find that the lack of a public impediment list is a prime indicator of a lack of focus on removing impediments.

This is essential in Scrum.  Why?

Well, first it is important to say that the public impediment list is not the main deal.  The list must be acted on.  But, like 12 lawyers at the bottom of the ocean, it is a good start.

The real deal is removing impediments, and making the lives of yourself, your team and your customers better.  And the impediment list is one way to do that.  Or, better to say: fixing impediments is one way to do that.  And the impediment list (public) helps you do it better.

Why have a list?  Well, we believe in doing one thing at a time, and getting relatively quicker results from that. Rather than working on many things and usually not making any tangible progress.

So, the list enables the team and the firm to order the work on the impediments.

How? Well, first an impediment is anything, anything slowing the team down. Or, if fixed, would speed the team up. (Speed meaning both higher quality and higher productivity.)  The team gets greater benefits sooner by working on the top priority impediment.

But we forgot to mention that the first one might be the one that gives us the greatest bang of the buck, meaning "business value" divided by effort. (Business value for impediments might, too simply, be thought of as the velocity increase for the team.)

So, we can always be working on the top item on the list.

And, by the way, every team has not reached anything close to optimal velocity, so there is always a top impediment.  In fact, always a list.

Why public? Well, so everyone can see and offer feedback on what are our team's biggest impediments.  Otherwise, Brian thinks he told George about Item X, but George forgot to put it on his personal list....so, it was forgotten. All these little human errors are less likely with a public list.

And we mean everyone.  People in the team and people outside the team.  And including the higher level Impediment Removal Team (IRT).  Anyway can make suggestions, and help us get better.  [I call it IRT.  Ken Schwaber and Mike Cohn and others have their own names for it.  I assume you are in a company with 4 or more Scrum teams, where an IRT starts to make sense.]

A public list reminds everyone that someone should be working on the top item, well, and that would be today!  "Has anyone started?" "Oh, yeah, I'm about to start that!"  Human nature again.

And a pubic list enables Mary... who was sure her Item B should be number one, but shows as number 10 now.... identify the problem. So, now she knows to go to George the ScrumMaster and make the case why her Item B should really be #1 on the list.  Otherwise, she might just guess that George "got it" after their hallway conversation (where he actually was thinking about the Christmas presents he needs to get).

****

The list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked.  And indeed someone is fixing one almost daily.

Again, there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person (the SM) over here *not* doing "real work." (By the way, I think the SM easily pays for himself by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts -- which has been known to happen.)

For you all into Lean, a public impediment list relates to Visual Management and to Kaizen.  Two big practices (or ideas) in the Lean community.

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Finally, let me recommend a public list of impediments already fixed.  How quickly we forget our successes.  Oh, yeah, that's why we have the stupid ScrumMaster around....

Your thoughts?

Why call it "BV Engineering?"

A man I greatly respect wrote to question why I call it "BV Engineering."  There are many engineering disciplines, he noted, but is there a degree in "business value engineering"?

I said I thought an MBA was the degree to get for this. Not another regular engineering degree.  But I agree with him that for some the name is mis-leading

But this begs the question. Why do I call it "BV Engineering?" Those of you who have taken one of my courses will of course know.

Those of you taking the BV Engineering workshop in Ottawa on Dec 8-9 will also learn (again) why.  And more.

But why?  Two reasons.

First, Scrum is a framework, and purposefully does not attempt to define the engineering practices that the team should use in building the product.   Scrum assumes that these engineering practices are not perfect.  And assumes that the imperfections will show up in the Impediments List.  And, when an impediment rises to the top, it will be fixed.

So, I want all the stuff around Business Value to be treated the same way. All the ideas, all the people, all the tools, all the process.  It needs to be continuously improved.  And items need to go on the Impediments List. And then get fixed!  So, I want BV Engineering to be amongst the engineering practices we are continuously improving.

Second, I have colleagues that have some wonderful ideas about Business Value.  Good, big concepts. Or other ideas.

And I want that to be wedded to rigor (or at least more rigor), discipline, and metrics.  Yes, metrics around BV are hard. And?  This is the only really important thing we do -- deliver business value -- so I think we should have some metrics.  And be continuously questioning how good the metrics are.  This is what they do in physics.  And so should we in business.

To me, 'engineering' implies rigor, discipline, and metrics.

So, apologies if the phrase otherwise does not work for you.

***
To see other posts about BV Engineering, just click on that label to the right.

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.