When most people in the Agile community talk about agility at the enterprise level they think the only way to get there is to start a pilot, see how well it works and then expand to other teams – essentially a bottom up approach. When they hear someone espouse -a top down approach they normally assume the person means a focus on best practices and/or a mandate by executives telling people how to do their work. I wanted to be clear that Lean does not suggest either of these approaches. I'm not sure I'd even say it involves a bottom-up and a top-down approach at the same time (what does that mean, anyway?). It recommends an optimize the whole approach – and that takes all of the people (at all roles) involved in the work taking place throughout the value stream.
To understand this, one must understand two main concepts. The first is that software, by itself, is not useful. Software enables what is useful. The second is to recognize that there are really two, highly related, value streams present. The one most people focus on is the value stream of developing the software itself. But this should only be done in the context of the other value stream – that of the service the software is supporting. In other words, software supports another service or action – always (or it is useless). In other words, development value streams create or modify operational value streams. We must remember this.
One way to understand this is to relate a conversation I had during one of my Lean-Agile Transition Workshops last year. The group of directors/managers that were present had virtually no experience in Agile methods. When I talked about features one of them asked a great question: "Are we supposed to describe features needed in the software or features needed by the people using the software?" This was a great question because it illustrated the two value streams I just mentioned. Now I knew that they had been thinking in terms of the software they were writing. But I've learned it's always important to not make people wrong in their thinking so I didn't want to just say "you should do it the second way" (not to mention consultants/coaches should only rarely do this). So I said "Well, you can do it either way, but the second way works better because it focuses on the intent of what the user needs." Their response was "Well, we've been doing the first but I see we should be doing the second." I could see agreement throughout the room. Now, to be fair, it wasn't that I was in exceptional form that day as much as these folks had already been thinking about this. I just helped the thoughts they were already considering click.
Getting back to where I started – top-down or bottom-up? Well, both miss the point and both have implementation challenges anyway. Bottom-up focuses too much on the work. Top-down misses the how the work is done. It's easy to say you need a bottom-up and top-down implementation. But what does that really mean? Well, I prefer to say you want to speed delivery from start to finish ("concept to consumption"), that is, focus on shortening the time to market (an old concept, by the way) by removing delays in the process.
This takes four things: 1) selecting the right work to focus on (business stakeholders), 2) having teams work efficiently (teams), 3) discovering the best way to coordinate the work to be done with the people doing the work, and 4) having managers create the organizational structure that allows all of this to happen by creating visibility, removing impediments to flow and challenging teams that engaged in improving their process.
To accomplish this requires all people throughout the value stream to align on a common goal - adding value to the customer in the context of the business quickly by removing delays. The role of the doers is to do – and they get to figure out how to do that. But business stakeholders pick what to build. And management, sometimes considered a pariah in Agile, has the critical role of creating the context within which all of this works – both getting the effective method of relating the right people to the right projects and ensuring the proper methods of coordinating these teams when necessary is achieved
At Net Objectives, our primary business is transitioning organizations to effective software development to support the needs of the business and their customers. We've done this with dozens of companies and have seen several patterns amongst them. One is is that only some of the time (25% or so) is the team the main bottleneck. It is just as often the business not selecting the right things to work on, improper product portfolio management or a bad inter-team process that fails to manage dependencies (both business and technical). BTW: I've always thought this 25 per cent to be an interesting non-coincidence to be the per cent of times that businesses get the value they expect from Scrum
The point is there is no right place to start every time. You've got to look to see what your challenges are. Sometimes it's at the business, sometimes with product portfolio management, sometimes with the way teams are formed, sometimes it's with the teams themselves. You need to see your problem and get everyone aligned to solve it. Now, if you can't get management buy-in, starting from the bottom-up is not a bad way to go (because it may be the only way to go). But don't kid yourself into thinking it is ideal. Ironically, I've seen just as many times when it was the management that wanted to go Agile and they could not convince the developers it was a good idea. The common objection from the team was that they couldn't build something if they didn't know all they needed to know. Not to mention that the architecture was going to be a disaster if they kept changing requirements. Of course, sometimes teams don't want to try Agile methods because they are afraid of what management will say if they make mistakes. It's not an easy path.
What started the idea for this blog is an interesting anecdote that illustrates it's not always clear who is seeing the right path and that one should never assume developers have the right insights (it is equally important not to assume this for business stakeholders or management). Anyway, I continually hear about Scrum teams getting interrupted by management in the middle of a sprint (a violation of the sprint commitment). It is always assumed that the managers are just doing this out of ignorance or because of a political power play. I have never seen a Scrum team ask – "why is that they continually do this" as a true inquiry And, perhaps this is a result of the difference between taking a scientific approach which Lean does, and an "inspect and adapt" approach which Scrum does (and which I claim is not scientific because there is no model that is created and tested – see The Difference Between "Inspect and Adapt" and Plan-Do-Check-Act (PDCA) ).
I'll admit for years I rarely asked this myself. But when I started going beyond the team 7-8 years ago I started becoming aware of the developer centric thinking that is so common in the Agile community. When one uses the 5-whys method, however, one comes up with different reasons than the immediate, off the cuff answer, provides. One of the two common ones I've seen is the not surprising realization that management doesn't really understand their actions are hurting the team. Given, until very recently, one rarely heard Scrum teams talk about flow and managing work-in-progress, most managers figure a high need can be accomplished by just doing a little more work. However, a more interesting one became evident when a conversation with an executive revealed that he had recently become aware that some major accounts couldn't get their problems in front of the support teams (which were manned by the development teams). In other words, no one was really looking at the customers' challenges with the software because the teams had isolated themselves from the customer.
One of the mantras of Scrum, of course, is to remove impediments. But, ironically, the team thought the impediment was the interruption by the executive. The true, unseen impediment was poor communication between the teams and the customers. This was occurring because they were talking only to the product owner and he wasn't in the loop on the customer problems. The real irony is that I can see a just trained CSM refusing to be interrupted in the middle of a sprint to help a customer because that wouldn't be doing Scrum if they allowed that to happen - even though that's what they really should be doing – fixing a customer problem. Discussions in the retrospection would be more about executive interruption than the cause for it.
The point is, one can't assume that one side (developers or management) has it right. One must create a common goal and vision for all to see. If you can't do that, you're probably not going to succeed. Personally, my experience has led me to believe that a team-based framework does not seem to have the power to do this when there are serious impediments in an organization. This is because one gets locked into only one of three perspectives – development – that need to be considered. If Scrum's success rate was higher, I'd rethink my opinion. But it being about the percentage of time that the problem is at the team level makes me believe that we've got to learn to attend to all the perspectives present.
Be clear, I am not claiming Lean/Kanban is a silver bullet. I know of no Lean/Kanban thought leader who has ever claimed that it is. However, it does provide what I consider to be essential for all organizations with more than 30 developers or so. One issue to consider is what does one need to know to do enterprise agility. I'll talk more about this and some frequently misinterpretations of Lean/Kanban in an upcoming blog as well. It is clear to me that organizations must provide alignment across all levels of people (business, management, teams). Scrum expects them to figure this out. Lean/Kanban provides valuable insights that assist in doing this. Even if you are only able to start at the team, Lean/Kanban enables one to see the global context of their actions – right from the beginning.