Defining Enterprise Coaching

I call myself an "Enterprise Coach," rather than an "Agile Coach" - because I feel that what the market typically understands under "Agile Coach" doesn't really match what I do. I work to improve organizational systems, and Agile frameworks and approaches are just one tool in my belt when doing that. And recently, with the TOP Structure, I have reclassified and restructured how I myself see this role. Let me share my defintion, which I have turned into an interactive site that also gives you a score at the end, so feel free to tick the boxes of competencies you believe that you bring to the table.

We'll take a look at the role of an Enterprise Coach through the lens of the TOP Structure, which - to keep things as simple as possible, stands for "Technology, Organization, Product." These are the three core pillars for (almost) every modern enterprise. An Enterprise Coach works at system level, hence they need to be familiar with all three pillars, as well as their interactions, at every level of the organization.

Domain Overview

The TOP Structure offers an integrated competency model to frame key skills and experiences across three primary domains: Technology, Organization, and Product. These domains encapsulate the broad range of expertise necessary for excellence in Enterprise environments.

Technology

An Enterprise Coach won't necessarily be a profound technology expert, but needs a solid understanding of the technology landscape and the technical practices within it. They should be familiar with how Agile methodologies and principles apply to software development, IT operations, and technological innovation. This includes understanding DevOps, Continuous Delivery, TDD, BDD, and many other technical practices associated with Agile environments. They use this knowledge to guide teams in adopting appropriate technical practices that allow them to work effectively and sustainably.

	Topic	Details
	Lean + Agile Practice	Possesses a comprehensive understanding of Agile methodologies and how they apply to technology and software development environments.
	Software Development Lifecycle	Understands the software development lifecycle and how Agile principles apply to various stages, from demand collection to development, testing and even operational maintenance.
	Technical Practices	Familiar with technical practices like DevOps, Continuous Integration/Continuous Delivery (CI/CD), Test-Driven Development (TDD), Behavior-Driven Development (BDD), pair programming, and automated testing. Can provide guidance to teams in adopting these practices as needed.
	Technical Facilitation	Able to facilitate technical discussions, bridging the gap between technical teams and business stakeholders. Can communicate technical complexities in a simple manner to non-technical team members.
	Digital Transformation	Understands the role of technology in digital transformation and can guide the organization to leverage technology for business agility.
	Technology Trends	Stays updated on the latest technology trends and innovations, and understands how they can influence Enterprise systems.
	Systems Thinking	Understands the interplay between technical systems and processes in an organization. Applies a holistic approach to problem-solving.
	Technical Debt Management	Understands the concept of technical debt and can guide teams on strategies to manage and reduce it.
	Scalable Architectures	Understands the principles of building scalable and flexible architectures. Can guide teams in aligning their technical practices with these principles.
	Tool Familiarity	Familiar with typical tools used to organize technology work. Can guide teams on using them effectively.

Organization

This is a key area for Enterprise Coaches. They need to understand organizational dynamics and how to build collaborative environments across teams and business functions. Skills in this area include change management, strategic thinking, leadership, and communication. They should have experience in leading organizational culture shifts, influencing stakeholders, facilitating conflict resolution, and mentoring other Coaches and leaders. They need to understand how to design and implement strategies that align with the organization's structure, culture, and business objectives.

	Topic	Details
	Organizational Design	Understands how different organizational structures impact the organization's ability to reach its goals. Able to guide changes in organizational design to improve alignment between structure and goals.
	Theory of Constraints	Understands how to maximize effect with minimum change in large organizational systems.
	Change Management	Skilled in leading and managing organizational change initiatives, particularly Agile transformations. Understands the psychological and social aspects of change and can help address resistance.
	Strategic Thinking	Able to design and implement change strategies and how to align them with organizational objectives.
	Leadership	Demonstrates strong leadership skills, guiding teams and individuals through change and fostering a culture of continuous improvement.
	Influencing Skills	Able to influence stakeholders at all levels, including senior leaders, to foster beneficial change practices.
	Communication Skills	Excellent verbal and written communication skills. Able to clearly articulate the benefits of change to different audiences.
	Conflict Resolution	Adept at facilitating conflict resolution and consensus-building among diverse stakeholders. Able to maintain harmony within teams during transformation efforts.
	Coaching and Mentoring	Experienced in mentoring and coaching Agile Coaches, Scrum Masters, managers and leaders within an organization. Can help develop leadership capabilities across the organization.
	Cultural Understanding	Aware of the cultural aspects within the organization and how they impact its ability to reach its goals. Able to guide cultural shifts to align closer with intended goals.
	Performance Management	Understands how to align performance management systems with organizational goals. Can guide changes to recognition and reward systems causing undesired behaviors.
	Assessment	Able to qualify the organization's current state to guide continuous improvement efforts with empirical data.

Product

Enterprise Coaches don't manage products directly. Instead, they support and enable product development efforts. They need to understand how roles such as Product Owners and Product Managers operate, and how product strategy, roadmapping, and backlog management can be conducted effectively. Their understanding of product management can help facilitate alignment between product strategies and ways of working, as they coach product-related roles in the organization.

	Topic	Details
	Product Management Practice	Able to apply product development functions, including concepts such as product-market-fit, design thinking, incremental bets, and iterative development.
	Value-Driven Delivery	Understands how to align product development practice with the delivery of value to customers and stakeholders. Can guide teams to refocus from output to value.
	Lean Principles	Understands Lean principles such as minimizing waste, amplifying learning, and delivering small batches. Can guide teams in applying these principles to their own work.
	Product Strategy and Roadmapping	Familiar with various approaches to product strategy and roadmapping, and can help align these with organizational objectives.
	Customer Centricity	Understands the importance of customer feedback and user experience in product development. Can guide product teams in adopting a customer-centric approach.
	Business Model Understanding	Understands the organization's business model and how product development aligns with it. Can guide product teams in aligning their work with the business model.
	Market and Competitive Analysis	Understands market trends and competitive dynamics that could affect the product. Can guide product teams in responding to these trends and dynamics.
	Metrics and Analytics	Understands how to use product-related metrics and analytics, such as customer satisfaction scores, throughput, yield rates, etc. Can guide teams in using these metrics for continuous improvement.
	Risk Management	Understands how to manage product-related risks including technical debt, market shifts, etc. Can guide teams in effective risk management practices.
	Product Owner/Manager Coaching	Skilled in coaching Product Owners and Product Managers on their roles and responsibilities, including for example backlog refinement, stakeholder management, and cost-benefit optimization.

So - how are you doing?

You scored:

• 0 / 0 Technology Competencies (%)
• 0 / 0 Organization Competencies (%)
• 0 / 0 Product Competencies (%)

That means you consider yourself equipped with % (0/0) of the TOP Structure Enterprise Coaching Competencies.

Would you like learn more about the TOP Structure, and how to become a TOP Structure Coach? Please visit The Official TOP Structure Page.

Does Agile make you faster? Yes! But not how you might think: A reorganization plus a calendar filled with recurrent meetings won't magically make things move faster. So - how do you become faster?

Work on fewer jobs in parallel

Think of it like this: We have 8 working hours in a day. If we work on 8 jobs for 1 hour each, it will take over a week to complete something that could be finished on a single day if we weren't distracted by 7 other things.

Work on smaller jobs at a time

Let me illustrate: If you have a job that says, "Paint porch and garage" - obviously, that thing will take longer than only painting the porch. By slicing the larger package into two parcels, you get two jobs that can each be delivered faster. The benefit? If you have painters paint your porch and garage over a period of two days, you need to inconveniently park somewhere else for two days in a row. But if you have the garage painted on day 1, and the porch on day 2 - you park in front of the porch on day 1, and return to your garage on day 2. Yay!

Admit that we're only guessing until we have a result

We often try to get the requirements right the first time, then do a perfect job. But - that usually doesn't work. The consequence? Arguments, blame and rework. None of that speeds things up. How about we simply accept that "this is version 1, now we need feedback, and we'll incorporate that?" The time spent on justifications, escalations and bickering can be eliminated from the process entirely.

There you have it.
We didn't reorganize.
We didn't assign new roles.
Or create new meetings.
Or introduce new tools.

With these three simple life hacks, I have helped development teams cut their time to market in half, while also increasing quality and stakeholder satisfaction

Addressing some SAFe concerns

Quite often, I encounter concerns with the Scaled Agile Framework. When looking at the Big Picture, and what many companies make out of SAFe, these concerns are valid - and should be taken serious. On the other hand, none of these concerns couldn't be addressed by a capable SPC and a management who cares about making a meaningful difference in their ways of working. In this article, I'm looking at some of them.

SAFe- Blessing or curse?

Typical Concerns with SAFe

Before digging in: I do believe that the skills and experiences of your SAFe Practice Consultants are critical for the success of SAFe. If you rely on people who don't understand the consequences of any advice they give, you're in for a rough ride. An SPCT friend of mine recently said, "Having the wrong SPC's - or skipping the guidance of an SPC altogether - will easily cost you tenfold of what a good SPC would cost you." I agree. Good SPC's are worth their weight in gold. Unfortunately, they don't grow on trees ... but that's a different story.
Now, let's take a look at some of the concerns I typically encounter, and what we need to consider.

SAFe caters to traditional mindset

SAFe acknowledges and respects that many organizations transitioning to agile practices still have a traditional mindset. Therefore, a lot of material in SAFe is written in a way that might be more palatable to people who have a low understanding of agility. This is the idea of "meet people where they are." Yes - that's contentious, but it's by far better than affronting the very people you need in order to make a change. What happens after we met them - that depends a great deal on their motivation to change, and the ability of the SPC to lead change.

Complexity overkill

First things first - if you don't have the problems SAFe addresses, don't use it. With that out of the way, SAFe can't - and usually shouldn't - be applied completely. Much rather, when we spot a problem for which SAFe proposes a solution, we can look at what SAFe says, have a discussion on whether that's worth a try - and if it is, then go for it. That neither means that you need to do things that solve problems you don't have, nor that you have to do things the way SAFe says if that doesn't work for you. For myself, when someone comes to me and says, "We're using SAFe, and have this-or-that problem," I commonly refer to a SAFe article, and the original source pointers SAFe refers to, and take the discussion from there. To me, SAFe is a discussion starter - not the panacea for all ails.

Dependencies everywhere!

SAFe recognizes that dependencies can be a challenge in complex organizations. It provides clear guidance and practices that make dependencies visible, and then offers a way to address these dependencies systematically. In many organizations, dependencies are inevitable - but at least we know which troubles we have because of them, and can start the discussion of what to do about them. I have encountered more than once that teams found their dependencies unworkable and decided to re-organize. A great discussion to have.

Length of planning intervals

SAFe employs a cadence-based planning approach with fixed-length Planning Intervals (PIs) typically spanning 8-12 weeks. Longer planning intervals provide stability and predictability for teams at the expense of flexibility. However, you can adjust the duration of PIs based on your own context. I have seen Agile Release Trains running 3 1-week Sprints plus a 1-week IP Sprint. That even fits Scrum's old slogan of, "Working Software in 30 days or less" - at scale! Try what works for you, and have the discussion.

Top-down planning processes

Maybe we have the wrong picture in our heads, but who can blame us - when we've been conditioned to think in hierarchies? In a SAFe context, we'd like to decentralize that which makes sense - but not everything makes sense to decentralize. For example, the Product Management function in SAFe could be staffed from team Product Owners, if they have the skills and capacity to succeed in that role, so it doesn't need to be hierarchical. What we need is a clear focus on the bigger chunks of value, and align all teams around them. How this happens can vary per organization, but having each team decide by themselves - doesn't bode well. Please be aware that SAFe encourages active involvement and empowerment of teams and individuals in making decisions.

Not proper Scrum

SAFe is not a strict implementation of Scrum, but rather a framework that incorporates agile principles and practices from various sources, including Scrum. Since many teams already run Scrum and are familiar with the core concepts of Scrum, SAFe has taken advantage of that and it retains the fundamental principles of transparency, inspection, and adaptation. When I coach SAFe teams, I quite often refer to the Scrum Guide, and suggest that understanding and practicing Scrum really well helps a lot getting the scaling part right. Unfortunately, what I see quite often is that organizations have already used a highly dysfunctional Scrum for years, and now want to change that. If anything, the SAFe transformation could be an opportunity to fix the Scrum stuff that was always broken and never got addressed.

Teams become Feature Factories

That's already a dysfunction - because SAFe features should focus on value, not on maximizing quantity of work delivered. We should only have a single ART Kanban that's prioritized by value - and teams should collaborate on shared objectives, using common backlogs and cross-team events to ensure a cohesive system solution that maximizes value. While sometimes, we see that individual teams may focus on delivering their own features irrespective of value, SAFe provides mechanisms such as System Demos and Inspect and Adapt events to ensure they don't go off on a tangent and do a large quantity of low-value work.

Fallacious estimation processes

A lot could be said about SAFe's estimation process, and I have my own opinion on the guidance they give. To keep it simple: its guidance is only for people who don't know how to get started. Coaching and empiricism should lead to an approach that meets the needs of those who need the estimates. We should realize that in larger organizations, where quite often multiple stakeholders, other teams and potentially large amounts of money depend on making fairly accurate forecasts for completion, estimation may have implications that don't exist in smaller contexts. My own go-to example is that we need to absolutely know whether the feature will be ready for the Trade Fair, or whether we need to mitigate. But "Well, we might or might not be ready in time for the fair" - could lead to a major PR disaster, and is probably unacceptable.

One Continuous Improvement event every 3 months is too little, too late

While the Inspect and Adapt (I+A) event occurs at the end of each Planning Interval (PI), SAFe encourages continuous improvement throughout the PI, with both the Scrum-of-Scrums (SoS) and Retrospectives being opportunities to surface and address cross-cutting issues. I myself like to give the guidance that teams are expected to make their own changes and improvements independent of the I+A event, and even share learnings with other teams during that event. I expect teams to bring short-term issues to the SoS, and only bring issues to the I+A which require longer preparation and observation periods, and have an impact far beyond the team boundaries. Most of all, we need to consider that the I+A is a point of reflection, where we detach from the daily routine, and come together as a team-of-teams to discuss the things we need to discuss that we never got to discuss before. There's always something. Yes, we could have such events more often - if you feel that it could help, there's nothing in SAFe stopping you. Try it.

Conclusion

I agree that the Scaled Agile Framework (SAFe) has areas of interpretation and concerns. Expecting it to be a silver bullet is completely unrealistic. It does provide a structured approach for larger organizations trying to make sense of this entire "Agile" thing, though - but that only works if they have someone who understands more than just what the material says. When you can address the complexities of large-scale development, cross-team collaboration and overall alignment while continuously improving, you've succeeded with SAFe. To get there, you absolutely must customize SAFe, and use it wisely - otherwise it will become a mess, and that's why you need some folks who know what they're talking about. And I've seen that mess: The shambles take years to clean up. The people who support your change initiative need to be able to address critical concerns based on their own experience and learnings. And the people in your organization who have concerns need a time and place to voice these concerns - because only then can we truly improve.