At a conference years ago Don Reinertsen & I were watching from the back of the room together & sometimes making comments between us about the presentations. At one point it was clear that there was a pattern of “this or that.” Don made a funny observation “these folks have been around 1s & 0s too long.” I had had the same feeling so laughed at his eloquence.
We’re still doing that. We look at Scrum as a thing & Kanban as a thing. Scrum has the cross-functional team be sacrosanct & David Anderson says “visualization not reorganization.” There is power to both. Both are proxies to what we need to do.
Conway’s law tells us “”organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” My corollary is that “When development groups change how their development staff are organized, their current application architecture will work against them.”
We have to recognize we’re in a very complex situation. Ultimately we need to have some simple guidance to help with decisions. The root of these are:
- make sure what you’re building has value
- look at time it takes from start to end (cycle time)
- shorten the time any part takes from start to completion
- attend to quality at each step
btw, if this looks like Lean to you that’s because it is. Lean, boileld down to its essence is:
- systems thinking
- just in time
- build quality in
I’m guessing most people are expecting me to talk about making a decision on whether to use Scrum or Kanban. But I don’t believe that’s the biggest decision to make. The first thing when starting Agile at the team is to ask “what’s in my way of creating and delivering value?”
Although Scrum proponents hail Scrum as a good way to figure this out there are other, faster methods available (mostly just look at your current situation and see where your blockages and large queues are – see Value Stream Impedance Scorecard for more).
Common challenges are:
- developers & testers don’t collaborate well together on stories
- people aren’t interacting well with each other
- the lack of cross-functional teams is causing delays
- work is not done in short cycles so feedback is hard to get
- teams are being overloaded with work
- teams don’t know how to write small stories
Clearly Scrum & Kanban both attempt to address this in their own way and it should be clear how each one addresses these. Your choice though is to learn a framework or method that helps you with these challenges or in your initial training work on them directly – and then adopt a Scrum/Kanban approach that best fits your situation.
People often conflate Scrum with Agile. But Scrum is not the same as Agile. Agile is considered by many to be a set of values, principles and way of being. Scrum is a framework consisting of roles, rules, artifacts and events. It is designed for teams to add those practices needed in order to become Agile.
XP is quite different. Continue reading “The biggest difference between Scrum, XP and Kanban”