Enterprise Agile: 3 characteristics

No, this is not a typo… I really mean Enterprise Agile, not the subject of some of my previous articles about Agile Enterprises. I hear you sigh: do you really need to put the enterprise moniker in front of everything? Although this is a fair question I think enterprise agile is not just a buzz word. Agile on a bigger scale, in a big enterprise, is different from agile in a small isolated team. I do not care if you call it enterprise agile, enterprise-class agile, agile at scale, or something else. My point is: there is a difference between an agile team in a start-up (or enterprise!), working in some sort of vacuum, and an agile team operating within the broader context of an enterprise. Let’s look at some characteristics to make the difference more clear.

Solutions need to be fit in an existing ecosystem

There is quite a difference between building a standalone piece of software and software which needs to fit in an existing application landscape. The latter asks you to spend time on analyzing the existing systems and testing the integrations. You will have to address the inter-dependencies of applications and data.

There is also quite a difference between building applications for consumers or small organizations and enterprises. Enterprise requirements like data ownership, data security, and all kinds of compliance rules need to be taken into account. Yes, there are successful examples of tools like Yammer and DropBox with a main focus on simplicity, but as their popularity within enterprises is growing they pay more and more attention to enterprise requirements. They can stay simple and focused, but they have to pay attention to, for example, compliance and security. This means you need to spend time on these items, you need to widen your definition of done to say it in agile terms.

Multiple teams work towards a common goal

Creating software within the broader context of an enterprise also means you are just creating parts of the software landscape. Multiple teams are working in parallel towards a (hopefully) common goal. Within this context the goals and deliverables of your team need to be aligned with the other teams. Releases and release dates need to be coordinated and you probably can reuse software parts created by other teams. This means there need to be alignment with (so-called) enterprise disciplines such as portfolio management, enterprise architecture, and strategic reuse.

This will probably ask for a kind of inception phase at the start of your project to define the vision, align stakeholders, identify the initial technical strategy, secure funding, etc. Have a look at the excellent whitepaper by Scott W. Ambler and Mark Lines “Disciplined Agile Delivery: An introduction” for a more detailed description of this concept.

Agility is only possible when the whole organization adopts the mindset

Agile is not just for the software department. If you really want to adopt enterprise agile as briefly described in the previous, you will need an agile enterprise. The whole organization needs to adopt the agile mindset. If only your software department adopts the agile mindset you can crank out releases in a very fast cadence, but what about the rest of the organization?

Let’s take the case of being a software product company as an example. You can create new product releases every month, but can your marketing organization handle a release every month? And what about sales, support, training, finance, etc.? 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. Even at the executive level the focus is on smaller bets, on short feedback cycles. It is such an end-to-end approach which is an important characteristic of enterprise agile.

Conclusion

Enterprise agile is not just a buzz word in my opinion. It depends on the product maturity phase and the target user of your product, but in a lot of cases, even in startups, you will have to make the transition from agile to enterprise agile in my experience. Ideally the team grows more mature along with the process (as they will learn why they change their process), but this of course only holds for the first team members, new people join a more mature process.

Do you have experience with the continuous improvement of your working processes? What did you learn? What are the important characteristics of a mature process in your opinion? Can you relate to the characteristics mentioned above?

Photo by Matija Grguric