You’re a software firm that’s utilized EOS in your launch phase to “run the organization” while you focus on your product(s) but now you have a problem: “our Product & Engineering teams are fully Agile and we’ve outgrown EOS!” I don’t believe so. You’re now ready to run an Agile firm with EOS as your “flavor” of organizational agility. Time to get to work!
EOS enables firms to ramp up quickly because it puts people first by empowering them through trust and transparency, thus, enabling individuals to strive for success both personally and for the company. This sets up its second strength in focusing on the big picture while cascading down through the org to individuals giving each team member the opportunity to choose how they will shine. EOS builds great culture as a result because it becomes part of a firm’s DNA. The issue for growing software firms is that EOS does not give prescriptive elements on how to get work done, rather, leaving it up to an org to choose whatever method works best for them. So, you have a great organizational structure focused on “What” and “Why” but need a delivery mechanism for “How.”
In my organizational architecture practice, my approach to a firm’s process flow is very connected to my engineering past; I focus on the notion of interconnected patterns and constant optimization. Also, I hold the desire to have a library of tried & true elements that can snap in to save time and effort (and risk) that has been put through the paces. I’ve been trying to crack the code, as it were, when it comes to how EOS Rocks correlate to a firm with multiple mature revenue streams while developing new products and it dawned on me that the issue isn’t a matter of cobbling together a bunch of different systems, rather, it’s viewing EOS as the organizational agility function.
When I had this lightbulb moment, I searched for anyone posting/writing about it. To no surprise, EOS consulting and implementation firms don’t tackle this subject because they make a living on EOS. Conversely, Agile firms don’t touch EOS because they cover that in whatever flavor of org agility they pick. I did find this post and it connected the dots as far as the cornerstones of an agile organization and where EOS intersects: https://medium.com/antarius-en/agile-with-eos-f785a0bad71f — the author, Chris Burger, does a great job of showing overlays on how EOS maps to corporate agility, but, doesn’t go into operationalizing the concepts.
Where I am leaning is to use the Scaled Agile Framework’s SAFe 5 For Lean Enterprises “Full” implementation (https://www.scaledagileframework.com/) for a mature firm (or at least one with multiple revenue streams in its portfolio). It is the closest to the Product lifecycle for multiple SaaS offerings requiring a core enterprise of underlying services. Additionally, the Portfolio aspect seeks to manage discrete revenue streams (customer-facing application, really) that all flow into the rest of the SAFe for enterprise nicely.
In spinning up a Product division or moving to a product mindset, SAFe Enterprise Essential is a very good core model and it affords great flexibility. All what a product-driven firm requires is there including the Design Thinking toolset to develop net-new IP quicker and with better understood risk (investment). Getting to prototypes faster that are desirable for users, technically feasible for the firm to develop, and are economically viable is crucial to a product-driven organization. Further, even the smallest of firms can start with the Agile Product Delivery methodology and even combine that function with the Team and Technical Agility aspects as needed.
When it comes to larger firms, the issue of how to wrangle new revenue opportunities and keep existing value streams up and delivering becomes a sticking point. To me (and to SAFe), a Portfolio represents a revenue stream. Lean Portfolio Management has “Epic Owners” which are really business sponsors in this use case. The aspect of a Portfolio’s Lean Budget — ownership of CAPEX and OPEX aspects — can be owned by the business sponsor if accountability lies that way in an org. That same accountability layer (EOS again) can carry through to the Agile Product Delivery level but might change depending on firm size and structure, but, I’d suspect the hand-off to a Product team would have happened further upstream. Either way, the Portfolio needs to be tied to a greater Enterprise strategy and should carry through in the Portfolio vision.
SAFe is grand but what about EOS and, more importantly, Rocks? In the Portfolio, there are Epics for the Portfolio. Those are designed to be major milestones in moving the Portfolio along in whatever way deemed. They don’t have to be software release Epics as we (Agilists) typically think about Epics, but, they can work in the same fashion in that an Epic has subset Stories that break out into discrete Tickets, etc. Epics in this sense are Rocks. In fact, it meets this SAFe definition: “The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.” (https://www.scaledagileframework.com/lean-portfolio-management/).
Rocks are intended to be overarching strategic initiatives in play against yearly/3-year/5-year/etc. goals played out in a quarter/90 days (or over several if need be). Epics in a Portfolio can directly be that. On the Portfolio level, if the Portfolio is “Mobile Applications” and is, in reality, treated like a firm’s Mobile App Division, everything lines up nicely and Rocks (Epics) on the strategic level could be something like: Yearly Goal: Drive Mobile App Revenue 15% which cascades to: Q1 Rock: Establish Sales Roadmap / Q2 Rock: Onboard New Sales Director & Enact New Deal Desk / Q3: Recruit & Onboard New Devs and PMs / Q4: Capture New Revenue. The point is that these are SMART and broken out into milestones across the year (or whatever period) to achieve that yearly goal and that someone is accountable for the Rock in the portfolio.
Going further, Lean Portfolio Management (as does all of SAFe) requires a notion of Business Agility — that’s where EOS snaps in directly. It becomes the way you run the firm in an Agile fashion. It is the lens for corporate structure being people-focused (another SAFe principle) and allows, most importantly, the aspect of “running the business” to be a core function under a framework that isn’t so tightly coupled with software delivery. Yes, it has ceremonies — we love that — but more importantly it requires a firm to step outside of the day-to-day to talk about business performance and the people that make up the firm. This is particularly important in a scaling business because not everyone operates in the software delivery function.
People (EOS) + Process (SAFe) = Product.
If you are an EOS firm that has faced this challenge, how did you/how do you approach it? What has worked? What has flamed out? I’d love to hear your thoughts.
