Scrum or Kanban

I was asked this the other day by a scrum master at my current organization.  For disclosure, I’ve been involved with Agile delivery for about 8 years or so.  I started out with Scrum and have been involved with Scrum, XP and Kanban ever since.  I’ve been a developer, a delivery leader, a coach and a trainer over this period of time so hopefully you’ll see my opinion as being informed.

My response to this individual’s question was that I can take a newly formed team and get them to predictability in Scrum regardless of talent and skills, but just a general desire to learn the framework.  Scrum is very good at providing a framework for delivery.  It’s got artifacts, ceremonies and there has been so much literature written about the topic that there is no shortage of finding guidance.  Notice I didn’t mention anything about self organizing or empowered teams.  To me, this is a basic ingredient no matter what direction you choose.  If you desire for a more command and control type structure, perhaps you are better off not reading any further.

So what about Kanban … I have two things I like to consider when moving to Kanban.

  1. Do I have a  high performing team that is mature and looking for ways to get even better
  2. Do I have a new team that is made up of strong folks who are responsible enough to wield the power of a lean delivery model

If I don’t have either of those, I tend to shy away from Kanban.  Reason is, I’ve seen too many teams take advantage of the things about Kanban that make it so powerful.  Such as, with no time box, people work endlessly.  Again without a time box, the size of a work item tends to grow.  With no defined sprint planning, team members don’t work together to plan work.  With no defined retro, they often don’t improve on demand.  With no prescribed demo cadence, an on demand demo just doesn’t seem to occur.  So unless you have the right folks or a strong leader, these things just don’t occur.

I get it, you could argue that all of the missing components in Kanban could be added in, but to be honest, I don’t like that form of prescriptive nature.  I believe when Kanban is working, demos spawn at any point, retros occur when someone feels the need to improve.  I do still like cadence based planning but other than that, I’m not really in love with the idea of ScrumBan.

So to wrap this up, my opinion is people are what’s important, not necessarily the process. I’ve got plenty of experiences that show this at small scale as well as at large scale while implementing the Scaled Agile Framework.  It doesn’t truly matter at the end of the day what method you use, but that you choose the one that best fits your people and tailor it according to your environment.  Know what success looks like and measure your progress towards that and I think you will be just fine.

facebooktwittergoogle_plusredditpinterestlinkedinmail

PMO in Agile

This keeps coming up in quite a few conversations I’ve been having lately.  Does the PMO have a place in an Agile Software Delivery team/company/project etc?  I have a couple of opinions on this and its really an either/or.

If your organization currently has a Project Management Office and you have a strong hierarchical reporting structure, I believe that you can repurpose this group of folks.  Especially in the case that the people in the organization are really looking to embrace a new role.  Don’t get me wrong, this will come with challenges.  Traditionally the PMO is a command and control type org that breaks down work and assigns out tasks and manages to delivery.  In an Agile model, you typically don’t have much use for this type of behavior as you are working with a group of empowered, self-organizing and intelligent knowledge workers.  However, what I think often goes left unsaid is the need for vertical reporting of team data as well as program level data.  As a delivery leader, I’m not so interested in sprint burn downs, task burn downs etc, but I am interested in predictability metrics, feature completion against a roadmap and overall quality of the codebase.  This is stuff that I think the PMO is very well suited for.  In this model, I’d call them “Ambassadors of Transparency”.

Now if you are starting something up from scratch, my opinion is that adding the layer of a PMO is probably unnecessary.  With the right tooling and the right scrum master or product owner, I believe that this information can be shared and flowed in a different manner.  I find that in this model, the team(s) are all in on the upcoming milestones and they are owners of their data in addition to their code so they are more than happy to share their progress.  Basic scrum doesn’t really have a recipe of this and neither does the kanban method, but I think that’s what I like most about finding the right balance of process and people … you tailor to your needs based on the framework.

facebooktwittergoogle_plusredditpinterestlinkedinmail