The problems with agile at scale

- Many organizations are used to working in a waterfall paradigm where they begin by creating large programs of work, going through the budgeting process, doing a great deal of analysis and estimation, and when they're finished with that, then going into the development phase. Once development is complete on a release, we take that work and we go through integration, centralized testing, and then once that is finished, we then go into production, throw the whole thing over the wall into IT operations. Taking that paradigm and moving it to Agile is difficult and complex, and often many organizations don't go the whole way in transforming the way they manage programs. Instead, what we often see is a paradigm that we like to call water scrum fall. In this paradigm, we transform the central part which is the development process and we start working in iterations, with small teams, building stuff, and testing, and analyzing in process, but we're still book-ended by these two big phases. The initial fuzzy front end, the budgeting and estimation process, and we still have that piece at the end, the integration, and testing, and release process. Often, these front end, fuzzy front end and back end integration and testing processes consume a large proportion of the cycle time. We need to think completely differently about this paradigm and transform the whole value stream, not just development. We're gonna spend most of this module discussing the fuzzy front end, the piece at the beginning of the delivery cycle. There's a lot of work that goes into this. The budgeting process typically only happens once a year, sometimes twice a year, and a great deal of work and preparation goes into that budgeting process in deciding which programs we're going to invest in, which ones we're not gonna invest in, fighting over how much money we're gonna spend on them and what we expect the return to be, but typically that process is not very effective. In a survey that we did with ThoughtWorks and Forrester, we asked a number of executives in big companies how they made investment decisions and the results were pretty sobering. What we found is that in 47% of those organizations, committees decide from the potential options. In 24% of those organizations, there is some form of economic modeling that happens. In 13% of organizations, people said that the opinion of the person with the highest salary wins out. This is called the HIPPO method and actually we put that answer in for a joke, but 13% of the executives said that was how they made investment decisions in products. The dirty secret is that decision by committee is basically the same thing. We found that 9% of respondents said they used a product portfolio approach which is effectively decision by committee and then 7% said they use no systematic approach. If we wanna summarize these results, what we can say is that 24% of people used some kind of economic model to make their investment decision and 76% of people didn't. This is pretty depressing, but unfortunately I think representative of what we see in many organizations today. All that work that goes into deciding what we should invest in and what we shouldn't invest in, most of that work is estimating costs. Working out how much money we're gonna spend on building these products. One of my favorite authors talking about this kind of work is Douglas Hubbard. He wrote an amazing book called, How to Measure Anything. In an article for CIO Magazine, he reports that, "Even in projects with very uncertain development costs, "we haven't found that these costs "have a significant information value "for the investment decision. "The single most important unknown is "whether the project will be canceled. "The next most important variable is the utilization "of the system including how quickly the system rolls out "and whether some people will use it at all." These are not variables that we typically spend a lot of time measuring and yet they're the most important ones. Will the project be canceled? Will it be used? How quickly will it be used? We should be spending our time focusing on those questions, not the question of cost. Yet, typically cost is where we spend most of our time. This is a big problem. The other problem for the typical product investment decision process is that we tend to batch up work into very big projects and this is done for a few reasons. Partly because it's so expensive to get anything done, it makes economic sense to batch up work into these large projects. Secondly, this is normally the way that we run the budget process. We invest in large projects, because that's the program or project management process that most people are used to working in large organizations. However, there are many problems with the project management process. Perhaps the biggest one is that we tend to batch up work into these huge projects by combining a lot of high-value features with very low-value features, and you deliver all of them at the same time and effectively with the same priority because you delivered them all in one-go. There was a study done by Maersk Shipping on the requirements in their IT group published in a paper called, Black Swan Farming, which is an excellent paper. I highly recommend reading. In this study, the team was doing an IT transformation. There was a huge backlog of thousands of requirements that the team looked at and they wanted to prioritize those requirements. They used a technique called cost of delay, which we'll talk about in the module on economic modeling. Cost of delay, very briefly, looks at the opportunity costs of not building those features and how much it's costing you to not build those features per unit time, say, per week. By looking at how much you're losing by not building those features, you can prioritize the features. The team sat in a room for a few days and looked at all those thousands of requirements and worked out the cost of delay of not building them. What they found, as shown on this graph, is that there was a very small number of features, about three features, that had a cost of delay above one billion dollars per week. Then, there was a really long tail of features that delivered a cost of delay much, much lower than that. All those features were gonna be delivered in big batches in projects. When you see this graph, it becomes very clear what you should do. What you should be doing is not building all those low-value features, but instead building the three, very high-value features and prioritizing that and getting your entire team to work on that as a matter of priority and releasing them as quickly as possible. This distribution, which is a power distribution, is very typical when you look at projects to see this kind of distribution of features. If you're delivering all these features in big batches, that's a really big problem. What happens is you try and prioritize within those projects and nothing happens. We see this in big enterprises all the time. Some project will try and get some of their stuff expedited and they'll ask the teams they're waiting for, please expedite this stuff, please expedite this stuff. Then, the teams who are serving these project teams, maybe teams doing networking, or storage, or other IT operation stuff, they just have a big queue of stuff and someone comes along and tells them to expedite something. Well, you expedite one thing, you have to drop something else on the floor. So, some other project gets slowed down and then their project manager comes and says, please expedite our stuff and then our stuff gets slowed down. The outcome of this is that everyone moves at the same glacial pace. You need to create transparency into the high-value work across the whole organization and everyone needs to know what that is. That's the only way to make sure that you can get the high-value stuff done quickly and not worry about the low-value stuff. The project paradigm completely obscures this and makes it very difficult to prioritize and get anything done, which is why everything moves so slowly in big enterprises. To summarize the problems with the waterfall paradigm and even Agile paradigms, where we haven't transformed the entire value stream, but have focused only on development. Number one, we tend to place a lot of focus on managing cost instead of thinking about value and the value we're gonna deliver to our customers and our organization. Number two, we're not making our investment decisions using economic models. Instead, we're using decision by committee and the highest paid person's opinion. Number three, we're batching work up into these huge projects. There's no effective prioritization of the high-value work. Everything moves at the same glacial pace. Number four, our feedback loops are too slow. If you're building stuff in the project paradigm, everything gets delivered at the end, you try and work out which of those features actually delivered value to your customers, it's impossible to do that. You've got a big batch of stuff. There's no way then to go back on it and say which features actually delivered the value we were expecting and which ones didn't. We wanna be able to get that feedback in a much more fine grained way. Fifth, we completely waste the creative potential of our people. If all the requirements are decided up-front and the development teams have no ability to change what they're working on and experiment with new ideas based on actual customer feedback, then those people are basically just building stuff that they've been told to build. The only people with creative impact in your organization are the people building the requirements and the executives. That's a massive waste of human potential.