Applying Agile Practices in Enterprises Outside Development
Benefits can be gained when agile practices are used in the whole enterprise. In several recent blog posts, the possibilities to use agile outside development are explored. Jake Sorofman from Gartner wrote about is agile the last remaining competitive advantage?, where he signals a trend that he sees on agile usage in enterprises:
We all know that this philosophy has transformed software development practices. What we’re now beginning to know that agile practices are creeping into other aspects of business.
Earlier InfoQ reported how agile practices are used in enterprises for marketing (agile marketers create an agile marketing manifesto at SprintZero) and sales (sales and agile, oil and water?). It is becoming clear that agile can give benefits in enterprises for activities beyond software development, as Jake explains:
(…) agile practices are simply our response to the changing nature of everything. It helps address the reality that everything moves fast, the truth is often opaque and, in business, while we can afford to get small things wrong, we need to get the big things right. In fact, in agile, getting the small things wrong often enables us to the big things right.
He shows how lean startup and agile come together, by focusing on continuously delivering value for customers:
In the world of new business incubation, we talk about the “minimum viable product,” which defines the smallest increment of value you can deliver—as a probe for homing in on the truth. And this leads me, mercifully, to my final point: It’s the broad application of agile that is leading to a minimum value life.
In the blog post enterprise agile: extending the agile process outside development CTO Johan den Haan from Mendix shares his ideas about adopting agile practices in the whole enterprise. He starts by explaining what makes agile adoption different for an enterprise:
Agility is only possible when the whole organization adopts the mindset: in an agile enterprise the marketing and sales side of the organization is balanced with product development. In an agile enterprise the entire business is organized in a way that it can respond quickly to changes in the market. All departments are fully integrated with the overall value stream, there is end-to-end agility.
He describes what the value of agile practices can be for marketing:
Frequent releases in a steady cadence make it easier for marketing to create their own cadence in messaging, but even more important, it brings value to users as soon as possible.
Agile software development makes it possible to deliver frequently. To get feedback on these deliveries, Johan proposes that services should also adopts agile practices:
(…) services should be involved early-on in the process too. Make sure you listen to their feedback on the product, involve them in early iteration / sprint meetings, and give them the opportunity to start acting on new releases before you actually release.
Johan concludes his blog post by describing how you can adopt agile in the enterprise:
Approach it in an agile way! Do not start top-down by creating policies, etc. Start with one team, as soon as you have multiple teams "doing" agile you probably need something to coordinate among teams. At this point you probably want to start with Scrum of Scrums meetings. If your development process within your team is agile, start to widen your definition-of-done. Involve other departments one-by-one and make sure upper management is supporting the move to an overall agile value stream.
In introducing agile techniques to teams outside software development, author and agile coach Rachel Davies shares her experience with applying agile practices outside development:
Our company was founded using XP at the core of our approach to software development. We've grown along with the success of our products and now have several departments with day-to-day work that does not involve the Development team (such as Finance, Infrastructure, and "People & Places" who combine HR and facilities management) interested in managing their work along similar lines.
She describes how she introduces agile to teams that are not developing software:
Rather than blasting these teams with Agile theory and principles, we're building things up slowly. We start with a simple sketch about how to make the work for the week visible on the wall then put it together using super-sticky notes (…) Around the board, we run a simple meeting cycle: surfacing and prioritising work for the week ahead, daily standups and monthly retrospectives.
Rachel did an open jam discussion at Agile2012. From that discussion she compiled a list of things that you can do to start a conversation about using agile:
- Explaining the value over beer or coffee
- Introducing facilitation as a way to make meetings more fun
- Executive evangelists
- Arranging a tour of software development teams using Agile
- Finding one open and curious person
- Organising a team reliance - involving all hands as supporters
- Making an Agile coach available to teams outside Development
- Crafting an interesting elevator pitch
- Create interest with cool looking stuff