Scrum and Kanban

We run across informative books that tell us just a bit more.  Henrik Kniberg and his coauthor Mattias Skarin  have just such a publication with Kanban and Scrum – Making the Most of Both.  It is a great reference with many examples.  When I started having individuals and teams and ask for the differences between Scrum and Kanban, I wanted to help them by explaining the impact of choosing either. Once I was sure that a team didn’t just want to adopt kanban in order to hide from a scrum master, we were ready to explore the impact of going with one, the other or a mixture of both (Scrumban).  The 3 columns below were a reminder for making a good comparison.  The choice however also included some consideration for the organization and where we ultimately wanted to grow. Hopefully it serves to help the conversation you may have with that team along their agile journey.

scrumkanban1

scrumkanban2

scrumkanban3

Start with Retrospectives

Never stop experimenting

  • Fear vs. empowered
  • Mistakes vs. failures
  • Continuous Improvement

Feedback +/- Long vs. Short

  • Too Long may make it hard to find a root cause
  • Too Short may cause thrashing with no process stabilization

A Short History of Kanban:

1950’s Edward Deming a quality focused statistical process control person form the US is in Japan doing work for the Government.  Taichi Ohno who creates the Toyota Production System (TPS) is similarly working on Just In Time (JIT) and Lean Manufacturing methods.    Kanban results from this crucible of ideas in time.  Both Edward and Taichi die in the 1990’s when Lean Manufacturing is gaining popularity in the US.  Kanban means ‘signal board’ in Japanese.  It is a tool to help drive out waste.  A pull of inventory and work is preferred over a push.  The signal board helps to communicate work in progress and the state of this work.

Muda    – ‘waste’

7 kinds of waste are identified [They still hold relevance from a manufacturing world to an IT world – Read the book “The Phoenix Project” for more comparisons between the two]

T – Transportation [Today I put this in terms of COMMUNICATION TRANSPORTAION – how many emails, tools notes and days have passed rather than just stopping over or pairing up and getting it straight]
I – Inventory [maybe this is license usage, capacity, ]
M – Motion [meetings that weren’t useful]
W – Waiting [Time, feedback lags, process completion]
O – Over processing [duplication of effort in code, replication in different tools or the organization]
O – Overproduction [producing things the customer didn’t want and didn’t align with expectation]
D – Defects [!!!]

Mura     – ‘unevenness’ – [making the peaks and valleys a bit more level with shared resources or load balancing]
Muri      – ‘overburden’ – [still speaks to sustainable pace today]

A Short History of Scrum:

In 1986 Ikujiro Nonaka and Hirotaka Takeuchi write a reactionary paper called the “New NEW Product Development”.  In it, they note that the team behavior that works best is very scrum-like.  This is in reference to the sport of Rugby.  In the 1990’s in the US, Jeff Sutherland and then Ken Schwaber, start experimenting with software development teams and keep this inspirational terminology.

Advertisements

Foundations Are Important

Foundations are what people build on physically and mentally.  If an investment isn’t made in establishing a solid, built-to-last foundation you’ll be hard-pressed to add anything on top of it successfully.  Seems reasonable, right?

Yesterday was a tough day for me.  I started coaching a team recently that had the benefit of a consultant coach for about six weeks.  This team was chomping at the bit to “just get going”.  I had been told they had been in training, workshops and all kinds of other things prior to my arrival and so I, incorrectly, assumed the foundation had been established.

Lesson #1 (for the 100th time):  Don’t make assumptions.  Trust but verify.

So, two weeks ago, they started sprinting.  As you can imagine, it was a solid, foundational learning experience.  Planning was done(ish).  They had been instructed to use Scrumban.  Admittedly, I am far from an expert in Kanban and know even less about Scrumban so I wasn’t certain about how to go about helping this team.  I went to do some on-line research and consulted with some coaches I trust.  I learned that attempting a hybrid from the get-go might not be a good idea, but a committed team could work through it.  I crossed my fingers and hoped they knew what the heck they were doing.

Lesson #2:  Sometimes, you risk losing an excited team by not trusting your gut.

It was really hard – for them and for me.  I found myself at a loss for what to do and they were clearly very frustrated with the process as was I.  Back to consulting with trusted coaches who advised me to take them back to Scrum or Kanban.  Based on what I read about Kanban and not having the experience with it, I opted for Scrum both as a better fit for them and for me.

Lesson #3:  Building a solid foundation on top of a crappy one isn’t ideal.

I worked with the necessary people to get a full day away from the work to invest in some training and establish a foundation.  Yesterday was the day.  First question out of the gate after the goals, agenda and we’re going back to Scrum intro….. “Doesn’t the team decide?”.  Yes.  Yes they do.  Once a team has been presented with what each framework offers and can make an informed choice, they can certainly choose.  This team didn’t choose Scrumban, it was prescribed.  I wasn’t allowing them to choose Scrum either.

Lesson #4:  Trusting yourself and others takes guts.

We worked through the agenda.  A background on Agile.  Review of Scrum.  High-performing teams.  Story writing.  We powered through.  I powered through.  I was tested at every turn.  At the end of the day I was exhausted, frustrated and, frankly, a little beaten.  This morning, I wasn’t looking forward to going in to work.  Here’s what happened:

  • A team member watching me slog through getting all the stories and tasks into the spreadsheet and up on the board offered to learn how to do it and them completed the last 25% of it for me.  Bless her.
  • A team member put a large post-it on the wall for people to share their “Bold” Agile actions.
  • Another team member put a different one up for members to share how they were “fertilizing their roots”.  We did a review of the high-performance tree in Lyssa Adkins amazing book “Coaching Agile Teams”.  (LOVE that book)
  • The team was positively chatty today.  Generally, they’re all clammed up and it’s stifling.

Lesson #5:  Being challenged is a good thing.  It makes you give it your all.

On to more learning now and if someone can please tell me more about Scrumban, I would really appreciate it.

Final Lesson (for this week):  Don’t start without the foundation.  This applies to teams or to Scrum Masters with a new methodology.