For anyone who has been following the Agile movement, it is no surprise that Agile has grown far beyond its roots in software development to encompass business processes of all sorts.
McKinsey consulting has a step-by-step guide for Agile Marketing. Leading Agile trainer Steve Denning talks about Agile for Human Resources in Forbes. And a growing segment of respondents to the annual State of Agile survey come from outside of technology teams.
More recently, Harvard Business Review featured Enterprise Agile as its cover story, Agile at Scale. Its lead-off concept?
“Agile teams, when implemented correctly, almost always result in higher team productivity and morale, faster time to market, better quality, and lower risk than traditional approaches can achieve.”
There is a lot to unpack in that sentence alone, but the benefits are enticing. And they are consistent with the findings of the State of Agile survey I mentioned above, where reported benefits include:
- Faster delivery
- Enhanced ability to manage changing priorities
- Improved business alignment
- Increased quality
- More predictable delivery timeframes
- Better project visibility
- Reduced project risk
- Increased team morale
But the HBR article makes it clear that those benefits don’t always come easy. For one, notice the qualifying opening to the above quote: “When implemented correctly…” As Agile’s popularity grows, so do its detractors. I won’t dive into them here, but in my opinion a lot of examples of failed Agile implementations come from organizations that are too focused on a dogmatic approach to “doing” Agile instead of understanding the philosophies & concepts necessary for “being” Agile.
Other important factors from the HBR article? The need for flatter organizations, or less of a command-and-control environment. (For an in-depth read on that topic, see the excellent book Wiki Management by Rod Collins). The need for new-to-Agile organizations to start small in order to build up their capabilities and develop their own cadence. And the need to develop a common language to describe the sorts of improvements the organization hopes to make.
And, of course, there is the need to set a proper mission and goals before embarking on any change effort.
As someone who has been beating the “Agile for Legal” drum longer than most, it is great to see real-world examples of Agile methods in different types of organizations.
To learn more, read the HBR Article for yourself.