Several years ago I tried to discuss the need for Lean when Scrum was being used on projects with more than one team. Ken Schwaber didn’t want to hear this and eventually threw me off the Scrum Development Yahoo discussions group. I admit, I was talking outside the domain of what he wanted – the pretense was that Scrum wasn’t Lean and the Scrum Development group wasn’t the place to talk about Lean.
Times have changes – a little. We now hear how Scrum is based on Lean but I have heard little acknowledgement that Lean-thinking, used explicitly, is an essential ingredient for Scrum teams. At the Scrum gathering I heard of a successful Scrum implementation of a company that had 150-200 folks in it. I can validate that myself. Because I had been in there myself, before they were successful with Scrum across the enterprise. True, it didn’t take much to get them from successful team Scrum to successful enterprise Scrum, but it did take Lean-thinking, value stream mapping and an understanding of Lean-flow to get them there. While Scrum is a great team process I still contend it is rarely successful at scale because the framework itself does not provide the insights needed to extend it. If that’s the case, part of the Scrum discussion should be about what is needed to include in the framework.
For the last few years I have been promoting Kanban, both team-Kanban and the Kanban Method, a transition management method across the entire value stream. Team-Kanban is best used within a full-value stream view as well, but it doesn’t require the Kanban-Method’s approach. It is unfortunate that the term Kanban has been so overloaded (see De-Mystifying Kanban for a description of all the types of Kanban).
Net Objectives is not attached to any one method. I believe we are the only company that promotes Scrum, XP, Team-Kanban, Kanban Method, SAFe, and Lean, along with technical practices. Our approach is to see where people are, what their culture is, how much discipline they need, the extent they can form teams, amongst other things. If you missed our webinar, Beginning an Agile Transformation, you might want to watch it for a full list of what to look for.
Our experience enables us to cull the best approach from all of these methods to suit our clients’ needs. Sorry, I’m not trying to make this a sales pitch, anyone can take this approach. Unfortunately, relatively few consultants do. I’ll admit I'm writing this blog for practitioners and my advice is don’t decide between methods, learn from each of them. In other words, it’s not Scrum Vs Kanban, it’s how do we take the best approach for the needs at hand. This requires understanding the strengths and limitations, particularly where they best apply, of both.
Since the Lean-Kanban community has been forefront in bringing new methods to the Agile space, I had thought it would behave a bit different from my experience in the Scrum community. Unfortunately, apparently not. Because Net Objectives uses both Scrum and the Kanban Method, we’ve learned a lot from both. While the Kanban Method facilitates the creation of effective value streams when true teams can’t be created we’ve seen that teams are truly valuable (see Know the Power of Teams).
I started discussing the value of teams on the Kanban Development board and essentially ran into the same attitude as I had years ago. First it was – “teams are orthogonal to the method.” Then it was “let’s not discuss this.” Then it was “you (meaning me) are not behaving professionally.” This time I left before getting moderated or thrown off. But it’s a bit distressing to see the same attitude – “our method is correct, let’s not discuss things that aren’t defined in it.”
Tragic.
Practitioners – please don’t fall into this trap. There are many consultants out there not attached to any one method. Because of this, they often don’t have an accreditation from either the Scrum Alliance or the Lean-Kanban University. Don’t take that as a negative – it might be a plus.
Al Shalloway
CEO, Net Objectives
