Entrepreneurial Operating System / Traction - How does it relate to Agile/Scrum?

Transparency is emphasized in both but is used differently. Both approaches make the work transparent. Agile frameworks like Scrum are designed to deal with VUCA (Volatility, Uncertainty, Complexity, Ambiguity) through empiricism — an aspect that EOS® isn’t explicitly solving for. And in this environment, Transparency goes much further — it is not just awareness of what the team and individuals on the team are working on — it is the transparency of whether the product of the team’s work (whether the team is building a product or leading a company) is working and effective.

• Align toward the Vision by making the Vision, or a specific sub-aspect of it, their Product Goal. Even if they are not a product team, this is the overarching goal for the product of their work: winning deals, operating the company, growing, or something similar.
• Plan and deliver on their Rocks and achieve traction by using Product Backlogs, Sprints, and potentially concepts like Program Increments from SAFe, which align well with the EOS quarter.
• EOS Big Rocks can map almost 1:1 to PI Objectives. For teams, I recommend having them at the team level, not at the individual contributor level, to drive collaborative ownership toward results.
• SAFe PI Planning or other types of Big Room Planning could complement EOS®Quarterly planning by involving the actual Teams and not just the function leads in the planning and accountability cycle.
• Issues are very similar to Risks and how they’re managed in SAFe via ongoing ROAMing (Resolving, Owning, Accepting, Mitigating)
• Scrum Sprints map to the Weekly Level 10 cycle. Sprint Review/Retrospective/Planning is an opportunity to inspect and adapt where we are within the quarter, which is especially important in VUCA. We’re not just executing a quarterly plan. We’re intentionally learning what works/doesn’t and adjusting course accordingly.

• All of the above could be used by the leadership team itself.
• The “Product Backlog” is focused on the “product” of the leadership team’s work — which is leading the company — solving issues, growing, implementing strategies/tactics, etc. Changes in Process, People, Dealing with Issues, Advancing Rocks.
• The Increment of each Sprint is not just a “Done / Not Done” answer to to-do items — it’s an actual “working change” in how the company operates. (For example — list of candidates for a VP position, draft scorecard, analysis of desired profitability range, etc. ) This Increment is ready for the leadership team to inspect, review, to adapt their plans (Product Backlog) accordingly every Sprint/Week. A leadership team could also decide to run longer Sprints e.g. Monthly, and use a weekly cycle similar to Scrum’s “Daily Scrum” to inspect and adapt progress within the Sprint. The Sprint length should match the level of VUCA the leadership team/company is facing.
• The leadership Team acts as the “Developers” of the “Product.”
• The PO/SM Scrum roles could map several ways -
• Option 1
• Visionary — Product Owner
• Integrator — Scrum Master
• Option 2
• Visionary and Integrator™- Sharing the Product Owner role
• Dedicated coach/Scrum expert as the Scrum Master

This would follow the guidelines/mapping described above. In this scenario, solid Scrum Training/Coaching would be provided to the leadership team in advance of the whole organization, and they would become Scrum Practitioners better able to understand and drive what’s going on when Scrum/EOS®gets implemented throughout the organization.

If you’re starting to use Scrum in an organization using EOS®or if you’re using Scrum and your organization is in the process of implementing EOS®the list of mappings above will help you create some common language and reduce the conflict/confusion that might arise due to running both EOS®and Scrum at the same time.

Is EOS waterfall?

The main aspect of EOS®that looks like waterfall is that it runs a quarterly cycle with planning the Rocks for the quarter in advance. I don’t consider that waterfall. And if care is given to making sure that Rocks focus on WHAT rather than HOW and leaves enough space to account for variability/learning, I don’t see a problem. It’s very similar to SAFe’s PI-level planning, which is again properly done with an eye towards emerging learning and adjusting course as needed while staying focused on the high-level objectives for the quarter.

What about individual accountability?

Indeed this is a potential area of conflict. But even EOS®makes several mentions of the fact that to succeed, team members need to prioritize the team’s rocks over their individual ones and support each other. When implementing EOS®, there should be an emphasis on accountability towards team rocks rather than individual rocks, even at the leadership team level.

Is EOS micromanagement under a thin veil?

The way to look at this is that EOS®allows teams to micro-manage their work — with the understanding that in a VUCA environment, there’ll be lots of surprises and emerging realities that are better addressed quickly. The Integrator role, like the Scrum Master, should lead the team through this discipline of tight-loop inspection and adaptation rather than feel a need to micromanage work or output. Learning the proper “Leaders who Serve” Scrum Master mindset would be very useful to any EOS leader if he wants to avoid EOS becoming a checklist-based micro-management tool.

Conclusion

As you can see above, as long as you understand the purpose and practices of EOS®, Agile, and Scrum and think about how they can complement each other, you can use them in tandem.

Furthermore, to maximize the effectiveness of EOS, you might want to enhance it with the empiricism and evidence-based management that Scrum provides.

If you want some help thinking through what this would mean in your context, we’ll be happy to discuss it further.

Helping leaders combine EOS/Traction discipline with the empiricism and adaptability that Agile provides is a recurring theme in how I work with scaling companies. Explore Product Operating Model advisory or let’s talk.