I ask this question to agile leaders working with five or more teams: 

What boundaries and empowerments do you set for your self-organizing teams? 

More specifically, are their agile teams free to choose their own tools and technologies? Can the scrum masters lead agile backlogs the way that worked for them at one of their previous jobs? Do you have defined quality, security, compliance, and other criteria that define “production readiness,” or can teams decide this themselves? Where do you need standards to improve collaboration with stakeholders and demonstrate KPIs or OKRs to executives?

At StarCIO’s Driving Digital Workshops, we survey participants to tell us whether they lean toward startup-like self-organizing principles or if they bend toward more enterprise-like standards. We then ask participants to identify which principles and practices associated with startups and others more enterprise-like are most important to their organization’s success.

You’d be surprised what you learn about your organization and team, but one thing I can share with you is that the results illustrate a wide grey area between startup and enterprise extremes. 

Guiding Self-Organizing Agile Teams

And this begs the question as to how agile leaders define decision-making authorities across their agile team. Does a product owner have the ultimate say in backlog priorities even if they consistently punt on prioritizing tech debt and security patches? Or maybe you have strict stage gates in place for new ideas, architecture boards that stimy experimentation and change advisory boards creating too much friction to agile teams’ velocities?

Again, most agile leaders would agree that the boundary conditions – no/little decision authority or hard/strict rules are both undesirable. 

Defining the Agile Operating Model and Agile Principles

So the question is, what is your agile operating model and how do you define an agile way of working? Where do you provide hard specifics, and where do you let teams figure things out with complete autonomy?

These are fundamental areas StarCIO helps clients work through as part of our agile centers of excellence. The basics are available in previous blog posts and 5NYIke videos where I outline agile leader roles:

• Product managers and owners guide teams on markets, customer personas, product visions, roadmaps, backlog priorities, and requirements.
• Delivery managers and team leaders are most responsible for hitting release dates and quality, defining standards, and ensuring teams are happy and successful.
• Program managers, scrum masters, and business analysts each have different responsibilities, from resolving blocks, working on compliance functions, and ensuring non-functional acceptance criteria are defined and addressed.

These are just the start. It’s easy to describe agile principles, but not trivial to do, drive consensus, and develop lightweight and usable documentation. 

And sure, you can buy your way to an agile way of working with a framework to help you “scale agile.” But does that shoe fit your organization’s culture and goals?

Or does self-organizing also mean self-defining your agile way of work? 

I certainly think so, which is why my company, StarCIO, offers agile guides and not frameworks, and why we believe agile leaders must cocreate their agile centers of excellence.

I’d love to tell you more about creating your agile way of working. Reach out to me if you’d like to chat about it.