I hear a lot about Scaling Agile these days. Every time I hear it I have to shake my head. The fact that people are asking how to scale Agile means that they don’t know how to do Agile. The fact that people are designing frameworks for scaling Agile means that they don’t know how to do Agile either. Agile done right (beyond the 1-star level) consists of two steps:
- Change the rules of the game (by changing the details of how software is created moment-by-moment).
- Adapt everything else to take advantage of the new reality.
This is why when you ask “how do I scale Agile?” to someone who can ship at will, they look at you with a blank stare. If you’re thinking about “scaling Agile,” then you probably haven’t really benefitted from your agile implementation. If you had, then the question wouldn’t make sense to you either. You would just scale your business in a few obvious ways, look around, and repeat.
There isn’t a special method to scale Agile. The team just does whatever it was doing before, only it stops doing whichever parts it doesn’t need anymore.
The alternative to scaling
I am cheating a bit. When I say Agile, I really mean 2-star Agile. Therefore my argument only applies to Agile software companies who are intending to keep their software for more than 3 weeks. If we are discussing an Agile team that does not build software, or one that intentionally throws away 100% of its code every 3 weeks (like, say, a game developer for mobile phones often does), then my argument doesn’t apply. 1-star may work best for those teams and they may have to scale it.
For everyone else, there is a better way: become competent at shipping software.
Not that this will be easy. Competence is a pretty high bar these days. There are a ton of companies and open source projects out there that write one bug once every 100 developer-days or so. Most of these bugs are found within an hour or two of being written. These teams can go as much as 1000 developer-days between bugs that actually make it even as far as testing.
That is basic competence. It used to be excellence, but now lots of people are doing it. It’s so common that there’s a formula for it and everything. We spend some effort, we run the formula, and we will get that bug rate. It takes about 2 months to see initial results and 2 years before we get to 1 bug per 100 dev-days, but we get there. And we see progress and return on investment the whole time.
The heart of Agile
In my mind, Agile is simple (but not easy). Work tiny. Prove it. Get done. Learn constantly. Work together. Tech first. This is all about focusing on the details, not the big ideas. This isn’t values and principles. This is simply doing every detail well.
It is a practical approach: we will drive the risk and cost out of every transaction (code commit cycle, design change, response to requirement change, …). As we drive out the costs, we make each cycle tinier (smaller in scope and in duration). This identifies more transaction risks and more transaction costs. We kill those and iterate.
After a while, we are operating with almost 0 risk and almost 0 transactional cost for each thing we do.
At that point, we just do the obvious thing. We have mastered shipping software. We have driven the technical risk out of our efforts. We have driven the technical overhead costs our of our efforts. We are left with the direct costs for the tech and the risk that we might be building the wrong thing. And that’s it.
In addition to not worrying about bugs, these teams typically have the following characteristics (as in, these traits are pretty common teams that do the Adaptive Engineering practices and have talked to me. See also Embedded Agile Project by the Numbers with Newbies):
- Code changes cost the same whether they are in line with the current design or require a design change. The additional cost of changing the design is 0.
- There are no technical dependencies; each item can be done in any order, without there being a lump cost for whichever one goes first.
- A change in requirements or direction incurs no overhead cost. It may invalidate completed features (no longer needed for the product), but it does not invalidate partial work or change estimates for non-started work.
- There is little technical risk or variance in stories. If two stories are estimated to be the same size, they take the same amount of time to finish, regardless of which parts of the product they touch (like within 5%).
Building on this foundation
Once the details of writing software are right, the rest of Agile comes as an obvious case of following your nose.
Take planning as an example. It really doesn’t matter, at all, how a team does planning. (I know I’ll be stoned for this one.)
Assume you can ship software whenever you want. Assume that when you estimate how long something will take to build, there is no technical variance in that estimate. Assume there are no technical dependencies between things, so you can freely change the order of your features and it will not affect the cost of any feature. Assume there are no “platform” costs that will be assigned to the first story to do X.
These assumptions hold (nearly) true for teams that master the art of delivering software. These costs and interactions are small enough that the optimal strategy is generally to ignore them. This has been achieved many times, by many teams, in many industries, and in many sizes of companies.
Given those assumptions, how do you plan? You plan however the hell you want to plan.
If you have a lot of partner teams and need to coordinate your efforts, then Waterfall is the best planning methodology out there for you. Use it.
If you need to make projections for marketing (or others) but want to reserve some of your capacity for responding to changing market needs, then iterative planning (like Scrum) is the best planning methodology out there for you. Use it.
If you want to run tons of experiments and adapt immediately to what you learn or if you can’t predict what you will do from day to day (professional services or IT are often in this situation), then a continuous-form planning methodology (like Kanban / Naked Planning) is best for you. Use it.
If you are delivering on fixed-bid contracts and want to make sure that you can get feedback from the customers at the right times and always both get paid and make them happy, then Spiral is best for you. Use it.
All of these are Agile methodologies (including Waterfall). The Agile part was in making software be a low-risk endeavor. The particular way a team chooses to do planning is just a local specialization to match the context.
The point is that the planning approach is irrelevant. It is the tail, not the dog. First we change the rules of the game—we remove all the arbitrary technical constraints on planning. Then we leverage our new circumstances.
And that brings us to scaling
So how do I recommend scaling Agile?
Well, assuming you master shipping software, then you scale the business. You won’t find answers to scaling Agile in some book. You certainly won’t find them in any framework (there are several out there. All assume a similar level of incompetence at delivering software. All are irrelevant if you lack that incompetence). About the best guide that I’ve found is “seek level 3 on the Agile Fluency path.” This works because it isn’t a set of prescriptive guidance. It is just an indicator of which problems are most worth solving.
There won’t be technical dependencies between your teams. Each team will be able to deliver value to the customer. Teams won’t cause problems when they integrate code with each other. None of the products will have bugs (well, not for more than about an hour out of every 2 weeks). Teams can work together in order to provide solutions that enhance each other. Teams can also deliver business value without coordinating with any other team. You only really have one open problem:
What does my business need?
- How can I get that without sacrificing my ability to ship?
- How can I maintain transparency when no one can know the entire business?
- How can I decentralize decisions to avoid blocking on “the geniuses who make the decisions?”
- How can I keep the right degree of alignment (not so much that I lose my ability to experiment; not so little that I fail to deliver anything good)?
- What do my customers want out of my business anyway?
- What does my business do that pisses my customers off?
- How can I satisfy shareholders without allowing them to destroy my business (a business which, in general, they know basically nothing about)?
- How can I gain information about my customers in the process of doing business with them?
These are not Agile software development questions. They are not process questions. They are business culture questions.
In the end, there are no constraints. You can choose to scale by simply delivering separate pieces of software, each on its own cadence (something like Amazon’s marketplace of services without their remixing). You can choose to do better than that when it is to your advantage.
Often the best approach is to simply take whatever you were doing to scale your previous software efforts and ask what you can delete, now that you no longer have to worry about bugs, integrations, technical dependencies, or other hogwash. Worst case, you do everything that you used to do and no more. This will deliver better results than your previous process, because you will still be set up to deal with all the technical complexity but that complexity will simply never arise. Best case, the team can drop the parts of the process that only existed to work around problems caused by its own software development.
In other words, you can follow your nose. Do the easy, obvious thing if you have no reason to do more. If you do, then do more.
Picking a fight with thought leaders
There are sets of 10 partner teams that are each fluent at the 2-star level. I challenge anyone to find me such a set that needs a complex framework to coordinate their efforts. A lot of effort to figure out what their customers really want? Sure. But not to coordinate their efforts.
In the end, anyone building a process or framework for scaling Agile doesn’t know Agile. Period. Full stop. Go learn to ship software at will without any risk of defect, and you will discover you no longer need your framework.
Oh, and if you want to know the formula to ship software without risk, just ask. Better yet, read a good XP book (I recommend James Shore & Shane Warden: The Art of Agile Development) and go to a Code Retreat. You’ll be working in that style by the end of the day. Bring it back to your daily work and you’ll see obvious results by the end of the quarter.