How DO you scale agile without frameworks?

Brian Link
Practical Agilist
Published in
8 min readJan 20, 2020

--

There are a lot of opinions about scaling agile out there. And I get it. This stuff is not easy. I tend to lean more toward a practical and balanced approach to solving agility problems, rather than trying to apply any one particular framework. And while you can find success stories of companies implementing nothing but Scrum (and related scaling strategies) or nothing but the Scaled Agile Framework. I suspect, over time there will be far more success stories of companies applying multiple strategies at once in a custom smattering of approaches melded to whatever the company finds works best for them. I think the most adept companies are applying ideas from multiple schools of thought.

Matterhorn by Marcel Wiesweg (and Zacharie Grossen) via CC BY-SA 3.0

So, what does your company do to solve agility problems? Business Agility is a complex set of problems. Whether you are just starting an “agile transformation” or are deep into removing complexities and coordinating new ways of working in all areas of your business, I think the smartest approach is to just keep it simple and practical. Sometimes, applying a framework may be the right thing to do. But in most cases, especially for larger companies, I will argue, the answer may very well be to avoid them. Either way, it takes some discipline and your company needs to put a comprehensive strategy together to make these decisions deliberately and carefully.

By the way, I’d love to see our industry steer away from using the word “transformation” because it implies a start and an end, much like the word “project”. Many companies are embracing a “post-project” world, but wouldn’t it be nice if we could all enter the “post-transformation” world…?where embracing the concepts of VUCA and an everpresent state of change becomes the norm?

I think I’ll probably dwell on this topic for a number of blog posts, so let me start by itemizing some of the important non-framework concepts that I think are worth exploring, if you’re interested in scaling agile and embracing business agility without frameworks. This article is very similar to one I wrote recently on stealing concepts from SAFe and other frameworks, but you’ll see my own shift in focus from tactical to strategic. This post intends to cover more of a guide for a change agent team or senior leadership team to craft their corporate strategy to the transformation approach itself. I hope the following ideas can be used to help inspire your companies plans:

  • ScalingManifesto.orgPaul Boos and others have pulled together this wonderful philosophy that summarizes beautifully a practical approach to scaling agile. Like the original manifesto, it has four core values followed by 12 principles. The four values are below and the lessons are very practical sounding: let your vision steer your progress; allow for organic growth instead of forcing a structure up front; place more emphasis on systems thinking concepts to improve the organization if you have to choose over (only) bottoms-up teams-based improvements; and create a culture that leans on trusting teams over governing them with policies.

In our work to help organizations become more agile, we have come to value:

Shared vision over aligned processes

Organic growth over pre-defined structure

High performing organization over high performing teams

Team-empowered responsibility over organizational policies

  • Focus on all Layers. Ensure that you have top-down executive support, a bottom-up strategy to make great durable longstanding product teams, and (don’t forget the messy middle) a servant leadership strategy to educate, connect, and reinforce both top and bottom messages from the middle. What training and education do you have planned for all three layers? How prepared are the people in those layers to adopt the agile mindset? Prioritize the servant leaders in the middle who are closest to the teams shifting to agile first and work with those about to shift next.
Flow by Fin Goulding and Haydn Shaughnessy
  • Flow with an Executive Portfolio Board. Haydn Shaughnessy and Fin Goulding have written pure gold, simple and practical, in their books on Flow. Executives must have the vision and strategy as well as the transparency to inspire the organization. Value Stream Maps should drive high level areas to invest in, strategic goals and direction while giving the product teams something to align to. Early versions of an executive portfolio board will help the organization prioritize the work at a high level and ensure the work in flight aligns with the forward looking vision. As the organization embraces a larger percentage of agile teams, the principles of Flow and an executive portfolio board can be used to align the financial investment portfolio as well. Durable agile product teams are the currency of the future. An executive team can eventually steer and adjust the company vision, financial investments, and focus through the singular action of confirming which teams will be serving which products and services for the upcoming month (or quarter).
  • Organizational Design and Support. Driven by the vision and strategic goals, start with building great product teams, then build teams of teams. This gives the teams and agile leads a chance to improve on basics before advanced agile topics are needed. People and teams that need to shift out of shared services teams into durable product teams is a disruptive process. Therefore, a slower, organic evolution is helpful to make sure the vision and strategic set of products has solidified over time with your market and customer needs. Make sure the senior leaders are actively driving the changes and keeping a pulse on the organization’s ability to embrace the changes. As the agile presence grows, the senior leaders and core agile leaders should work hard to train and/or hire enough people into the agile roles required to spin up more agile teams.
  • Product Management. If there isn’t a formal Product organization, it should be established as early as possible, aligned with the business strategy and reporting into senior executive leadership between business and technology functions somehow. Customer-centric functions naturally align here as well including User Experience, Design Thinking roles, and in some cases Marketing. Ideally, the CEO and a senior leadership team are the functional leaders and own the product vision that is disseminated through Product Managers down to Product Owners on teams. The importance of the cultural shift to a product-focused mentality should not be underestimated. If done right it is pervasive.
Grand Study Hall, New York Public Library by Alex Proimos via CC BY-NC 2.0
  • Agile Community and Point of View. As the ratio of agile vs non-agile teams increases, it becomes necessary to provide a peer-to-peer support network for all the employees learning to become agile. An Agile Community of Practice is an obvious way to serve this need. The core agile leaders (often called the change agent team) will naturally become the single point of content, questions, and authority for “how to be agile” at the company. In order to scale this function, the change agent team should consider building an Agile Community of Practice, providing a monthly event for peers to help each other, lightly facilitated by the change agent team members. The embodiment of the point-of-view represented by this team is sometimes written down in a playbook and shared, distributed and delivered to teams by the agile coaches, scrum masters, and product managers.
  • Stakeholder Engagement. As an organization shifts from a project management driven waterfall model to a product team based agile model, there is a need to change the way stakeholders are engaged and informed. Often, in a waterfall process these communication channels rely on a pull based model with governance and policies and milestones to ensure the involvement of the right people at the right time. In the agile world, work changes more rapidly and everything is more dynamic, so a new model of engagement of stakeholders is required to keep the right people engaged and involved at the right time. This is especially true in a regulatory environment. The product and agile roles on a team or team-of-teams will need to drive this engagement model, encouraging on-team representation and inviting appropriate parties to sprint reviews, early design sessions, and product launches. Building trust and helping stakeholders shift to the agile mindset, utilizing information radiators, and knowing how to engage with the product team is key.
  • Transformation Backlog. During the years-long period of transition to building an agile company, an organization should utilize agile principles to manage and guide the transformaton itself. This will help create the right level of transparency for what the organization is working on next. How many agile product teams do we have? Which teams will be transitioning to agile next? What products and services have we decided to expand or reduce? Who is deciding what we focus on next? An organizational backlog and kanban board will help steer the transformation and limit the work in progress. Larger organizations will find it helpful to align their separate divisions’ areas of focus centrally as well, including representatives in this centralized strategic board’s conversation. This board will be unlikely to change as often as a product team’s board so the ceremonies are best to be held on a less frequent cadence. Deciding the structure of this team will depend, of course, on the organizational complexity. Senior stakeholders on this team should treat their roles like Product Managers who share a backlog. They should then coordinate and communicate the impacts of changes here to their portion of the organization, its products, and teams.

The process to transition a large company into being agile will take years. It will take great leadership, require a transparent strategy, and leaders will need to apply many agile principles at scale. All success stories will undoubtedly include many failures along the way where an organization, its people, and its leaders learn. Learning how to be adaptive and embracing the cultural shifts required are the best places to focus, however your organization decides to address them. The cultural mindset shifts include:

  • An Agile Mindset (new ways of thinking and new ways of working)
  • A Culture of Experimentation (and Design Thinking Mindset)
  • A Product Mindset (of customer centricity and continuous feedback)
  • A Learning Mindset (of Continuous Improvement and learning from failure)
  • and A Lean Mindset (with a bias toward action and simplicity)

If you enjoyed this, please clap or share. It means a lot to know my work on this blog is read and used by agilists out there in the world.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com

How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com

Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.

--

--

Brian Link
Practical Agilist

Enterprise Agile Coach at Practical Agilist. Writes about product, agile mindset, leadership, business agility, transformations, scaling and all things agile.