As dedicated Agilists, our main focus is to help our clients understand the value that Agile methods can bring, then help them implement a successful transformation. Although this is reasonably straightforward in small organizations, planning for and implementing enterprise-level transformations is another matter. If for no other reason, large enterprises employ multiple vendors and consultants, not all of whom are on the same page. And large enterprises often have a strong history of Waterfall and all the controls that must be in place to govern it. These two factors frequently show up in more traditional cultures, which can be some of the most difficult to change to an Agile mindset.
In our work, we've found that many enterprise Agile transformations that we've been brought into were started with inadequate foundations on which to build real and sustainable improvement over time. For example, starting a transformation with a senior leadership announcement that we will all "go Agile!" without an implementation strategy or initial plan can create a fairly chaotic environment, as each unit interprets the direction in its own way. Building on an inadequate understanding of what Agile is — for example, concentrating on the way Agile is sold as a "speed demon" rather than on how it focuses on quality first — can offer a tempting panacea for the IT organization under delivery pressure. But quality may suffer with that incorrect focus. Starting Agile only in the IT organization with little engagement from business can perpetuate the current Waterfall paradigm of "handing our work over to IT, and they'll make it work without any involvement from us, only it will be better."
None of these approaches really works well and can fizzle over time. Although many of these issues can be dealt with at the team level, Agile implementation at scale, as with any paradigm-shifting change, takes thought, a clear direction, an approach that is implementable yet flexible, and determination at all organizational levels to see it through to completion.
However, once a decision is made, most organizations tend to "soldier on" and do their best to implement Agile. For the IT organization, that's relatively straightforward; for business, it's another matter. Old habits stick around longer than they're useful, and the tendency to shift the burden of product development, planning, risk management, and delivery is easily left to the IT shop. During these types of implementation, lots of questions come up, and by the time they're asked — often by external consultants hired to coach the teams — the die has been cast, and the focus on implementing and performing has replaced the focus on thinking and planning.
We've generated a partial list of questions that need to be asked ahead of time so that effective implementation planning can happen. To the extent that they're taken seriously, your implementation has a better chance than average of success. To the extent that they're ignored, or are asked too late in the cycle to shift the implementation, you run the risk of claiming that you're Agile when you're really not. Feel free to adopt and adapt these; it's not a perfect list. Delete those that are not useful, add your own, and find ways to ask them in a nonthreatening manner to organizational leaders at all levels.
Motivation: Why are we doing this?
Harvard Business School Professor John Kotter talks a lot about creating urgency for a transformation effort. While that's a key part of any change effort, keep in mind that urgency by itself is not enough. It's senior management's job to create urgency throughout the organization to counteract the built-in inertia all organizations have. However, senior leadership itself needs something much more important than urgency: determination. Determination, as we define it, is the unwavering intention to shoot for a goal and see it all the way through, even when we're in the middle of the implementation and it seems a little chaotic.
- What factors in your organization are driving your interest in Agile? Perhaps there's a problem or challenge that you want to address. What is it and how is it affecting you? How critical to your business is the need to address this problem or challenge?
- What strategic outcomes do you want from implementing Agile? How will you know that you've accomplished them?
- What evidence do you have that Agile would help your business be more effective or efficient? To what extent is the business committed to Agile transformation? How do you know?
- How does an Agile transformation tie in with your own objectives or strategic direction? What's in this for you personally?
- Given that an Agile transformation can take investment in funding, time, and organizational disruption until your organization adjusts to a new way of working, how determined are you and your company to see the implementation all the way through to completion?
Approach: How do we get there?
Let's look at the how
as a logical follow-on to the why
. These questions are roughly ordered from higher level to lower level, but that's not hard and fast. It's better to think about these as forming a tapestry of decisions that guide a set of integrated plans for shifting the organization to achieve its outcomes.
It's important to remember that few businesses can really "do it all; they just don't have the budget." So for each of these, it's useful to keep in mind two aspects of planning — "What do I want?" and "What can I afford?" — and balance the two as the plans unfold. We've done this successfully with leadership teams and senior implementation teams reporting to C-levels. Pursuing these at mid-level is not as likely to be productive, as the decision space becomes more limited further down the managerial chain.
That said, some organizations have cultures that allow for local independence, either by design or by oversight, and when you find yourself in a local situation in which there is strong leadership, some of these might be worth considering for discussion. We've worked with clients who decide globally on a target and overall implementation strategy (Questions 6–9 below) but expect local implementation planning, and these questions have been effective in those situations.
- How will you handle the rollout of your Agile transformation? Divisional? Pilot first, then expand? Targets of opportunity? Business value stream? Customer-facing applications first? Focus on programs, projects, or a mix of both?
- What interim target states for your Agile transformation would be appropriate for the first year? The second year? How realistic are those targets, given your current culture, investment budget, decision authority, political environment, and operating style?
- How will you pay for this Agile transformation in training and coaching services, technical and physical infrastructure investment, and Agile management tooling? Approved budget? Tax on current and future projects/programs?
- How will you handle the typical organizational changes needed to make the transformation successful, such as restructuring centralized functions (e.g., governance, testing, release, and deployment) that will need to become services?
- How will you engage your partners (business and technology) in implementing their accountabilities for Agile? Top-down? Peer-to-peer? Joint goal-setting?
- How will you ensure that the layers of management from the team to the top are prepared to develop and demonstrate Agile behaviors: Lean thinking and action, quick resolution of barriers to team, and program progress, etc.? Training? Coaching? Performance goal adjustments? Career development/role redefinition?
- How will you handle the shift in managerial roles that comes from managers learning how to behave as servant leaders? How will you adjust their job descriptions or performance goals when they move from a direct-and-control perspective to a facilitate-protect-and-guide perspective?
- How will you model the servant leadership that you want your management chain to adopt so that they have a stable and consistent reference point for their behavior?
- How will you adjust your current governance processes (e.g., funding committee and processes, enterprise project management office, program management office, change control board, technology committees, etc.) from Waterfall to Agile with respect to life cycle structure and gates, planning, reporting, metrics, regulatory, group and individual KPIs, target operating models, technical road maps, and other governance factors?
- How will you ensure that your performance system is adjusted to account for team versus individual accomplishment? Shared goals? Additional evaluation for teaming behavior? Role redefinition (e.g., team member for all disciplines, rather than designer, developer, or tester)?
- How will you communicate your goals, approach, and expected outcomes for the transformation? How frequently and by what vehicles? How will you get honest and direct feedback on how the transformation is going and the barriers (impediments) that the organization will encounter?
- How will you ensure direct two-way communication to foster the identification and resolution of implementation challenges?
- How will you sustain motivation and focus over the whole transformation life cycle? What interim measures will you take from business and from IT?
Evaluation: How will we know?
Many organizations use partial measures to determine implementation progress and outcomes from an Agile transformation. Some measure adoption rate, some "maturity" of teams, some feedback from business, some cycle time — and there are a host of others. What's important here is to determine two things: To what extent is Agile becoming a part of the fabric of our work (adoption rate and maturity) and to what extent is Agile useful to us (business return for customer-facing products, risk reduction for internal or regulatory products, value/cost for nearly internal investment)? To answer the last question, the business needs to be pretty clear about what its own product or project goals are and how it will value these.
While we talk about "delivering value" a lot, it's not often clear what that actually means to an individual project or business unit in practice, nor is it clear how to measure it. Further, many business units have never really measured their outputs before (few organizations actually determine their actual ROI on a new product against the business case promises). Nonetheless, these two questions must be asked:
- How will you measure the quality and extent to which Agile is being used here? Adoption rate? Maturity? Self-report or external evaluation? How will that information be used?
- How will you measure the value that Agile brings to the business or project? How will you measure defects delivered? Cycle time? Value delivered according to budget? Utility of the product delivered to the customer base? End-user satisfaction and product usage data?
As we mentioned, this not an exhaustive list of questions. However, we believe that if you can get clear answers to half or more of these questions, you'll be in a pretty good position to plan an effective implementation. That doesn't imply that things will be smooth, as they never are. But at least you'll have a fighting chance. So take these, try them out, and practice our old inspect-and-adapt principles. Let us know how these questions work for you in transforming your business to a more Agile organization.