Article Series: Part 3: Team Design Strategy – Where do we start?

A pattern for Team Design strategy & self-Formation Workshop events

In this series of articles, Agile Rising’s Scaled Agile experts has introduced and provided recommendations on peer-reviewed and field-tested ideas and patterns for organizing around value while using SAFe as guidance. The patterns include critical features of value stream management, SAFe principles, Design Thinking, Agile, organizational change management & design, industrial and organizational psychology, team design strategy, team topologies, team formation & self-selection, and applied Lean and Systems Thinking.

Series Article Topics

Team Design Strategy – Where do we start?

February 19, 2023 - Marshall Guillory, Scaled Agile SPCT, Enterprise Agility Coach

In previous articles we introduced an overview of two new workshops that we add to our SAFe implementations, Team Design Strategy and Team Formation & Self-Selection and explained what Team Design Strategy is and why you would use it. In this article we will figure out where to start with Team Design Strategy (TDS) by understanding some key philosophy and mindsets so that a goal can be defined. These mindsets are foundations for successfully designing the value stream “collaboration” network and launching ARTs that have capability, time, and space for innovation in realizing business agility. We will also explore how using OKRs for the team design can help drive success in how the designs are delivered and perform.

Parts of this article were written by AI.

Where do we start?

With a Goal

Plainly, strategy is defined as a plan of action [how] intended to accomplish a specific goal. Team design strategy is a deliberate (and reusable) plan for forming and managing a team to accomplish a specific goal. So it goes in Team Design Strategy that we must first discover and define the goal. So, what did we do next?

Excerpt from, “Connecting Enterprise Strategy to Portfolio Execution”

“At Apple, people are putting in 18-hour days. We attract a different type of person — a person who doesn’t want to wait five or 10 years to have someone take a giant risk on him or her. Someone who really wants to get in a little over his head and make a dent in the universe. We are aware that we are doing something significant. We’re here at the beginning of it and we’re able to shape how it goes. Everyone here has the sense that right now is one of those moments when we are influencing the future.“
–Steve Jobs

Team design strategy is a critical component of any organization’s success with change planning and management. It involves creating a well-planned and thought-out approach to building and un-managing teams to achieve specific goals. A strong, informative, and inspiring team design strategy not only helps create a more productive and efficient team but also fosters a positive and collaborative work environment. One part is the strategy – how the design serves the purposes of the organization and the other part is the design – how people organize around value.

–Laurene Powell Jobs

Why do we need team design strategy in the first place?

“Today’s complex, uncertain, and volatile world has rendered incremental improvement and change obsolete. Instead, organizations must deliver non-linear, dramatic change on a regular basis just to keep pace with the rapid changes and transformations affecting nearly every industry.”
–John Kotter, Change

Because of the inevitable moment and inertia, when people organize into teams! Or, perhaps your people are already organized into teams that are not working well for your business or mission goals. The teams may still be deadlocked in the trap of matrixing and fractional allocation across many projects in the complex domain. Are your teams stuck in complacency, or order taking mentality with little to no innovation? Is your business underperforming in the market? There are many possible motivations — which should be tied to a problem statement and the ‘why?’

In Kotter’s book, “Change,” he states “Today’s complex, uncertain, and volatile world has rendered incremental improvement and change obsolete. Instead, organizations must deliver non-linear, dramatic change on a regular basis just to keep pace with the rapid changes and transformations affecting nearly every industry.” We agree wholeheartedly but this statement leaves us begging the question of how organizations can apply a pragmatic approach to planning for and managing change at this pace. Traditional HR transformation and digital transformations worked on a scale of years — not the 6 months or less that is need to keep up with the competition.

Why bother with digital transformation if the design and solution is already obsolete by the time the changes are implemented?

In case you were wondering, we assume that your organization already understands the teaming concept and teamwork. We’ll explore why we need teamwork some other time.

If we desire teamwork some group of change leaders will need to do the work to understand the system, the problem space, design a solution, implement it, and then un-manage it. To enable “intent based leadership”, one must give clarity and intent. Create the environment for thinking. That is all from Captain David Marquet, ret, an inspirational and important leadership thinker. Then, sense the market, rinse and repeat. In our terms this implements the SAFe principle of re-organizing around value beautifully.

We chose ‘team design strategy’ because we intentionally want to separate managers from the job role of assigning people to teams and managing their tasks. To keep the good parts of the hierarchy and remove or weaken the parts that hinder business agility. We believe self-organized and self-managed teams are desirable. The Agile Manifesto says, “Business people and developers must work together daily throughout the ~~project~~ product/service life cycle,” and to “Build ~~projects~~ products and services around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

the challenge

Reality wins where the people and culture are when you start. As it is well known that the most common solution to ‘self-organizing‘ teams in many agile implementations and growth journeys is a manager assigns people to the team(s). A manager who is not on the team, but wants the team to ‘be agile!’ Say it isn’t so, but the manifesto says, “The best architectures, requirements, and designs emerge from self-organizing teams.” This does not imply that there is anarchy as the business and strategy still exist around the team.

Sad dogs are tied up and just want to be free to innovate

Lets keep the Iditarod in Alaska with dog sled teams and not in your business.

The solution

The goal must support the mindset shift in thinking about the purpose of a manager and her responsibilities to the team. Growth Mindset is key and the first place it could appear in your new organization is during Team Design Strategy. The effort requires change minded growth leadership. If the organization does not have clear strategies documented and a vision for a differentiating future then “people will be unmoved.”

The lore of “Agile” is replete with reference and intent for teams to be independent, autonomous, and self-managed. The common misunderstanding is that agile teams are groups of cowboys and cowgirls wandering the prairie, herding cattle in unmanaged chaos with Kevin Costner, which is not true. Because we don’t find agile teams at Yellowstone ranches, we find them at businesses and missions. Agile teams have purpose.

It is really important to revisit and understand the importance of Scrum and its influence on Agile.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
scrumguides.org

Extreme Programming (Kent Beck and others) introduced the concept as “all working together elbow to elbow” where risk is high or with dynamic requirements a small team will be more effective. Scrum popularized the concept of cross-functional team members having all the skills necessary to create value in a sprint.

We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway. XP requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow.
http://www.extremeprogramming.org/when.html
Extreme Programming

How do we construct the goal

There are many techniques that we can use to facilitate the discussion about the “goal.” We could use Sinek’s Golden Circle, or Doerr’s Goal Setting Framework. We could just have a conversation. How you get there is not as important as clearly defining and documenting the GOAL of the consequent team design strategy and ultimately the change that follows that impacts your teams, customers, and organization.

more challenges – Going Fractional

A common practice inherited from matrix organizational structures is fractional allocation of people to teams. Fractional allocation can actually work in some specific cases but only in consideration of the entire system. Jurgen Appelo refers to it as multi-teaming. This is highly role dependent too. Theoretically, the strong matrix with project mindset is very successful. Perhaps in certain circumstances. In the real world the strong matrix burns people out and stifles innovation. This is another topic to explore separately in comparison, but agile teams are long-lived for their purpose. One way to understand this key difference is captured in the research of Dr. Mik Kersten in his book Project to Product where we learn how to survive the Age of Software. Mik explains that project mindset creates a chasm between the business and IT through three epiphanies.

Mik Kersten’s Three epiphanies

Productivity declines, and waste increases as software scales due to disconnects between the architecture and the value stream.

Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model.

Software value streams are not linear manufacturing processes but are complex collaboration networks that need to be aligned to products.

When building a strategy for team design we must move past project mindset to understand the products and services – the catalog – and learn to organize around value by moving the work to the teams and not the people to the work.

applying lean and systems thinking

Every business is a software business. This doesn’t mean that every person is writing code. But every person has a role to play in the creation of value in the value stream. Let’s explore.

Moving from Project to Product Includes:

Putting software delivery at the core of the organization, not an isolated department

Measuring to outcomes, instead of activities.

Automating the entire deployment pipeline and delivering in small batch sizes.

Avoiding Proxies. Don’t believe that if you’re doing the process right customer outcomes will automatically get met.

Mik Kersten, Project to Product

The connection that we make about the root cause is through projects to the strong matrix organizational structure and project mindset. Project mindset is not bad or evil. It has a place in the ordered domains (Complexity Theory; Cynefin® framework). In complex social/collaboration networks of organizations working with competing priorities and resources on complex solutions – project mindset fails to deliver reliably.

We know from organizational studies that people that do not regularly work with each other do not develop the trust necessary to fuel high performance. When it comes to technical work this can become more important as cross-functional skill support needs to be consistent to have agility. Multi-teaming, the matrix structure, or fractional allocation causes less efficiency in communication, and therefore less efficient execution and harms the ability of the teams to achieve business agility.

What problem are we trying to solve by organizing our teams around value?

This is most often tied up in the “Why” of your digital or agile transformation. “We have a burning platform…”, or “We are proactively innovating in our ways of working…” are common threads. In this context though, we must set a goal that is relevant to the why for the teams. What could the goal look like, or not?

Nots that we are trying to avoid or remove as waste:

Our goal is to organize the teams along functional roles such as software developers, testers/quality control, business analysts, and hardware engineering. So, this makes the developers happy because they only have to work with other developers. (the intra/inter waterfall trap)
Our goal is to organize our teams around xyz business segments because that is the sphere of influence of our change sponsor. (the local optimization trap)
We trust the teams with no vision or boundaries. So long as I only have to work with people that I like (the social network trap)
No goal statement provided to teams
We are not ready to make changes because HR was not consulted and the job requirements have not been defined and changed

Keeps driving by Strategic Themes and investments in Epics:

Our goal is to deliver value faster and with higher quality by organizing our teams around value into an agile delivery/release network or agile release train using the SAFe as guidance to design and build a new value stream network and operating model for our business.
Objectives and Key Results:
- Increase speed of innovation by 10% measured through leading indicators in product innovations and customer adoption, NPS, and usage metrics
- Invest in our people by offering technical and agile training for 100% of our staff to attend at least 32 hours of training in the next 12 months
- Invest $5M into building a continuous delivery pipeline and the technology necessary to realize the benefits of a DevOps culture
- Reduce time to market for new services or products by 5% per quarter by measuring flow time for features per ART

Evolving your Goal Statement and OKRs

The evolution of your team design strategy goal statement as constructed should include knowledge about team designs that we have already acquired. The teamwork concept – working towards a shared goal, cross-functional teams – derived from SAFe, XP, Agile Manifesto, and Scrum, Team Topologies, and from lean principles are all necessary elements supporting a great goal statement for developing team design strategy.

Lean principles:

‘precisely specify value by specific product’
‘identify the value stream for each product’
‘make value flow without interruptions’
‘let the customer pull value from the producer’
‘pursue perfection’

As your change leaders continue to explore creating a great team design strategy have the team do introspection on the design and strategy and see if it measures up to the concepts and principles. Here are ten questions to start asking of your organization when you start building your goal setting framework:

Does your organization have defined strategy?
Is the strategy communicated regularly and repeatedly (if you have to ask how many times, do it one more time)?
Is the strategy available at any time (transparency) for any employee to view and is it kept up to date?
Are the organizations products and services defined?
Is value by product and service defined?
Has the organization constructed a goal setting framework that connects enterprise strategy to execution?
Does the organization use regular check-ins against the key results of objectives to determine if the strategy is effective?
Are KPI’s used to objectively measure the outcomes of the value stream and strategy?
Are the value streams identified and mapped for each product and service?
Are measures in place to understand flow, the constraint, and waste in the value streams and act to improve the system?

“The most valuable “currency” of any organization is the initiative and creativity of its members. Every leader has the solemn moral responsibility to develop these to the maximum in all his people. This is the leader’s highest priority.”
W. Edwards Deming

Where you start is important. Team Design Strategy is about solving an organizational problem that affects your business. Not a product problem. This is about the people solution. The people who build your product and service solutions.

Learn more about

The Agile Rising Difference

Access the Overview

Breaking Silos – start with value streams, end with flow

Part of precisely specifying value by specific products is breaking silos away from your product and service concepts. From a lean perspective this means we must first define value. Value for customers and our business is captured in the things we sell or provide to the mission.

For example, if an organizational silo is named ‘Applications’, the product that you sell to customers is not that generic. It is something specific, like a Financial Management & Accounting Application that your customers use to manage their accounts, budgets and money, provide fiduciary reporting, and artifacts for auditing and compliance. Or a password management tool. An iPhone app.

The other extreme is also potentially missing the precision necessary to define value. For example, the ‘audit log comparison report’ is a feature of a product, not a product independently of itself. Of course, products can be bundled with services. All of the products and services go into your catalog [see ITIL].

Begin by gathering the right people and data to document and agree on what your products and services are. You may already have a Product/Service Catalog, so start there. If you don’t this is a great place to begin constructing one.

The silos that are familiar to your context may not be the only silos you need to achieve business agility (AI generated image – Agile Rising 2023). The organizations product is the grain, not the silo. Team Design seeks to intentionally define a flow based system for the second system – the siloes – to enable flow of the product and innovation.

Breaking silos down to create the virtual network, bring online the second operating system, gets hard once you look beyond the boundaries of the classic IT or software or engineering shop in large, complex organizations. Or, from the perspective of product teams or the business using those services seeing IT or software as more than just commoditized tools and an expensive cost center (TBM Value Conversations).

If we truly desire to achieve business agility we must break the traditional boundaries down and make space for innovation in not just ways of working, but in the ways we view our organization as a whole – the enterprise operating model.

“Yes! Put the surgeon on the agile team.”
– Chris Ruch, Agile Rising, speaking about business agility and teams in the context of the Department of Veterans Affairs

The silos that are familiar to your context may not be the only silos you need to achieve business agility. The product is the grain, not the silo (in our example).

Tradition, ‘as-is’, or ‘was’, certainly has consequence and will influence the new things we design. But, we need speed of innovation to sustain a balanced Survive mode, and enable Thrive (Kotter). We must unlock the hidden assumptions in the system.

For example, we work with the Department of Veterans Affairs in an ongoing transformation engagement. In one of our classes we were having a discussion about how the VA service lines (departments/BUs) were organized and how they would translate into agile teams. Chris Ruch made a point in the discussion that the software development team may actually need the surgeon on the team in order to deliver value. Otherwise, the actual user of the product is just a cold collection of bits and bytes on a document, or at best an interesting persona. What is better than well written personas? The actual surgeon.

This is business agility, realized. Now, we know this isn’t always possible or economically feasible. But, agile is all about the art of the possible. “Simplicity–the art of maximizing the amount of work not done–is essential. – The Agile Manifesto.” It may cost many thousands of dollars to have a surgeon spend time on an agile team. But, misunderstanding, technical debt, and rework also cost many thousands of dollars.

to enable a balanced survive and thrive, committed Leadership is required

The hierarchy does not have to be dismantled to recreate the collaborative network. In fact, we should keep the robustness, efficiency and stability of the hierarchy to support the general operational model, the people engine, and a place from which to guide the purpose of the business or mission. The hierarchy is the framework upon which the network, the second operating system, lives. Its purpose is to sustain the system of innovation and creativity that drives high performing teams.

what’s next?

Keep an eye out for the next topic article in the series, “Part 4: Team Design Strategy – Workshop.”

References

[1] Bennett, Nathan, and G. James Lemoine. “What VUCA Really Means for You.” Harvard Business Review, Jan. 2014, hbr.org/2014/01/what-vuca-really-means-for-you.

[2] “The Three Epiphanies of Mik Kersten.” IT Revolution, itrevolution.com/articles/the-three-epiphanies-of-mik-kersten/. Accessed 23 Feb. 2023.

[3] Snowden, David. “Home.” The Cynefin Co, thecynefin.co/. Accessed 23 Feb. 2023.

[4] Leffingwell, Dean, and Donald G Reinertsen. Agile Software Requirements : Lean Requirements Practices for Teams, Programs, and the Enterprise. Upper Saddle River (Nj), Addison-Wesley, , Cop, 2012.

[5] Watkins, Michael. HBR https://hbr.org/2007/09/demystifying-strategy-the-what