One of the claims that we make in the Disciplined Agile Delivery (DAD) book is that DAD provides a solid foundation from which to scale agile. In this blog posting I thought I would expand upon that idea.
Figure 1 overviews the basic strategy that I led the development of when I was with IBM Rational. The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We felt that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together. This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.
Figure 1: DAD provides a foundation for agility at scale.
First, let’s examine how the DAD framework provides a better foundation for scaling agile:
- Risk and value driven lifecycle. Scrum has what is called a value driven lifecycle. Work is prioritized by value to the business and is performed in priority order. This is a pretty good approach, but it’s possible to do better. Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early. A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.
- Self organization with effective governance. There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy. But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem. Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.
- Delivery of consumable solutions over construction of working software. There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus. First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project. DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project. The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach. Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle. Second, agile teams do far more than produce software. We create supporting documentation. The software runs on hardware that may need to be upgraded and/or redeployed. We potentially change the business process around the usage of the system we’re producing. We may even affect changes to the organization structure of the people using the system. In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”. Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want. What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals. The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.
- Enterprise awareness over team awareness. I alluded to this in point #2. Disciplined agile teams recognize that they work in a larger organizational ecosystem. This enterprise awareness motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization. Done right this increases a team’s ability to deliver.
- Context-sensitive and goal driven over prescriptive. One process size does not fit all. It’s comfortable to think that prescriptive strategies such as managing changing requirements in the form of a product backlog, holding a daily meeting where everyone answers three questions, having a single source of requirements and thereby a neck to wring, and other ideas will get the job done. But we all know that this isn’t true. There are many strategies for managing requirements change, there are different ways to coordinate within a team, there are different ways to explore stakeholder needs, and so on. Each of these strategies has advantages and disadvantages and each has a range of situations where they are appropriate. A strategy that works for a small co-located team will put a large geographically distributed team at risk. A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship). So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in. DAD describes a straightforward, easy to consume strategy that is goal-driven. This strategy has a visual component, the goals diagrams which summarize the fundamental process decision points, and a textual component (goals tables) which capture the details.
Now let’s examine what it means to scale agile. When many people hear “scaling” they often think about large teams that may be geographically distributed in some way. This clearly happens, and people are clearly succeeding at applying agile in these sorts of situations (see some of the more recent evidence I’ve gathered that agile scales, as well as some of the older evidence), but there’s often more to scaling than this. Organizations are also applying agile in compliance situations, either regulatory compliance that is imposed upon them or self selected compliance (such as CMMI and ISO). They are also applying agile in a range of problem and solution complexities, and even when multiple organizations are involved (as in outsourcing). As Figure 1 indicates, there are several scaling factors which you need to consider when tailoring your agile strategy.
So how does DAD provide a foundation from which to scale agile? When one considers how scaling factors can potentially affect your strategy it becomes a lot clearer. Consider some examples:
- Geographic distribution. When a team is geographically distributed they will likely need to to a bit more requirements envisioning up front (but not too much more), a bit more architecture envisioning up front (but not too much more), a bit more release planning up front (but not too much more), and so on. In other words you clearly need to tailor your inception efforts. The way the team coordinates will change (your 15 minute stand up meeting becomes one or more conference calls), the way that you coordinate requirements changes (you’re likely to have several product owners that need to negotiate dependencies), and the way that you coordinate architectural issues changes (your architecture owners will need to coordinate somehow). In short, you need strategies that are a bit more sophisticated than having a discussion standing up around a whiteboard with some sticky notes on it. By the way, I’ve found in several surveys over the years that the majority of agile teams are geographically distributed in some way.
- Compliance. A few years ago I worked with an agile team that was working on FDA-compliant software. Because of the need to be FDA compliant, they were working on a key software component of a life-critical solution, their approach to documentation, reviews, and testing was a bit more sophisticated than what you would find in a non-compliancy situation. They needed a defined process (an early version of DAD) that met the documentation and quality constraints of FDA regulations. This meant more documentation than most agile teams would normally create, more formal reviews, the inclusion of an independent test team on top of their whole team testing efforts, and documented proof thereof. The point is that they were still doing documentation, reviews, and testing (amongst other activities) but doing so in a different way than if they didn’t need to be compliant.
- Technical complexity. As technical complexity rises the sophistication of the techniques, and sometimes the tooling, needed to deal with that complexity increases. For example, if you’re building a brand new, stand alone application your team is in a position to write clean code, create a clean UI, and create clean data storage that is fully tested from the outset. If you’re working with a legacy system the code… may not be so clean. It may not have a full regression test suite (making continuous integration challenging). You may need to fix these assets, thereby requiring a more sophisticated approach to refactoring, testing, debugging, and so on than what you’re used to. Once again, this scaling factor will affect your strategy.
The good news is that there is a growing collection of techniques for scaling agile projects. This includes Dean Leffingwell’s Scaled Agile Framework (SAFe) as well as the continuing writings of Craig Larman and Bas Vodde. In future blog postings we’ll discuss the scaling factors in greater detail as well as how DAD and SAFe fit together.