Enterprise Agile: extending the agile process outside development

I previously wrote about Enterprise Agile, not because I just want to put the “enterprise” moniker in front of everything, but because I think there are some fundamental challenges in moving to agile software development practices within enterprises, as opposed to startups.

This follow-up post is triggered by the following comment on my previous article about this subject:

Where we are struggling as an organization is the whole enterprise adopting agile. Sales and marketing expect each release to have a “big splash”. Services hates the rapid iterations since they have a waterfall mindset where you accept a new release every 6 months and spent time chewing on it. I would love some pointers on resources that help move these parts of the value chain to agile. Almost everything I’ve read focuses on Engineering and Product management and I need to think broader.

I think this is recognizable for a lot of people. I would like to share my recent musing about this subject as I am struggling with the same kind of challenges within a fast growing company.

Why “Enterprise” Agile?

Being part of a fast growing company starting with a couple of guys in one room to being an international company of more than 125 people has taught me that there is a difference between an agile team in a start-up (or even a bigger company), working in some sort of vacuum, and an agile team operating within the broader context of a bigger company. I think you can imagine what the difference can be with a big enterprise.

What’s so different?

• Solutions need to be fit in an existing ecosystem: the definition of done needs to include compliance, data security, data ownership, and integration with existing systems.
• Multiple teams work towards a common goal: there needs to be alignment with (so-called) enterprise disciplines such as portfolio management, enterprise architecture, and strategic reuse.
• 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.

Isn’t “Enterprise Agile” moving away from the core principles of Agile?

You mean, does it deteriorate into following the Manifesto for Half-Arsed Agile Software Development? That’s a fair question. It is definitely easy to end-up with something that’s quite different from the core ideas of agile. However, enterprise agile as I see it is not doing that by definition. It is an awareness within development teams for the bigger picture and alignment with enterprise requirements. It is also a mindset change within the whole company as every department within a product company will be affected when product development needs to become “agile”. It is not bending the agile principles to be able to say “we’re doing agile” and at the same time trying to keep all existing processes in place.

What does Enterprise Agile mean for development?

If you want to extend the agile process outside the development processes, do start by looking at the development processes themselves first. Are they indeed agile? Agile development / releases are only possible with the right infrastructure in place. Think automated testing, incremental changes, agile architecture, automated deployments, focused and autonomous teams, a different (project) management approach, etc. The next step would be to connect the development value stream with “external” elements like business goals, strategy, portfolio management, architecture, training, marketing, sales, services, etc. Let’s look at some of the mentioned departments to see how creating an overall agile value stream would affect them.

What does Enterprise Agile mean for marketing?

The first thing to do is to make sure marketing understands the value of small, incremental releases. 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. But what if big yearly announcements or events are needed to attract the right press attendance? Well, incremental releases do not forbid that. You can still organize yearly events, issue big press releases, etc. In most cases the group of people being happy with the incremental releases (i.e. your users) are not the main group you target with your press releases.

The second thing to do is to make sure marketing isn’t seen as adding some sauce to the cool stuff engineering did come up with. Ideally software development is aimed at working on a set of marketable features. Marketing should be involved in the process even before development starts. Start the process of adding new features by writing the press release first as well as the FAQ. This really helps in defining the minimal set of technology needed to implement the feature. It also helps to integrate development and marketing in one agile process, and to make sure sending a new product release “through marketing” isn’t slowing down the process, but just a step in finalizing the things that already have been started.

What does Enterprise Agile mean for services?

There are of course quite some similarities with the previous section about marketing. We should again look at awareness for agile within services and involving services in the overall product development process. The comment quoted in the introduction of this article states that services hate rapid iterations. I think they often have good reasons to do so. If each new release leads to a lot of early problems and invokes a process to re-design the way-of-working and how support is done I wouldn’t like frequent releases either. That’s why I started above by saying that agile development is only possible with the right infrastructure in place. Agile development is not possible if a release can only be used in production after multiple patches spread over a long period. Services should have the trust and confidence to switch to new releases quickly, you have to earn that.

Additionally, 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. If you work backwards from the press release and user experience to actually starting development (see also previous section about marketing), make sure to involve services to cover aspects like methodology (i.e. way-of-working) and support related stuff. If you issue quality releases including features valuable for your users (and thus services) I am sure services will like frequent releases as much as you do.

How to start?

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.

Share your experiences!

There is a lot more to say about this subject. What is the impact on other departments? What are the requirements from a management and company strategy perspective? I will maybe address these kind of questions in a future article. This article is based on my personal ramblings, not a scientifically tested approach. Please enlighten me by sharing your experiences / thoughts in the comments!

Photo by Matija Grguric