Saturday Morning Ramblings… Bloody Stoopid Mary

Good morning everyone… I’m on a plane up to Philly to do a little work with the PMI Agile CoP. Delta bumped me to first class and I’m halfway through my second Bloody Mary. I’m asking that you be patient with me while I ramble on here a bit. I’ve got a nagging issue on my mind that I want to explore with you guys while I’m in transit this morning.

I was on my way home last night, on my way to the Buford High School homecoming football game, when my good buddy Dennis Stevens called and asked if I wanted to get together for a little while. I had a few hours until I needed to be anywhere, so I was like sure. You’d think that after a few years of knowing each other, we could find something else to talk about, but the conversation quickly turned to Scrum and Kanban.

You guys know that I am pretty pragmatic when it comes to selecting methodology… I genuinely feel that in the right set of circumstances, most methodologies… even Waterfall… have their place. What tends to set me off… and almost always forces me into some sort of a ‘devils advocate’ position, is when we start talking about these things as if they are absolutes.

Without going too far off in the weeds, we got to talking about Kanban’s strengths when it comes to helping teams that have to blend operational or support work with other project work that has deadlines. Dennis was passionately making the case the Kanban is superior because it has classes of service, work in process limits, and explicit policies.

Of course this is all true… but what inherently makes it better? NOTE: getting ready to play ‘devils’s advocate for a minute. With every Scrum team I’ve spun up, we’ve had a conversation about how much time should be allocated to support. We just know that whatever is allocated to support, that allocation is going to lower our velocity.

We’ve implicitly define a class of service and we set an implicit policy around the work. What’s the big deal? Sure… if I was a Scrum team that wasn’t taking support activities into consideration, or doing something stupid like aborting the sprint every time a new support issue came in, Kanban might help. But I’m not talking about strawman Scrum here. I’m talking about well coached Scrum.

I suggested to Dennis that the premise of the discussion was fundamentally flawed. The real problem isn’t which approach should I use to manage this variation… it’s that this variation fundamentally exists in the first place. You see… I can manage variability using either approach… the problem is that we have work that inherently needs stability (new product features) being done by the same team that is doing work that is inherently unstable (bug fixing and support).

We can use either approach to constrain the amount of time allocated to the variable work, but what happens if all hell breaks loose and that policy has to be broken? Sure, we need to have a conversation about that… but I’m not convinced that Scrum or Kanban does a better job a prompting that conversation. Again… the core challenge is that these two concerns are competing for the attention of the team.

Someone goes away unhappy… either the customer waiting for a fix because the policy was enforced, or the product owner waiting for a feature because the policy was broken. So you see… this isn’t a methodology problem… is a communication problem. It’s an expectation problem. More than likely its a technical debt problem. And it’s also likely that we haven’t invested enough in the product to get done everything that needs to get done.