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.