So, you want your organization to adopt Agile practices? All right, let’s do this! It takes just two steps… Step 1: Emphasize Better Results, Not Becoming Agile Agile development is a means to an end; it is not the point of your transformation. Your organization is transforming to cut the lead-time for software delivery, or […]
So, you want your organization to adopt Agile practices? All right, let’s do this! It takes just two steps…
Agile development is a means to an end; it is not the point of your transformation. Your organization is transforming to cut the lead-time for software delivery, or reliably deliver high-quality software on a deadline. And in actuality, even these two are only a means to an end in terms of business performance, whether it is being able to make more sales, improve customer satisfaction, increase data collection quality, or some other business reason. Improved outcomes are the purpose of an Agile transformation and you should clearly repeat that message at every opportunity.
Emphasizing the benefits is the only way to motivate people to commit to the transformation; it anchors them to a higher purpose. Your organization will have difficulty making the necessary changes. Executives must lead the change. Even when people agree they want the change, senior management will have to nudge them outside their comfort zone to make progress. People will worry they are losing control of their work or that their job is disappearing entirely. They’ll resist adopting behaviors they don’t understand; they’ll do what they always did but use agile jargon to describe it. If you let them get the idea that “becoming Agile” is the point, they’ll argue over the definition of “Agile” and your transformation will devolve into a compliance exercise.
Organizations introduce Agile approaches to achieve the following benefits:
Pick one, or two, at most three to focus on initially. Use it to name your transformation, for example, “Superior Value & Quality Transformation.” Agile approaches are just your path to those goals.
Beyond selecting your focus, set a quantitative or objective goal. Tom Gilb (Principles of Software Engineering Management) has long recommended establishing the following in each performance area:
Although the above is the ideal, at a minimum you must explicitly articulate your improvement priorities and specify how an improved situation would look. All the stakeholders need to understand what they are trying to accomplish and its importance. Gain broad buy-in by having representatives across the organization collectively set performance context and targets. Revisit these on a cadence to ensure they are still pertinent and make adjustments as needed; this cadence can be relatively long – quarterly, semi-annually – as dictated by your environment.
Now that you have identified compelling goals to achieve, you need to make incremental progress toward them, iteratively! This step is actually a plan-do-check-act cycle, with each cycle an incremental step toward your improvement goals (or a step in learning what doesn’t work for you). Organizational improvement increments should be short, perhaps not as short as the 2-week cadence of development teams, but no longer than 4 weeks. Longer than that, and you’ll lose momentum.
You’ll want a cross-functional leadership team guiding the improvement program, representing all the key areas of the organization. Some improvements may begin as a trial in a single development team, but most will demand negotiation and collaboration across multiple teams and functional groups. Some improvements will rest outside of teams in your management, how your organizational structure is designed, or in related business functions.
You may protest that this last step is a cheat because it is actually a lot of steps. However, there is no generic plan that will work for everyone. What incremental steps you take depend on your goals, your circumstances, and what kind of results you obtain from each step. However, we can give you examples of reasonable performance targets and a few incremental goals toward accomplishing those targets:
Incremental organizational goals can also be more indirect. They can enable better measurement of performance, map value streams to make problems visible, change budgeting practices to give visibility to cost-benefit of alternatives, or almost anything that has objective success criteria and contributes meaningfully to achieving your performance targets.
Just two simple steps to obtain the benefits of being Agile; albeit as with most things Agile, these steps are “simple to understand, but not easy to do.” Granted, you’ll have to repeat the second step quite a few times. In fact, it never stops—more improvement is always possible.
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...