I often hear people say “oh, we do Scrum but we don’t do …”. This includes “we do Scrum, but we don’t have fully cross-functional teams.” Or, “we do Scrum but management interrupts us all of the time with needed new functionality.” With the creation (and misunderstanding) of Kanban, we often hear “we do Scrum but we don’t have hard iterations, we follow more of a flow model.” Finally, “we do Scrum, but we don’t always have tests complete by the end of the sprint.”
The irony, however, is that you can’t really do Scrum and have a but like this. Scrum is based on the notion that you dogmatically follow its practices and remove any impediments to doing so. This is based on the idea that if we actually do the Scrum practices of having cross-functional teams, being complete at our sprint boundaries, not interrupting our sprints, being guided by a product owner, and providing visibility of our work progress then we will improve our methods. Scrum is pretty amazing in that it actually works without explaining why. In fact, my belief is that many people doing Scrum misunderstand why (see Why Scrum Works and How This Tells Us When It Won’t).
Classic Scrum is specifically based on the idea that one can’t have a well-defined process because what we are working on is not well defined. This is, unfortunately, a gross mis-understanding of systems, processes and complexity (see a guest blog - Types of Processes by Don Reinertsen). While micro-predictability is often unavailable (e.g., is the ball going to land on red or black in roulette) we can know with fairly good certainty that in the long run more money is staying at the table than leaving. In any event, Scrum proponents insist that you follow the practices of Scrum, and remove impediments along the way. There is not an acceptable time for you to violate them. If you do, you are doing “Scrum-but” with the implication you are not doing Scrum properly and the further implication that whatever it is you are doing is not as good as what you’d be doing if you were, in fact, doing Scrum.
This lack of awareness of the laws of software development leads to much waste, because people follow practices mandated by Scrum, where other practices could achieve the same (or better) result with much less effort. If we understand a few basic laws of software development, we can come up with alternative methods to achieve our intended result (see The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think). By “laws of software development” I mean things that are just true, regardless of opinions about them - see Principles and Practices All Agile (including Scrum) Teams Should Know and Follow. While it has been stated that we must do iterations because of uncertainty it is rarely discussed as to why that is true. In fact, this type of conversation has been frowned on in the community.
To be truly effective, we must understand the following:
I find it ironic that many Scrum proponents say learning Scrum should follow the path of Shu-Ha-Ri (follow basic teachings, break from tradition, create what’s useful). I personally dislike this metaphor because when learning martial arts, at the beginning, an understanding of theory is not necessary, while in knowledge work, it is always useful. But the irony is, I have never heard a Scrum thought leader explain when or how to break with the teachings of Scrum – doing so is Scrum-but and to be avoided. But if one is suggesting Shu-Ha-Ri, one must explain what to do in the Ha phase. Something we do at Net Objectives, but something I see rarely elsewhere.
The challenge with all practice and no theory can be summed up with Edwards Deming’s quote – “Theory without experience is useless, experience without theory is expensive.” Even when the practices are correct, they will often not be followed due to a lack of understanding (see People and Process). In the same way that engineering has laws (e.g., when building a bridge, we must attend to gravity, the elastic and compressive strength of our materials, and as we found out in Tacoma in 1945, the effects of wind). Some basic laws of software development we must attend to are:
Let’s take those first examples of Scrum-but at the beginning of this blog and see what we can do about them. In particular, let’s ask each of the four questions I mentioned above.
We do Scrum, but we don’t have fully cross-functional teams. We see this a lot because creating cross-functional teams is often difficult, incredibly expensive or downright impossible. For example, getting another person to have the experience of the decisions made when the code was written won’t be possible until we invent time machines that will let folks go back to that time. Unfortunately, if we actually end up sending anyone back, they will bring a copy of today’s Wall Street Journal and buy stocks back then – they won’t work for us when they come back. OK, I’m joking, but you get the point.
The purpose of cross-functional teams is to have all of the people we need to get the work done be available. The principles this is following is to avoid delay in the workflow. The law underneath this is that delays in workflow cause extra work to be done (consider how the delay between coding and testing makes developers spend a lot of time finding things that have gone wrong – see Cross-Functional Teams Eliminate Waste and Manifest Lean). Finally, we can achieve the intent of this practice in one of two ways:
While this might have you not be doing Scrum, only your consultant cares about that.
We do Scrum but management interrupts us all of the time with needed new functionality. It just may be that we should be allowing management to interrupt us during a Sprint. Perhaps the interruption is because we can make a lot of money if we do so. In my mind, Scrum has lost much of its application to software because it has lost sight of what inspired it in the first place – The New New Product Development Game (a must read by any Scrum developer). There is a big difference between a team building a new product, with no maintenance or support responsibilities, and the reality most Scrum teams face of extending an existing product while maintaining the product as well. The idea in “The New New Product Development Game” was to let teams explore on their own without micro-management. But in the world most of us live in, we have other responsibilities.
In this case, we may want management to interrupt us – when the financial opportunity presents itself. So, let’s go through our questions. The purpose of this practice is to not interrupt our workflow. The principles we’re following is to not have too much work in process. The laws underneath this are that these interruptions and too much WIP will cause additional work for us. The other way to achieve this is to use small stories, manage the WIP inside our sprint and use automated testing so as to require management to have a delay of only a couple of days before we can start the new work with all of our other work being completed.
In other words, the main cost of interruption is not the pushing items on our sprint backlog down, it is the cost of the interruption of the work taking place. Inserting new work above something in the sprint backlog that hasn’t been started is not nearly as costly as inserting something into the sprint while we are working on stories and having us work on too many things or having to set aside some partially completed stories to the next sprint.
We do Scrum but we don’t have hard iterations, we follow more of a flow model. People don’t like to be labeled as doing Scrum but. With the introduction of Kanban, many people realized they could just say – “oh, we’re doing flow, so we don’t need well defined sprints.” Given many Scrum trainers are starting to say “we like Lean” this is not a surprise. However, a flow model requires the following:
Not doing something Kanban doesn’t do (sprints) does not mean you are doing Kanban unless you are also doing the things Kanban says you should do.
As an aside, I’d like to add that saying “we like Lean so we do lean practices inside our sprints” really means to me that the person doesn’t understand Lean. Lean’s foundation is systems thinking and an explicit awareness that we are doing “just-in-time.” Lead does not have any mandated practices – and having any would be an anathema to it.
We do Scrum, but we don’t always have tests complete by the end of the sprint. OK, this one is likely bad. I am a firm believer in ATDD, automated testing, continuous integration and completing a sprint without having completed tests shouldn’t ever happen. But let’s look at a variant of this – we do Scrum but we sometimes carry a story over to the next sprint. Again, the purpose of attempting to complete all of your stories at the end of the sprint is to avoid workflow and feedback delays which, as I’ve already stated a few times, causes waste. If we focus on small stories and understand we must immediately complete the carried over stories while we are managing WIP (so only one or two are incomplete at the end of a sprint) our waste will be kept to a minimum.
We don’t estimate because it takes too long or management beats us up. OK, so this wasn’t mentioned upfront, but is a common one. I’ll just give you a solution to this one. See our notes on estimation on our page How to Vastly Improve Your Scrum Team in an Hour. Too many people use Mike Cohn’s planning poker method with takes several times longer than it needs to. Ironically, if estimation is being avoided because management is “beating you up,” I think this is an impediment you should address. The problem is that in Scrum, we have no model for good management except to have them remove impediments for us. Again, Lean provides us with this, but only if one accepts there is a set of laws underneath all of this work.
There was an interesting study where IT Managers were asked if they’d rather be on time and budget or add real value. We laugh at the IT manager who says, when asked, he’d rather be on time & on budget than add value. But aren’t we doing the same when we become overly focused on doing Scrum instead of attending to other ways of adding value? We should never get stuck on a plan, framework or method. We should only get stuck on achieving value.
If you disagree with these comments, come track me down at the Agile Conference (I'll be hanging out in the open space when I'm not doing my Kanban and SAFeTM talks). If you agree and are looking for someone interested in your challenges and not their solutions, track me down as well.
CEO, Net Objectives
If you are having troubles running Scrum or the Kanban Method, maybe it's because the approach you are trying is the right one for you. Take a look at our New Team Process page.