Enterprise Agile: 3 characteristics
|16 November 2011|
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 ecosystemThere 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.
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
I’m writing from the perspective of applying agile in a product company:
Another thing that changes in enterprise agile is that you may not be able to apply the “Minimum Viable Product” concept directly. If you’re building a product for an existing category, you’re really thinking “Minimum Marketable Featureset” – and that may include more than the lean MVP concept would call for, in order that you can compete against existing players.
Also, in this world you must include things like options and configurability, particularly if your solution is to be one of a suite and the existing piece of the suite is highly configurable. That sets a certain level of expectation that may force you to offer options where you might not ordinarily. Building a suite also imposes compatibility and other platform/enterprise requirements into “minimum marketable featureset”, compounded with things like look-and-feel and navigational stories that also have to be considered.
Enterprise agile definitely is more complex than “lean startup” agile.
John Peltier (URL) - 26 11 11 - 16:01
Thanks for sharing your experiences!
It seems like replacing an existing system brings a lot more challenges… is it even feasible to do such a project in an agile way?
How are you balancing between “lean startup” agile and “enterprise” agile during the lifetime of a product?
Johan den Haan () (URL) - 28 11 11 - 10:59
A brief post on achieving agility from another perspective – EA
Agility Through Enterprise Architecture: Independence of Structure and Content.
This applies to Business Process, to Root Information Object Concepts, and to Business Situation Rules.
Many specializations go into the same structural pattern. The structural pattern is consistent and stable. This is achieved by PBE (pattern based engineering)
• One Process structure, many specializations. High simplification, high reuse.
Flexibility in Process: The process pattern must enable these flexibilities: any number of nodes, any required dependency in nodes (by dependency rules), any relevant activity in any nodes, any service attached to any activity.
• One Object structure, many specializations. High simplification, high reuse.
Flexibility: Rules outside of the data quality services and the data management function – customized rule content to the specializations.
• Root concept based object patterns. High reuse of a relatively small number of patterns for all business objects. Flexibility to add specializations as needed
• Independence of business Situation Rules and Rule patterns. Rule structure patterns are few, consistent and stable and reusable. Rule content drives logic, decisions, results. Flexibility to add rule content and add Business Situations. Business Situations can evolve from new countries, new processes, new methods, new objects, new formats . . PBE finds and defines the pattern of dependencies. After PBE, flexibility is achieved by adding, modifying rule content; not structure.
System Agility without writing much code or creating databases. The result is support for Business Agility, and lower TCO and Intelligent systems.
James Pennington () (URL) - 19 05 12 - 23:09
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.
Dan Fflanigan - 12 07 12 - 22:42
I’m sorry for the delayed response. First I was on holiday, afterwards I thought it would be better to respond to you with a new post as I couldn’t formulate it in a single comment…
So, here is my response: http://www.theenterprisearchitect.eu/arc..
Please let me know what you think in the comment of that article.
Johan den Haan () (URL) - 10 08 12 - 17:25
Be nice. Keep it clean. Stay on topic. No spam.