Scrum, Kanban, ScrumBan…wait what?

Recently one of the Dev teams I’m the scrum master for wanted to try Kanban after seeing the success of another teams use of Kanban.  question-mark-clip-art-free-clipart-images-655x1024“Why would you do that? Why would you even let a team consider switching?” you might ask.  Something to help ease your mind or those on your team who may resist being open to such ideas –  remember its okay to try new things (be agile, not chaotic but agile – yep this is a hot topic).  Your mind might be running a million miles an hour thinking of all the by the book answers that would say not to let a team switch from one process to another, even for a possibly short time period.

how can I call myself a scrum master if I don’t even have a scrum team

I too was a little wary at first.  Thoughts like “how can I call myself a scrum master if I don’t even have a scrum team” or “how can I protect the team from distractions”, “how will I do reporting now”, “how will we do this and how will we do that”.  The ‘scrum cop’ inside of me was resistant at first.  All thoughts I had deep down inside, but based on my different experiences and readings, I remembered a lot of other great agile principles and teachings.  One that really stuck out to me is the one portion of the Agile Manifesto that says “Individuals and interactions over processes and tools” (see my other post People > Process for more on  this topic).

Other thoughts came to mind of when I completed my Certified Scrum Product Owner training, when the instructor confirmed that at the end of the day its really up to the scrum team how they implemented or delivered their increment, or chunks of work.  I’ve also been to great seminars and received great training on Product Ownership (the instructor felt the teams should be called Product Teams – this point was not my cup of tea but great training overall).  I understand all point of views here, but remember be open to discussing this as a ‘scrum team’ and choosing your own path or process. I know, I’m going off on a bit of a tangent here, and trust me, I know there are a million more counter arguments to this mentality (I know as I pretty much went thru them all in my head).  Lets get back to my scenario about one of my teams wanting to try out Kanban.

The team and I were a few weeks into trying Kanban when the team regrouped for a retro.  Wait what? why did I just say retro when talking about Kanban? More on that in a bit. During this ‘retro’, the team was evaluating wether or not they saw improvements or value in the short time we were following kanban practices.  The team agreed that they really like scrum, but that they felt confirmed in their (our) previous belief that team would be better suited for kanban due to the ever changing vision or ask from product. Not to throw the product group under the bus here, it was just a good call out. The team, however, did agree that they would like to get back to scrum but only if the product vision was clearer, or should I say, the features they where working on actually built upon the previous increments without constant context switching.  To the teams delight, the product owner agreed with the teams call out here, and even agreed to take this on as an action item to work towards reducing upcoming context switching and more consistency to feature intake.  Team agreed to try out kanban further until ‘things’ (features, etc.) became a bit clearer, or less changing.  Yes I know what you are thinking, perhaps this points to a much bigger problem – time will tell in our case.

Some would argue that instead of trying out kanban to have this productive discussion and team agreement, that the scrum master recommend that the product owner / team abort all upcoming sprints until the product ‘features’ or chunks were more constant and achievable.  Thats definitely one approach,  but the approach my team took just so happened to be better for our current situation.  Every team and situation is different, and again time will tell (which is all apart of the learning experience towards improvement).

So, why the Scrumban reference above? Why would a team do a retro in Kanban? What is that all about? 

Our team at first just had the retro as a form to evaluate the short time they had intially tried out Kanban.  During this retro, team agreed that they liked the Kanban retro format (which follows the format of that once at any time three retro topics have been added to the board the team talks thru them right away).  The team also liked having a short retro session every two weeks as well to capture an overall perspective of how Kanban is going for the team.  The team also agreed to have a grooming session scheduled every other week (just like before when doing scrum).  That’s were the similarities between the two processes end, as our Kanban process fits the bill and checks off all the other items seen in proper Kanban. I’m not certain this would be called scrumban, but we shall see how this plays out.  It will be interesting to see how things play out, and I along with the team am excited for the possibilities to come.

I understand many will think “if you are always switching processes you aren’t very consistent and therefore can’t build a high powered team”.  That’s a valid point to keep in mind for sure, don’t over do it, as long as the team is productive and they are all learning together I see no harm at this stage.  But, that said there is definitely a balance to obtain here between trying new things and stability, decide this as a ‘scrum team’.

Here is a similar interesting article to challenge your brain cells.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s