I really like the treatment that Henrik Kniberg has given when contrasting Kanban vs. Scrum. He expresses a dialog that is not too dis-similar to conversations I have heard especially in fire-fighting environments that are asked to shoehorn Scrum as this is best thing since sliced bread. Okay, that is a bit of a stretch, as I can do without Scrum but not without food!.
From what I have seen, this shoehorning occurs as usually the impetus is to conform to a mandate coming from a higher authority within an organization. This is usually management needing to use a common methodology by which all business operations that are delivering projects. This being most acute with groups that interface with Engineering teams, where Scrum is usually rolled out first. I’ll go out on a limb here and say Scrum isn’t a methodology. Sure it is a framework of iterative practices to deliver quality product (or services) in small batches. This is aimed to be in concert with the customer, so the customer gets exactly what they want and when they want it. The practices are one of team work and really fostered as bottoms-up approach to solving problems of delivering projects (products or services) that otherwise far often then not have failed to materialize value to the customer as either they are too late to market, at times the wrong thing at the wrong time, or just too costly to be of benefit.
The problem with the top-down approach suggested by mandates I refer to are – that they do not see the whole picture in terms of work flow within an environment. Sure this is a tactical issue of The how? as opposed to The why? when it comes to shoehorning any set of practices, including Scrum. By the way don’t get me wrong, mandates can be a good thing for kick starting change as much as getting everyone pulling the oar in the same direction, and hopefully the right direction. Scrum truly helps in this as it quickly surfaces issues that block team work and allows one to steer the team and potentially organization in the right direction if error is made in charting the wrong direction. I have also witnessed an initial shoehorning exercise where a divisional group lead would say “we just need to do is speak the same vernacular of Scrum that the Engineering teams were doing”, and by implication this will make the group Agile!. If this isn’t cargo cult behaviour then what is?
So you can see why I like the line Scrum is just a tool! You choose when and how to use it. Don’t be a slave to it! is the nub of what Henrik has stated. This is to say one may need to shape and customize how Scrum is practiced in your environment, this includes your Engineering environment and not just roll it out of the box. In order to customize this you’ll first need to identify and analyze some of the first order problems you are seeing in your environment and you wish to solve. It is not enough just to say “we want to deliver quality products or services first to market to our customers”. Tell me who doesn’t want to do that! Scratch this surface statement and ask what is it that is holding you back from doing this today, and which of the Agile work practices such as Scrum or Kanban (Scrum on steroids) mustered in software development environments by XP & TDD practices will best help overcome some of these impediments. Don’t kid yourself with tools of technology if fundamentally communication or timely decision making are the real problems. You’ll need to be honest to yourself at the team level, as well as at the organizational level when dealing with the gap in the Knowing & Doing of what are two critical components leading to less then stellar project work outcomes.
Based on my experience with software development and service operations teams I have to say the pull practices of Kanban, initially instrumented with WIP (work in progress) limits is a better starting point. To some this may be getting teams to swim in the deep end, in truth no more so than taking on a fresh graduate or a new employee and saying okay you are part of the following team. If there is no nurturing in the work practices in your particular environment then one only sees cargo cult behaviour when it comes to Scrum.
In conclusion, I firmly agree Scrum is just a tool!. You choose when and how to use it. Don’t be a slave to it!. Which means weave in team work practices such as Kanban and foster software development teams to adopt XP, TDD as part of the overall Agile framework that you need. The need being defined by the set of first order problems related to team work (individual) and Team Work (organizational) that you as part of a group are trying to solve.
As for the organizational team it will be of great help if you also map the value chain within your organization. This map addresses all the functions that are involved in product or service life cycle, from both the customer view point as well an internal view point. After all customer doesn’t see or experience all the pieces of the jigsaw that brings value to them. Use Lean principles to guide the Agile practices you are adopting and refine these based on your and the teams experience. After all much like a car engine that has to be tuned to match the organizational & team culture, with culture change being on a relatively slow time scale. Which means be patient with the teams and don’t rush to refine before you have some real evidence from the Teams in what is working and what isn’t. Most of all be pragmatic in your approach for nurturing Agile practices, and take great care not to read into the tea leaves of statistics of How well Teams (organizational level) are doing? based on a voting turn out in internal surveys that are lower then the turn out at a U.S election. I have witnessed this too, from those who have a vested interest in calling out the success of the fruits of their labor of rolling out Agile practices. Sure is difficult to be independent even in a Scrum and an Agile environment!.
As for pragmatic, I mean use base principles such as Lean to support the decision making and tune the Agile practices in your software development or otherwise work environment. These principles are tried and tested in many situations, from Lean manufacturing, construction to Lean Health care – and as such not unique for software development. Many have expressed the Lean principles, and currently I am using the following mnemonic D.E.A.D B.S.E (hey, this has nothing to do with the mad cow disease, far from it. It sure is a guide to preventing the effects of this within software development teams 🙂):
- Dilver as fast as possible
- Eliminate Waste
- Amplify Learning
- Delay Decision making
- Build in Integrity
- See the Whole
- Empower the Team
as a reminder to help any team that has to make a decision on some issue that hasn’t been previously encountered and past experience and know how does not point to a clear choice amongst a selection of options. It allows the team to shape Scrum practices and frames a more constructive team discussion then does knowing and doing the Scrum practices alone.