The Gory Details

In the following, we list the Principles that we derived. These Principles represent our consensus as a group.

In support of the Principles, we list the “Problems” and “Insights” that we discovered during our retrospective on the state of Agile and the ensuing discussions. We do not claim to have consensus on these Problems or Insights, but each was shared by at least two of us, and was not successfully challenged in the course of discussion. Thus, our Problems and Insights have partial consensus, but not necessarily full consensus as our Principles do.

Every Principle is supported by a set of Insights and/or Problems.

Planning, Transition, and Transformation
Product, Portfolio, and Stakeholders
Data
Frameworks and Methodologies
1. Principle: Fit an Agile framework to your work, your culture, and your circumstances.
2. Principle: Organizations need an “inception framework”, tailored to their needs.
Technical Dimension and Technical Fluency
Individuality v. Team
Team v. Organization
Continuous Improvement
Focus
Leadership

Planning, Transition, and Transformation

Principle: Any successful initiative requires both a vision or goal, and a flexible, steerable, outcome-oriented plan.

This applies to transformation, as well as to any initiative or product development.

Durable success requires working steadfastly towards a vision.

If those doing the work do not have control over how they do it, and are not able to make “field decisions” about how to achieve the vision or goal, the work will suffer and individuals will not develop leadership skills. However, they need a vision to work toward, and they need to understand the overall strategy so that they can align with it.

It is noted that the “mission command” leadership model embraces this principle.

Problem: Agile does not tell you how to transition to being more Agile – it only provides a target state.

Problem: The importance of planning was dismissed, or it was not explained how planning could be done in an Agile manner. Even though the Agile Manifesto did not say “do not plan,” its statement that “Responding to change” is more important than following a plan was taken by many in the early days of Agile to mean that plans are not important. Some even advocated not planning at all beyond the current iteration.

Insight: Thinking ahead is important for product design, for technical design, as well as for transition and transformation. Yet for transformation and for product development, overly detailed plans are a wasted effort, and one should expect plans to change.

Thinking ahead allows one to allocate money and resources to do things. It allows one to identify risks before they occur and plan for them so they have a lesser effect. It allows the organization to decide if investing in a particular initiative is worth it. Plans provide visibility, and flexible plans enable dynamic coordination; these are crucial. Yet, the plan should be continually informed by results, and adjusted, both strategically and tactically; and it should be driven by goals rather than tasks: behavioral change objectives, impediment removal goals, bottleneck removal, alignment, or other goals that focus on net end-to-end effectiveness. How plans are made and revised – whether through a centralized process or a distributed process – is a separate question.

Insight: Change is the new steady state: The corporate finance idea of an organization in a steady state, in which projects implement change, is obsolete. Today an organization’s circumstances change continuously, and an organization must be set up to continuously reevaluate strategy and react to changing circumstances intelligently, always measuring, always reconsidering, but not being reactive – instead, thinking both short term and long term. That is the only way to ensure orderly, sustainable change, rather than reactive, chaotic change. Today’s products are metaphorically living and breathing beings that need continuous growth and care – not just “maintenance” – or they die.

Insight: Product or project – it depends: A traditional project assumes that the organization is in a steady state, and a project changes the organization to a new state; but today’s systems – whether they are developed in the context of a project or a product delivery stream – need to continuously evolve – to respond to a changing market – their success depends on it. Thus, a more dynamic approach is needed. The “product” view is useful in this regard. This is a “kaizen” approach.

In the “product” approach, an organization maintains a list of capabilities – products or collections of products – to maintain and fund, and the details of those are managed tactically. That is a “Lean portfolio” or “value stream” approach. In this context, a “product” is not necessarily a revenue-generating product: it may be a service, or an internal system that serves operations in some way. Looking at it as a “product” fosters a long term view with continuity.

The “project” construct is still useful for achieving focused goals as long as the project plan does not lock down the “how” ahead of time. The “project” construct is best reserved for significant, discrete changes, to achieve a step increment of change. This is a “kaikaku” approach.

Do kaizen as often as you can, and kaikaku only when you must.

Problem: Organizations are often not clear about why they are adopting Agile methods. There should always be clear business goals – such as decreased time to market, increased quality, and so on. The goal should never be Agile itself.

Principle: Any significant transformation is mostly a learning journey – not merely a process change.

Learning new skills and ways of working requires instruction to provide a conceptual foundation and experience to create tangible memories. Experience is what leads to contextual judgment, which is essential for someone to have autonomy and operate effectively.

Problem: Agile defined only an end state; guidance about transition was needed. That is, the Agile community, the Manifesto, and the various methodologies focused on what Agile should be – not how to get there. That is one reason why transition and transformation to “becoming Agile” (the end state) became the biggest challenge only a few years into the Agile movement.

Insight: Transition needs to be addressed. Transition to Agile methods cannot just be a final state – guidance must be provided on how to get there, what happens to existing roles, knowledge that is needed, and changes to existing processes (architecture review boards, etc.), policy, and culture. And that is inherently org-specific. Crucially, Agile methods call for new skills and a lot of judgment, instead of predefined processes, but to attain that judgment, people must try new approaches and learn over time. False starts and pivots are normal and should not be seen as “mistakes,” because people learn from trying things – Agile learning is highly experiential. Thus Agile transformation is primarily a learning journey – not a process change.

We also need to stop thinking in terms of a final “target” state. Any target state is transitional. Change needs to be seen as continuous – not step-wise. (See the Insight, “Change is the new steady state”) Change is a journey, not a destination.

Insight: “Why” is more important than “what”. When planning for change, we need to be clear why we are doing it. The reason why we take a step is more important than the step: without being clear about why, we cannot apply judgment to guide us through the step. Complex steps – such as are required for any organizational change – require thoughtful execution, and contextual judgment. Without knowing why we are doing something, we cannot hope to have judgment about it. And as circumstances change, understanding why we have been doing something is essential for interpreting the new circumstances, and deciding what to do next.

Principle: Change must come from the top.

Without consistent and long term direction from the top, staff will not believe that the change is a priority, and when other business crises inevitably emerge staff will shelve their change efforts. Leadership must also provide clarity about the reasons for the change – the business objectives – and the criteria for success.

Insight: Organization culture should be explicitly developed: Vision and cultural goals should be explicitly managed, and explained to new hires. However, stated visions, goals and values will not become the “way things are done” if management does not exhibit those themselves.

Organizations should see people as their strategic resource, and think in terms of growing the right culture, and hiring people who fit the culture. Vision should connect in people’s minds to the actual work that they do. Leaders must “live” and “demonstrate” the culture that they want. An honest culture is needed in which people can say what went wrong, and in which people don’t jump to conclusions based on sound bites. Leadership should include a strong focus and capability on developing people; and leadership also needs to be informed by an inclusive perspective. Leadership should also exhibit the culture that they seek to develop. You don’t change culture through words, visions and cultural goals alone; you change a culture mostly by changing management behavior.

Principle: Product development is mostly a learning journey – not merely an “implementation.”

Product teams do not start out by coding requirements. They need to first learn about a product’s vision, and internalize the need for the product, its functionality, and its design. Otherwise, the teams will be largely guessing for the countless decisions that product development teams make every day.

Product, Portfolio, and Customer

These principles pertain to the collective management of multiple initiatives. Each initiative must be managed on behalf of one or more parties (sponsors, users, customers, those who have risk oversight or accountability, or any other affected party).

Principle: Obtain feedback from the market and stakeholders continuously.

Product development teams must remain in contact with the stakeholders (customers, constituents, overseers, and any other interested party) to understand their needs. This cannot be left to just one person; the teams must “see for themselves,” through the right amount of direct interaction with each stakeholder.

Problem: Problematic Product Owner (PO) role: The PO role became the de-facto standard for how Agile teams obtained requirements, and that approach has many problems – it undervalues the importance of product design, as well as frequent user feedback and market-facing experiments; and it creates an “order taking” mentality for teams, in which the PO is expected to somehow know what the market needs and can just tell the teams to create it.

Also, the PO role became confused, because on the one hand it is supposed to be someone who knows the business really well, but on the other hand the PO needs to be able to spend significant time with teams – two contradictory requirements; so organizations assigned POs who were really analysts. Those analysts end up with responsibility for product vision, but also all the details of product requirements – again, two opposing needs.

Insight: A sponsor’s claim of value needs to be substantiated by actual business outcomes: In a multi-product organization, a PO has an incentive to claim value. Business cases are often a fantasy to achieve a political objective and measures are a performance to ensure that people keep their jobs and the right people get the credit needed to advance in the organisation.

Insight: There are many stakeholders. The PO is not the only stakeholder (usually). All the stakeholders matter. The most effective relationship between the stakeholders – including the delivery teams – is a partnership; the relationship should not be viewed as a “contract” or “zero sum game,” but instead a win-win, in which every discussion is about how to make the joint endeavor succeed, and is never adversarial.

Insight: Need for business stakeholder on product marketing team. An effective business stakeholder – usually in the role of a PO in many Agile initiatives – who collaborates with the team(s) should be directly involved in the conceptualization and test marketing of a product. There should not be a separate product marketing or product definition group that hands off product requirements to the team-facing business representative to execute. If the product has multiple teams and multiple POs, there should be at least one who actually works directly with the market-facing and functions that define the product.

Insight: There are a range of leadership functions needed to oversee a product, including UX, business SME, marketing, economics, finance (providing and maintaining the funding stream), contract management, human resources and “PeopleOps,” and many other things, as well as product definition and delivery. Somehow these need to be integrated so that they are responsive to each other, and to market feedback, while cohesively providing a unified direction to product delivery. These need someone to oversee the process – e.g., a project manager (someone who gets things done) supporting the product manager (a product visionary). Product owner team.

Insight: 56. Inclusion of actual users is important. This is very important, and programmers need exposure to actual users, to be able to understand the user’s perspective firsthand. The PO is not the user (usually) or an adequate proxy for the user.

Principle: The only proof of value is a business outcome.

An objective is a tangible improvement in the customer’s life. Many activities are needed to realize this, and working software is only one of them. The teams must discover and track all of these through the full lifecycle.

Problem: 7. Working software is not a proof of value. Working software can prove that requirements were met; but the requirements might be wrong.

Insight: 4. Only a business outcome is a proof of value: Working product features are proof of functional efficacy, which actual users can validate – something that is very important to have throughout the development process rather than only at the end – but working features are not proof of value. The only proof of value is an outcome assessment such as an OKR or business metric – perhaps intangible such as the customer’s response – or tangible such as a balance sheet. As per Robb Thomsett’s O3 model, we execute on a set of objectives, to create the output (as working software), in an attempt to realize the outcome (value). Value needs to be determined in the context of the organization’s value system, which might include its investors, staff, constituents, community, and ecosystem as a whole. Work in small increments, to minimize risk, and enable one to pivot early. Use the “last responsible moment” principle for making irreversible decisions. For reversible decisions, don’t hesitate. And assessment of usability and operational efficacy must include an actual user’s perspective.

Insight: Delivery agility does not equal business agility. Teams can execute efficiently on the former yet fail on the latter. What’s missing is a deep understanding and connection between what customers’ underlying needs are, and what the team is told to deliver. Agile was sold as a solution to this problem, but (on its own) mostly fails to live up to that promise.

Insight: Outcome-based metrics are needed, and behavioral metrics are needed as well. And incentives (including financial) need to reflect those. Generally speaking, metrics fall into two categories: (1) those that measure actual performance and outcomes, and (2) those that measure behavior or adoption of desired practices. Those practices are supposed to be leading indicators of desired outcomes, which are trailing indicators. Both are important.

Principle: Work iteratively in small batches.

Deliver demonstrable progress regularly through small batches, each one providing more insight or usefulness than its predecessor. This proves continuous tangible progress, manages risk, and enables stakeholders to provide continuous feedback.

Insight: Validating is important: Before investing in a lot of implementation work one should learn early (and at low cost) so you don’t fail in the market, through small trials and validations.

Insight: Revisit goals continually. Don’t be a “slave to the backlog.” Frequently review where the product is headed, and see if there are backlog items that should be pushed to the far back.

Principle: Product design must be integrated with product implementation.

Product design is a challenging and iterative endeavor in its own right. It is not just a matter of defining requirements, or writing stories. The process of product design must be provided for, and it must closely tie to the implementation process, so that design can iterate and implementation can iterate, and influence each other without impeding each other.

Problem: Product design was not addressed. It was assumed that the PO somehow knows what the market wants. Thus, Agile had an “order taking” mentality from the start: tell us what to build and we will build it.

Insight: Product design is often a critical activity: Highly successful companies like Apple make it their most important function. Market research and user experience research are two supporting activities, and both should inform product design in a continuous manner. These are areas of distinct expertise. They need to be non-biased by team dynamics but still need to have enough “skin in the game” to have enough standing effect change.

Insight: Locking down requirements for a long period of development is often a poor project approach. Many kinds of projects, particularly software projects, benefit greatly from allowing requirements to be fluid, and making the project a success is determined by whether outcomes are achieved. Defining detailed requirements up front can severely constrain implementation teams, who then fail to benefit from the learning that occurs during implementation. In today’s dynamic environment and markets, it is unwise to unnecessarily constrain how to achieve something ahead of time. So while requirements should be managed and not be chaotic, there is a tradeoff between the stability of holding requirements constant for a period versus getting the benefits of refinement and learning by trying and testing, with the customer wherever possible.

Insight: A “dual track” approach should be considered. The “dual track” model is an approach for performing product design and technical design in parallel – each in a separate “track,” such that the tracks inform each other, generally with product design slightly ahead of technical design.

Insight: Design issues emerge over time. A design evolves, rather than emerges. A design cannot emerge, by definition. Design implies intention: an emergent phenomenon arises without prior intention. However, new design issues and patterns emerge over time, requiring intentional changes to a design, to refactor separate parts according to an emerging pattern, or to accommodate emergent issues.

Documentation can take many forms; it can be brief and lightweight, and yet convey a depth of understanding and insight that may be missed by purely face-to-face communication. Use documentation judiciously to complement other forms of communication, so that information that would otherwise have been forgotten can instead be shared, remembered, audited, and reflected upon. Documentation is an ongoing and layered process: document things that will help move you closer to your desired business outcome.

Insight: Communication is a process, not an event, and communication methods should fit the issues that are being discussed; generally more complex issues require more complex and ongoing interactions.

Insight: Writing is important. Short-form writing is essential to enable the use of writing for communication.

Insight: A complex issue cannot be resolved in a meeting with a lot of people.

Insight: A decision process must exist. It can be (1) an orchestrated process with provision for tie-breaking, or it can be (2) a Socratic process that is driven by an individual who initiates or participates in the exchanges that are needed, driving dialectic discussion toward resolution and making a final decision when necessary.

Insight: Sustainable pace, artificial urgency, giving people enough time and space to properly work through items and think about them to the depth required, and avoiding disillusionment and burnout from same. This is partly covered by Principle 7.1.

Principle: Those offering products and services should feel accountable to their customers for the impact of defects.

There is a crisis in product reliability and security (robustness). There cannot be a single value system for robustness: some products have higher need for robustness than others. Those who build things on which people and organizations depend should stand behind their offerings.

If a product user’s organization is hacked or experiences a loss because a purchased or supported product has a security weakness, there should be a direct cost to the creator or supporter of that product, because in an environment where everything is assumed to be insecure or unreliable, no one is held accountable. Agility cannot be an excuse for sidestepping the need to create products and services that users can rely on. If nothing can be relied on or trusted, life is terrible. Agility must be about rapidly creating robust products and services.

Data

This category pertains to the production and use of data by an organization. Such data is an asset and a liability, and robust strategies are needed for oversight and effective use of data.

Principle: Data has strategic value.

Data has strategic value to the success of your product and your organization, and should be central to your thinking at all phases of a project.

Organizations create huge amounts of data about their customers, their customer’s circumstances, their customers’ online behavior, and many other things. That data is a powerful source for insights, but if the data is stored in a way that makes it difficult to correlate across different domains, then the data’s usefulness in obtaining insights is greatly reduced.

Insight: Data needs to be a first-class stakeholder. Data has strategic value. Data specialists are needed on teams. Don’t treat data as ad-hoc. You might need a “data layer” in the architecture. And as for every Agile role, do not silo the data function; experts are required, but they need to be integrated so that they operate in a fluid manner and so that the other team roles acquire expertise pertaining to data.

Guidance: Use FAIR data principles.

Principle: An organization’s information model is strategic.

If an organization exists and has products and services, then the organization has information, and that information is critically important to understand when modifying its products and services or creating new ones.

Creating new business features requires making changes to existing product and service systems. To do that effectively, product developers need to understand the current operational and transactional systems. If they do not have an understanding of the data models used by those systems, they are severely handicapped.

Principle: Carefully gather and analyze data for product validation.

Data is needed by product development teams to validate product features, and those who know the data best or own the data should provide data for product validation.

Problem: Data is needed by product development teams to validate product features, but teams often have difficulty obtaining suitable data. Business stakeholders and business operations teams often have the best understanding of their data, but often expect development teams to come up with data. The result is that product teams do not have adequate data for validating product features.

Problem: Data is not mentioned in the original Agile Manifesto, yet data is strategically important, both as an asset for deriving insights and as a means of validating correctness of implementation.

Frameworks and Methodologies

Frameworks and methodologies abound in the Agile community of 2020. Many frameworks compete with each other, yet are quite different. Which is right? Are any right? Should you “adopt” a framework, or is a framework just a source of ideas? If a framework works for one situation, can it be trusted to work for another? These are all important questions and it is hoped that the principles of this category help to answer those questions.

Problem: Frameworks took control of the Agile movement, purporting to be Agile, but distorting it. Groups emerged to monetize those frameworks, even at the cost of subverting key Agile ideas, such as the importance of judgment over prescriptiveness. Thus, frameworks were sold as “silver bullets,” and organizations thought that they could “buy” Agile, or go through the motions of a framework to “do” Agile, instead of what was needed, which was to learn the thinking behind Agile and acquire the judgment that is needed by trying ideas over time.

Insight: Frameworks can create confusion. They are prescriptive, yet they leave things out. The prescriptiveness causes people to stop thinking; but then they don’t fill in the gaps. For example, Scrum defines some processes, but does not define others that are needed, such as story refinement, design, etc.

Principle: Fit an Agile framework to your work, your culture, and your circumstances.

It is common for organizations and teams to contort the way they work to fit within an Agile process framework. One should take the reverse approach – apply a framework’s ideas to the situation. That is, adjust the framework to fit your needs. A framework is just a set of ideas: do not apply one wholesale or “as defined.”

Insight: 24. The Agile Manifesto was too vague. It was vague enough that its misinterpretation was inevitable. The ambiguity also enabled people to “fill in the blanks” and create prescriptive versions of Agile, and interpret (or sell) processes such as Scrum that defined fixed roles and activities (“ceremonies”).

Problem: Frameworks cannot be used as-is, but they often are. The same frameworks are often used for a range of situations, failing to acknowledge that what works for one situation – say, a single-team startup – might not work for an established multi-product organization.

Insight: Prescriptiveness will fail. A framework or methodology should not be implemented – it should be seen as a source of ideas. Dogma is toxic and stifles learning and empirical experimentation. All ideas are contextual. One should be problem-focused, and not try to “implement Agile” or “implement” a framework. Practices often need to change over time: what teams need when beginning is not the same as what they need months later. Sometimes a practice from outside the set of accepted Agile community practices is needed.

Problem: Dogmas arose rapidly. People were called “Agile doubters” and “Scrum-buts.” The Agile community seemed to claim that there was one way of being Agile – leaving little room for people to do things in a way that worked best for them. People work differently.

Insight: Prescriptiveness and dogma stifle evolution. The community becomes invested in the dogma, and begins to shun change. Certifications for specific methodologies instead of general ideas and practices can contribute to that.

Insight: Do not be dogmatic about a particular framework. Instead, be open to applying a variety of frameworks in combinations that make sense in an organization’s context. Framework purists prevent organizations from seeing things contextually, and from evolving their own broader insights.

Problem: Agile became a culture of extremes. The Agile movement was started by the publication of Extreme Programming Explained, by Kent Beck. Extreme Programming (XP) is eponymously what it says: an extreme. The practices work for some people, but not others. Fortunately the Agile Manifesto, which came about two years later, was a moderate document; but the tone was already set for the Agile movement: practices should be extreme. But extremes do not usually work in large organizations, for most people, for most products.

Insight: Extremes tend not to work in most situations. They can work, but usually only in extreme cases, such as a single-team product and a team in which most people have the same level of experience; or when most members of a group share a set of personality traits; or when there is a sense of urgency or a crisis. Instead of using an extreme as a model, moderation usually informs a better model.

Insight: Do not be derisive: Terms like “Scrum-but” and “Agile doubter” are nasty and dismissive. These and other characterizations made the Agile community an unsafe space for voicing ideas.

Insight: Do not be insular: Read books on a broad array of topics beyond Agile. Reach out to other communities of thought: leadership, organization change, business agility (not the same as Agile, and includes finance and strategy), behavioral psychology, DevOps, microservices, Lean, business, HR/PeopleOps, and any others that might apply.

Insight: A leader or coach should listen to what team members want: Don’t arrogantly assume that they should adhere to a framework, or that you know what is best for them. Recognize also what you personally would want might not be what they want. At the same time, people often don’t know what they don’t know, so it is the responsibility of experts and coaches to share what they know, but in the end let people decide how they want to work.

Problem: Early Agile models did not address scale. Only a single-team model was initially described by Agile models, with multi-team models later added as proprietary frameworks. Organizations were left to either choose a proprietary framework (each varying greatly from the next), or figure out how the single team model might work in the context of a large organization with many products, each requiring many teams, and all integrated in a complex digital business platform. Meanwhile, some of the single-team practices that were being recommended did not work at scale, causing many Agile transformation efforts to flounder.

Insight: Startup versus at-scale are different: What works for a startup does not necessarily work for an established multi-product organization. Agile needs to accept the reality of a range of situations and not insist on one ideal model, including multi-team situations.

Problem: Consulting companies co-opted Agile, convincing organizations that the firms knew how to help them to transition, bringing with them an army of people with framework certifications, but not always with the experience needed to provide thought leadership. Experts often start their own firms and so they are not always found in the established firms. Established firms have experts, but they are needed to maintain relationships and make sales, hopping from client to client, making them less available for actually providing real help.

Insight: Agile thought leaders are often independent – many do not work for big consulting firms. Organizations need help undergoing transformations: they need expert advice, and that expertise often resides among individual thought leaders. Organizations need to be willing to reach out to individuals, and not rely only on large “vendors.”

Principle: Organizations need an “inception framework” tailored to their needs.

Beginning a new initiative, a new “product increment,” a new team – these kinds of situations require startup activities. With today’s high-tool and automation approaches, the startup effort is large and growing. Lean value canvas, stakeholder mapping, sponsor identification, describe the expected journey, design sprint, etc. Test marketing should be included. Metrics for alignment with strategic goals and OKRs should be implemented. One needs to be able to do all of the essential elements of planning in a few weeks to set the teams up for success.

Deciding on the tools to get the best inception framework is more of an art than a science, and therefore it should not be standardized, but rather should be a judgment made for each product. Business stakeholders also have to do their part in locating and eventually providing (in a timely manner) usable data for the purpose of validating the product features (i.e., production-like test data): production data, after all, belongs to the business.

Technical Dimension and Technical Fluency

Early business innovators like Henry Ford and Thomas Edison immersed themselves in the technology and how the work was done. Then things shifted, and managers began to focus more on financial aspects of business, cordoning technology off into a corner.

This trend has reversed: today’s most successful leaders like Jeff Bezos and Elon Musk immerse themselves in the technology and how the work is done. They realize that in today’s tech-driven business, one cannot clearly separate business issues from technical issues. This means that today’s leaders need to take an interest in the technology, as well as how the work is done, and not have the attitude, “That’s a tech thing – I don’t need to know that.”

This category provides principles pertaining to the need for various stakeholders and initiative participants to understand the entire product and its delivery system, and therefore each other’s work, by degree.

Principle: Technical agility and business agility are equally inseparable: one cannot understand one without also understanding the other.

Today’s organization performs many – if not most – of its activities on a technology platform. That platform often embodies the organization’s strategic advantage. Organizational agility and technical agility are now intertwined.

Problem: Loss of technical dimension. Early Agile ideas were steeped in technical methods: eXtreme Programming (XP), which preceded the Agile Manifesto, specified myriad technical practices. But the Agile movement quickly shed any technical focus.

Many believe that the rise of Scrum, which contains no technical elements, is to blame for Agile’s loss of focus on technical practices. In any case, the technical focus did not return until the DevOps movement rose to prominence in the early 2010s, principally after the publication of Jez Humble’s book Continuous Delivery and later Gene Kim’s book The Phoenix Project, which described DevOps in layman’s terms and popularized DevOps.

While DevOps ideas were presented at Agile conferences, and Humble was definitely an Agilist, DevOps ideas did not gain significant attention within the broad Agile community until DevOps had become its own movement. Thus, DevOps evolved somewhat apart from the Agile community at large, which was preoccupied with the non-technical aspects of Agile. That is why today DevOps methods are mostly known by cloud programmers, rather than by Agile coaches, and today DevOps is mostly known as a collection of mostly technical practices such as continuous delivery, the “immutable servers” pattern, “shift-left” testing, “infrastructure as code,” “build once, deploy many,” “you build it you own it,” and “Twelve Factor apps.”

Since technical practices are essential for making Agile work in the context of software development and especially at scale, many Agile adoption efforts floundered during the 2000s partly (not entirely) because of the loss of technical focus.

Insight: Treating a team as a commodity deprives it of innovation and motivation. The tech team needs to have higher standing than Agile gives it – it cannot merely be the “implementer.” Teams need to be involved from inception through implementation and involved in all aspects of the work including discovery and interaction with the customer.

Insight: Tech vision is important, and programmers can be as visionary as business people. Further, the process of technical architecture and design is critical for a robust and reliable system. True technical design does not emerge: it is crafted and refined over time, becoming progressively more detailed. Sometimes technical design decisions prove to be flawed, and it is necessary to revisit them; but technical design is a mostly progressive process – not a process that can be completed up front, and also not a process that can be assumed to emerge on its own. Also, teams that only focus on one feature at a time run the risk of creating a fragmented system that has poor cohesion, because the cost of going back and changing the design to be more holistic is too high.

One model for integrating technical design and product design is the “dual track” model. However it is done, product feature design and technical design are important aspects of overall product design, and both need to be treated as an evolutionary refinement and adjustment process.

Insight: The technology platform is strategic. It is as important as the business features. Nearly every large 21st century company is a tech company. JetBlue describes itself as a tech company that flies airplanes; Capital One describes itself as a tech company that does banking.

Insight: The technology that you use must inform your Agile practices. The technical direction, delivery framework, and technical innovation are all crucial to your success. Your agile practice must include your prominent technology elements as first-class components, alongside the usual processes.

Principle: Business leaders must understand how products and services are built and delivered.

Today, the way that products and services are built and deployed (delivered into the market) is often strategic: it may be part of the business value proposition. For example, SpaceX is able to rapidly turn around design changes to its vehicles; and they are able to perform launches with a very short interval between each. That speed is a strong differentiator. To be able to trade off the value of new features for the way those features are delivered – such as the speed of delivery – requires understanding the basics of how features are delivered.

Insight: Business leaders must understand delivery. Everyone needs to understand the development model – not just the tech team. The delivery system is the business’s capability agility system. This understanding is necessary in order to ensure that the delivery system is optimized in order to maximize business agility, quality, or other goals, which all carry tradeoffs.

Insight: Tech innovation is a separate lifecycle from tech implementation. Tech innovation requires a different lifecycle, and a different kind of oversight. Tech innovation can feed tech implementation; alternatively, members of tech innovation teams (experts) can do “stints” on implementation teams, to transfer knowledge. Systematized transfer of tech innovation to tech implementation requires orchestration of someone (or a team) who understands both.

On the other hand, while having innovation teams feed delivery teams, delivery teams should be allowed the time and space to experiment and innovate as well: sometimes the best ideas come from the people who build things. If they are always under pressure to deliver, they cannot be expected to make improvements in how they work, or to have time to think through new ideas that might greatly improve the product. And since innovation is a different lifecycle process than implementation, an implementation delivery process should not be forced onto how teams experiment and try new ideas. Moreover, teams need to be given some breathing room in their implementation schedules so that innovation from within the team can germinate and thrive.

Problem: Agile was viewed as a “tech team thing” – that it only pertained to how programmers work on a team. Managers did not understand that in order to use Agile methods in a large organization, nearly all of the organization’s functions need to change how they work, i.e. develop business agility. They also did not understand that to transition to Agile methods, they had to lead the change.

Insight: Agile is not just a tech team thing: Agile methods rely on enterprise functions operating in a just-in-time manner and by embedding experts on teams rather than as separate service silos; thus, Agile transformation requires changing how every enterprise function operates.

Insight: Technical leadership is a vital element for a technology platform. Technical leadership means having responsibility for the product’s technology decisions. A person in a role of technical leadership is not intended to be the source of all ideas or an autocratic decision-maker, but instead should have a servant leadership mindset, and be responsible for driving technical discussions and making sure that good technical decisions get made in a timely manner. A tech lead should stay up to date on relevant technology. In terms of scale, a tech lead is needed for every few developers, and the need expands outward hierarchically. A technical leader needs to be able to mentor others, in order to develop their abilities, both technical and in terms of their ability to lead.

Principle: Technology delivery leadership must understand technology delivery.

Leaders who oversee the design and delivery of products and services cannot operate only at a task and spend level: they must understand how the work is being done.

Insight: Technology delivery leadership must understand delivery. Technology delivery managers often do not understand Agile and DevOps methods, but they must. Delivery team coaches, who play an important leadership role, also often do not understand today’s delivery methods – but they must! Engineers have effectively been subordinated to non-engineers who don’t understand the delivery process or the technology.

A lack of understanding of today’s technology delivery methods results in insufficient investment in the delivery tooling and setup, and a relentless focus on new features over technical debt, creating a house of cards that eventually becomes brittle and problem-ridden. Also, the lack of understanding of today’s methods results in an under-appreciation of the value of technical expertise, and tends to promote a view of programmers as commodities – and seeking the lowest cost instead of the most effective.

Technology thought leaders must have experienced the work themselves; e.g., architects must be able to deliver code using today’s methods.

Principle: Technology delivery leadership and teams need to understand the business.

What is intended is not a return to management by technologists, but instead an equal partnership between business and technology at all levels. For today’s strategic digital platforms, tech cannot be viewed as merely an implementer: it must be a partner. Further, technologists need to understand the business, just as business needs to understand the technology and its delivery.

Individuality v. Team

This category pertains to the tradeoffs between focusing on individuals and focusing on teams.

Principle: The whole team solves the whole problem.

A team should collectively figure out how to tackle the features that it is tasked with implementing. They might decide to divide up the work; but, they all own each feature – in that they all decide how to approach it. The common approach treats a backlog as a set of stories that people pick from. Instead, there should be a whole team discussion about how to tackle the stories/features that they are taking on.

This does not mean that everyone works together all the time: the team may decide to divide up the work. Also, focus without frequent distraction is essential for deep work (see Focus). But the whole team takes on each problem (e.g., product feature), and decides how to accomplish it.

Insight: Teams need to know how things fit together, in both a functionality and business sense, and in a technical sense. People need to know more than their two-week objective; they need to know the longer term goals. And they need to know how the many efforts of their team and other teams all combine. Otherwise, they are working in the dark. Programmers and designers make decisions every day – decisions that are embedded in their designs and their code – and if they are operating in the dark, those decisions will suffer.

Insight: Not everyone needs to know what everyone else is working on each day. There is a tradeoff between knowing how things being worked on by others all fit together, and being interrupted constantly every time someone else’s status changes. In some situations it might be better to rely on people to notify others who might be affected by a change, rather than insist that everyone stay current on everyone else’s tasks. This tradeoff might fluctuate over time. On the other hand, it is important for everyone to be able to easily find out what other people are working on, perhaps using “passive” methods such as dashboards.

Insight: It’s not all about a team: Building big stuff requires many teams, and there needs to be a leadership model, interaction model, and growth model for any collective of teams.

Insight: A decision-making process must exist. It can be (1) an orchestrated process with provision for tie-breaking, or it can be (2) a Socratic process that is driven by an individual who initiates or participates in the exchanges that are needed, driving dialectic discussion toward resolution and making a final decision when necessary.

Principle: Foster diversity of communication and diversity of working style.

Not everyone works in the same way: some people like immediate in-person communication, while others prefer to compose their thoughts over time in writing. Not all situations are the same: some are immediately obvious while others require deep reflection. Leverage the strengths of a variety of communication means to bring out everyone’s best ideas.

Problem: Agile came to reflect an extrovert’s approach – yet many programmers are introverts, or at least not extroverts. Practices such as face-to-face meetings were interpreted as “all collaboration should be face to face.” People who communicate better through writing were disempowered. Extrovert-favoring practices were forced on everyone, and the ability of the individual to select how they need to work – often partly a factor of someone’s cultural influences – was subordinated to how the team voted it should work as a whole, which was usually informed by the extrovert-favoring practices advocated by Scrum-certified (i.e., indoctrinated) Scrum Masters and the the Agile community.

Insight: People don’t all work the same: Different people need different things to be productive. Often the best developers are not the best team members – yet according to Frederick Brooks a single brilliant developer can make a product (e.g., Linus Torvalds) – how do we accommodate such people? Remember that a team is composed of individuals. Some people should not even be on a team, because that is not how they work best, and some of those people are brilliant.

Insight: Teams differ: What works for an experienced team might not work for an inexperienced team. The authors of the original Agile Manifesto were all highly experienced; their assumptions about what works for a team reflected their own composition.

Insight: Organizations differ: Transformation is contextual. What works for one organization should not be blindly adopted by another without modification.

Insight: Non-extroverts must be accommodated too. Agile’s preference for face-to-face communication favors extroverts and people who think “on their feet.” People who think and communicate differently need to be accounted for as well, so that everyone is able to communicate effectively. Other practices such as self organization tend to favor extroverts who like to take charge, potentially causing less assertive people to withdraw. Instead, an environment that gives everyone an equal chance at thought leadership needs to be provided. There is also evidence that the “open plan” office is particularly challenging for introverts who might have more sensitive nervous systems and are more easily distracted.

Insight: Communication about a complex issue is a process that occurs over time. Communication often requires conversation, writing, whiteboarding, and private deep thought. Communication methods should fit the issues that are being discussed; generally more complex issues require more complex and ongoing interactions.

Insight: Match the communication format to the issue. The idea of standing meetings should be questioned. Instead, communication needs to happen as soon as it is needed, rather than waiting for a meeting; and communication should be via the most appropriate form: for complex issues, this might require writing out one’s complete thoughts; for other issues it might be a short conversation. Complex topics might require a combination of forms of communication. If a team has a designated leader, usually one of their jobs is to make sure that issues are being identified and discussed (and resolved) in a timely and effective manner.

Problem: The Agile Manifesto over-simplified human behavior. The Manifesto’s statement, “the best architectures, requirements, and designs emerge from self-organizing teams”, was interpreted by the Agile community to mean that teams should self organize. Yet in actuality, the ability of a team to self-organize is not a given, and groups of people often develop conflict, remain directionless, or split into factions.

Insight: Consider human interactions. How people will work, how they will collaborate, how they will be recognized, how they will lead – all the situations, and how to encourage the behaviors that are desirable, yet allow a range of personality types.

People often need to be taught skills and new behaviors to be able to work as a team. To change behavior in a lasting way, one must experience the change and become committed to it and identify with it as one’s “new way.” Good leadership, coaching, and mentorship can greatly accelerate people through the phases of lasting change, whereas bad leadership can block change.

Insight: Cultural differences matter. Be aware of differing value systems, particularly for remote teams. Discuss them; make agreements about behavioral norms.

Principle: Individuals matter just as the team matters.

Each grouping of people in an organization is as important as any other; and the simplest grouping – the individual – matters just as much as the team.

Problem: Insufficient mentorship. The Agile community came to emphasize the importance of “the team” to an extent that it greatly diminished the importance of the individual. The view of the team became egalitarian and almost communistic by frowning on any form of recognition for an individual, and stressing generalists over specialists to an extreme. Team leads now always talk to the whole team – rarely one-on-one – hindering the development of personal mentorship relationships. Yet career advancement is important to people, as is individual recognition, and one-to-one relationships between leaders and team individuals. The focus on the team reduced the amount of one-on-one mentorship and individual coaching that many people need.

Some organizations have resource managers for direct reporting by team members. The difficulty with that approach is that the resource manager cannot combine mentoring with coaching, and cannot synthesize team issues with individual issues. Resource managers also often have much less contact with their reports than a team lead, yet an effective mentor might need more interaction and more contextual opportunities to give advice. This is often more problematic in a large organization than a small one where everyone is aware of goings on.

Insight: Individual are not commodities. Programmers are not all the same – not fungible “generalists.” So-called “T-shaped” skill sets are desirable; but individual differences need to be accounted for, particularly with regard to how people work best. The best teams contain complementary skill sets that allow people to do what they are best at, and they mentor others to share their expertise (“missionary not mercenary”).

Insight: Annual performance management is ineffective: People move around too much. Having only an annual review is too infrequent for feedback. Feedback on one’s performance needs to be continual, concrete (relate to actual events), tied directly to ongoing evaluation, and account for skill levels achieved in recognized categories. Recognition of individuals is also essential. Recognize those who are less competitive and more collaborative and helpful. Feedback by team leaders is valuable, assuming that those leaders have a relationship with the team member.

Insight: People need career paths. An organization also needs a vision for how people advance, how they work together, how they improve. This is particularly important for development team members, who often do not see an advancement path. There also is an attitude in some organizations that programmers are commodities, and that experience does not matter, but in fact it matters a great deal. One of us has a saying, “A smart recent college graduate programmer will rapidly create a mountain of unmaintainable code.”

Principle: Both specialists and generalists are valuable.

Some people prefer to be generalists, and others prefer to become experts. Both of these are important. Holistic teams usually need both, working together, to accomplish great things.

Problem: The Agile community tended to dismiss the importance of experts. So-called “T-shaped” skills eventually came to be advocated, but still it is not acknowledged by some Agile coaches that some people want to become and remain experts, and that experts who can mentor and coach teams are essential.

Insight: Specializing is valuable and sometimes essential. Some people want to specialize. For example, some people like writing test programs or AI. They should be allowed to specialize, and specialists are in fact necessary: e.g., a security specialist or a cloud stack specialist. At the same time, it is important to not pigeon-hole people or force people to specialize. Specialists working together in a complementary and supportive manner can be more effective than a team of generalists, as long as most of the specialists are “T-shaped” and therefore can do most tasks when they need to – instead of having to wait for someone else to do it. Waiting is one of the Lean “wastes.”

Specialists are most effective if they can mentor others to transfer some of their knowledge, although it is not always possible to completely transfer knowledge; a machine learning specialist who has a PhD cannot be expected to groom other machine learning specialists who do not have the same academic foundation.

Insight: Generalists are valuable: Generalists on a team are able to perform many tasks, and so they never need to wait for someone else to perform the task.

Problem: The Agile community dismissed the importance of seniority, insisting that everyone on a team should be treated the same. Agile has become like a pop culture that celebrates the young upstart. Yet Alan Kay – one of the most brilliant computer scientists who has lived – has remarked repeatedly on how each generation re-invents every best practice from scratch, describing the software field as a “pop culture.” Seniority matters.

Insight: Programming was too democratized. Programming is a skill that is difficult to become good at. Further, there are different kinds of programming (e.g., real time programming) that are particularly difficult, and that require specialized skill. There are also personality attributes that are particularly well suited to programming, and those that are less suited. There should be clear-cut skill categories, but those should not be used to limit what people are allowed to do, but instead inform what assistance or oversight is appropriate.

Insight: Balance teams. Mix experienced and junior members within a team so that they can benefit from each other: experienced members bring broader and deeper judgment, and junior members bring new ideas.

Problem: Technical expertise was demoted. It was assumed that tech teams don’t have vision – only the PO has vision – despite the fact that some of today’s most successful companies in history are or were led by technical visionaries (Tesla, SpaceX, Amazon, Microsoft, Google, Apple). And it was assumed that teams could be led by non-technical facilitators who had no understanding of how the team does its work. All the focus shifted to esoteric behavioral dimensions such as “team trust,” yet “trust” is rarely an issue among programmer teams – it is more often an issue between development teams and leadership. The real issue is that development teams have fallen off of the radar screen, to finally be resurrected by DevOps.

Insight: Experts are needed. Different roles tend to have different expertise, at a deep level, and different perspectives. Those are needed, and need to be proactively injected, with thought into how to make these roles work effectively and continuously and not create silos or handoffs. Some important areas of expertise and perspective: QA, customer, user, business domain and analysis, technology domain, security, architecture, operations.

Insight: Seniority changes things. Junior people might need more prescriptiveness or direction than senior people. But nevertheless, always be outcome oriented – every practice should have a reason. The “shu-ha-ri” model emphasizes the importance of experience, as well as the fact that an experienced practitioner does not necessarily follow a prescribed method, but has the expertise needed to be able to tailor their approach.

Principle: Different Agile certifications have unequal value and require scrutiny.

Some certifications represent substantial study and achievement, but some do not – even some that purport to be “master” certifications. One must be careful when assuming things about what a given certification represents.

Problem: Agile certifications were accepted as proof of expertise, and given the same weight as experience and technical credentials. Yet many of the most common Agile certifications are obtained through a two or three day seminar without a test, in contrast to certifications in other fields that require months or even years of study and preparation for an extremely difficult test.

Insight: Certification programs that only include classroom learning are a good foundation, but they do not create expertise: they are merely a starting point. Experience is necessary in order to become effective and to internalize a new way of working.

Insight: Certification should be difficult to have value and meaning. Certifications in other professions such as accounting and finance should serve as a model. The exams for these often take two days and require a year or more of preparation.

Insight: View certifications rationally: If a certification is for a two day course that has no test, it should not be weighted the same as a two-year graduate diploma or years of work experience. Yet certifications may be an important aspect of learning, as long as they are not construed to equate to actual experience unless the training is heavily experiential. Certifications that are not experiential still may provide a foundation on top of which experience can build.

Team v. Organization

This category pertains to the tradeoffs between focusing on teams and focusing on the organization.

Principle: Favor mostly-autonomous end-to-end delivery streams whose teams have authority to act.

Not every team should be identical. Favor building teams that are each centers of excellence for the different parts of your product. Fill them with the diverse range of skills needed to mostly-autonomously handle any likely situation in that area. Give them the authority to act upon information as soon as they encounter it; this includes allowing both time, opportunity and intellectual freedom to properly finish initiatives that they start.

Definition: a delivery stream is a network of people, processes, and tools that build, measure, validate, and maintain a business capability.

Definition: a business capability is a network of people, processes, and tools that deliver business value to actual users. A business capability implements a value stream, which is the flow of business value through a business capability.

Insight: You design it, you build it. Implementation teams should make the key design decisions about what they build, although they might be required to choose from a set of choices.

Insight: You build it, you support it. Teams must be self-sufficient, to the extent possible; in areas they are not, those dependencies must be explicitly managed. The people best suited to maintain a system are the ones who built it.

Insight: Team formation should be thoughtful. The process of forming teams, and forming groups of teams that share a goal or purpose, should be designed. There is considerable time and overhead for teams to become productive. And if team members have competing agendas, e.g., due to different sourcing, those challenges must be dealt with explicitly – they need to act as “one team” – not just a group; perhaps cross-functional, cross-vendor, cross-expertise, etc. – approached from an organizational design perspective. Maximally cross-functional and maximally autonomous, although those attributes are not absolutes.

Insight: Team autonomy is a matter of degree, and depends on the completeness of self-service tooling they are given, and on the scope of integration tests they can run on demand. Enterprise-spanning frameworks are not built and operated by single teams. Just like microservices, delivery teams operate in ecosystems that they cannot hope to master alone. In that context, autonomy means being trusted to make requests of others without having to ask permission.

Insight: Feature teams are the preferred model. A feature team – one that is capable of implementing an entire end-to-end feature by itself (perhaps with the use of self-service tools provided by the organization), is highly efficient because it never needs to wait or depend on other teams. This is the preferred approach.

Insight: Feature teams are not always possible. Some product “stacks” are so complex that most teams – if any – cannot implement all of a feature’s changes, spanning all of the affected components. Further, there are sometimes good reasons to limit a component’s changes to a select set of teams, such as if the component is highly sensitive or mission critical. Thus, features teams are an aspiration, but should not be seen as an absolute.

Insight: People doing the work need to be authorized to make decisions locally about most issues that impact them, rather than having to seek permission. When doing so, they need to inform others, including their leadership, but they cannot be expected to wait as a frequent occurrence. They also are expected to seek expertise as needed, and to discuss an issue with others, to ensure that others with applicable expertise have a chance to contribute to the decision. But the key difference is that the people doing the actual work are authorized to initiate and drive this whole process, rather than relying on management. The people doing the work by and large have the best idea about how to do the work: and thus, they should have a say about decisions pertaining to the work and how it is done, how long it will take, and the risks.

Note that a focus on reducing development costs will actually increase the cost per feature. The focus should be on reducing lead time and cycle time. Eventually the cost per feature will then go down, and product delivery agility will increase. However, it is true that since an investment is required to make these changes, overall costs will likely increase for some time.

Principle: Foster collaboration between teams through shared objectives.

Complex products require multiple teams. Yet teams do not automatically collaborate freely and transparently with each other. A leader or facilitator – depending on the maturity of the team – is often needed to ensure effective collaboration and timely decisions.

Multiple teams often need the kind(s) of leadership that a team needs. A team of teams is itself a team, composed of leads or representatives from each team. The team of teams needs planning, organizing, directing (through consensus or through another leadership model), coordinating, and issue management. How this is provided is a matter of organization design, and the lessons of leadership (see the category “Leadership”) all apply.

Insight: Explicitly design the dependency management process: How will dependent tasks or activities be identified, communicated, and coordinated? (e.g., vendor actions needed prior to internal actions) How will unnecessary dependencies be eliminated? (streamlined, better coordinated, or reduced) How will technical inconsistencies be detected and reconciled? This impacts hardware or software product source code “repo” strategy, branch strategy, integration test strategy, team collaboration practices, API management practices, message management strategy, and many other important kinds of technical strategy. Design how the dependency management process will be overseen, so that it does not succumb to “tragedy of the commons.”

Insight: Teams need transparency: For multi-team and multi-product situations, up-to-date status about dependencies is essential. Some kind of lightweight “Agile PMO” is needed, which is responsible for ensuring that communication is actually happening (not performing the communication itself). Also teams need transparency on lessons learned – retro results should not be private to teams if they might be more broadly applicable.

Insight: Separate product from platform. The platform is the set of things shared among many products. Platform needs its own teams: it is an internal “product.” Success of the platform needs to be based on its ability to provide what the internal customers need.

Insight: Collections of technical teams do not automatically collaborate. Technical teams tend to naturally work as silos. The whole team should be interested in the big picture – otherwise they have a siloed mentality of what they perceive to affect only them. However, it is sometimes too much to expect that collections of teams will collaborate of their own initiative and adequately cover the product-spanning issues, and so explicit leadership is often needed to ensure sufficient cross-team collaboration.

Insight: The completion of a team’s stories is less important than the integrity (business and technical) of the entire product. For example, if other teams are mis-using a team’s service API, the product will fail – and that is everyone’s concern. There needs to be a lightweight scaling model – an “Agile PMO” or a system for coordinating and integration of activities.

Principle: Favor long-lived teams, and turn their expertise into competitive advantage.

There is substantial overhead in establishing a new team. Teams also build expertise over time. The startup overhead and the accrual of expertise are an investment. That investment should be weighed when disbanding a team or shifting it to a new area of focus, because there is a substantial cost when a team shifts its focus to a different product or business area. When a team forms and has to create and learn a new development, test, and deployment system from scratch (which is highly dependent on the product and business area) for the new product or business area, and also has to learn the new product and business area, the entire investment must be made again.

Problem: The Agile Manifesto did not address how teams are funded, but that is a crucial element. Agile is irreconcilable with the traditional corporate finance view of an organization in a steady state, in which “projects” change the organization to a new steady state. Agile organizations are in a state of continuous change, and the IT initiative funding process must accommodate that.

Insight: An agile funding process may be needed. In a large organization, funding needs to be allocated from central sources that are sometimes shared across multiple products; and further, there are often central functions that serve multiple products in order to achieve economies of scale. Capability-based funding needs to ensure continuity for product-oriented initiatives, but allow for occasional increments for discrete objectives. Product-oriented funding needs to be based on the value of the product, rather than the value of each discrete use of funding, allowing product funds to be allocated tactically and thereby benefit from frequent market-facing experiments.

Insight: Creating new teams is expensive. It is far more efficient to maintain teams and flow work through teams, than to create new teams every time there is new work. At the same time, new team members bring a fresh perspective to an existing team.

Insight: Occasionally shift one or two team members to other teams, in order to distribute knowledge and methods.

Continuous Improvement

This category pertains to the need to view any initiative or process as something that requires continuous improvement.

Principle: Place limits on things that cause drag.

Identify and continuously reduce the number of things that slow down work. This includes reducing excess work-in-progress, finishing important unfinished features, reducing excessive technical debt that makes code hard to change or that is a source of time consuming bugs and incidents, removing legacy code that must be maintained or that is a source of problems, and removing process bottlenecks. It takes discipline to prioritize these “house cleaning” tasks, but having the right balance on these will optimize the entire product delivery system and increase the ability to deliver value rapidly.

Insight: Implement automation from the start – otherwise, it always lags, and the lack of automation is a drag on cycle time.

Insight: Automate every procedural task – i.e., not requiring contextual judgment – that will be done more than once, if possible; but automation is only beneficial if it is reliable and resilient to change – i.e., is not “brittle”.

Insight: Organization policy is often a source of drag. Policies that are inflexible impede improvements. Senior leadership should be continuously examining the flow of work as a system, and considering policies that optimize that flow.

Problem: Much of the automation that is used in the product industry is “brittle” – that is, it is not resilient to change, such that inconsistencies are not readily detectable, and changes in one place often require changes in other places.

Insight: Brittle automation is not effective. Lean toward robust automation – tools and methods. Treat automation as a product – the product that delivers your product.

Principle: Integrate early and often.

Work between the many people on a team, as well as the work spanning teams, needs to be synchronized to ensure consistency. That synchronizing should happen early so that inconsistencies are still few, and should happen often so that new inconsistencies do not accumulate. The reason is that as inconsistencies accumulate, the time to resolve them all increases much more.

Insight: Shift integration left. Today’s products are highly componentized and distributed. The sooner product developers can validate that component changes work as a system the better.

Principle: From time to time, reflect, and then enact change.

It takes discipline, authority and autonomy to actually enact change following group reflection and analysis – what Agilists call a “retrospective.” Together with leadership, work to realize the changes that are needed. This will sometimes require working upstream or influencing management from time to time, because some of the changes needed might be outside the team or rely on others.

Be bold: never think “we cannot change this because this is how we do things.” Be the change that you wish to see – that is, be the first to use and demonstrate the new approach when you can.

Insight: Delivery process should be outcome oriented: Use BDD/ATDD; deliver potentially deployable releases at least as often as each iteration – use metrics that highlight that. Embed business value indicators – e.g., customer usage of features; define a business value dashboard for each product.

Insight: Measure the whole product development life cycle from beginning to end – not just the technical parts of it. The entire delivery chain needs to be measured and optimized – not just the portion that is performed by product developers. Too often only product developer functions are measured for cycle time and other efficiency measures, while the business functions on which development depends for specs, data, test scenarios, and so on are measured in an ad hoc manner or not measured as part of the end-to-end delivery lead time or cycle time.

Insight: Cost of validation and cost of change are tradeoffs. The amount of prior-implementation validation that should go into any change attempt increases as the cost of the change increases. Cost of change includes the cost of the change, plus the cost to validate the implementation, plus the expected loss if the change fails to work or fails to produce the expected outcomes.

Principle: Don’t fully commit capacity.

Leave a substantial portion of delivery capacity open for tactical allocation. That provides a more flexible situation and enables rapid decisions on how to allocate capacity to respond to market feedback, as well as enables using some capacity to make improvements to the development process.

Insight: Don’t fully commit capacity, and the percent of commitment should be less the farther out in the future the work is. If all of the teams’ capacity is committed far into the future, there will be no capacity to continuously improve the technical processes, and the quality of the product will suffer.

Focus

This category pertains to the tradeoffs between collaborative versus isolated work and thought, and the need for balance in these.

Principle: Respect cognitive flow.

Only interrupt people when there is a strong need to do so.

Do not perform ceremonies (pre-defined meeting or gathering) by default. The cost of a recurring ceremony is very high, in terms of people’s focus. Yet, people do need to interact on a frequent basis – so there is a balance. Utilize a variety of mechanisms such as status boards or online messaging tools to keep others informed in a “pull” rather than “push” manner. The act of informing should not be an act that unnecessarily demands focus such that the team member has no control over when they give it their focus.

Problem: Too many meetings. The Scrum daily standup is taken for granted. Yet, in a high-functioning team, it might not be necessary. Scrum ceremonies and a tendency to include everyone in every decision takes a toll, especially if one also adds the additional meetings that occur when there are multiple teams and cross-cutting issues for complex products in a large organization. Agile teams complain that they do not have enough focus time. Be sure to limit meetings to those most necessary, and consider measures to reduce their length by using written forms of communication ahead of time and afterwards. Ensure that all meetings have a clear goal, are able to end early when the goal is accomplished, and do not include more (or less) people than needed to accomplish the goal of the meeting.

One issue is that meetings need to be effective. Meetings can be ineffective by being too long, not having an agenda, having the wrong participants, occur too frequently, or being redundant. But the number of meetings can be an issue too – one can have too many “good” meetings. Some meetings are better done as hoc rather than being scheduled as recurring; or it is sometimes possible to achieve the meeting goals in another way, that is less disruptive.

Managers’ calendars have become full of meetings – many different standing collaborative sessions. This is discussed in the Insight, “Managers need to have fewer meetings, and more conversations.”

Insight: Developers should raise issues in near real time (but without interrupting others), as things are finished without waiting for a standup. Sometimes (e.g. for experienced people, or for work that is just beginning) a defined meeting can get in the way and actually inhibit work.

Insight: The need for communication and the need for collaboration are two different needs. Communication can often be achieved through broadcast, such as a message to a text message channel or an email. People can disable messaging when they need to focus. Collaboration requires everyone to participate in real time: it can be very disruptive, and should be reserved for important issues that need to be worked through.

Insight: Team spirit is important. It is important for people to congregate on a regular basis. However, the cost of that needs to be monitored, because the trend has been toward way too much disruption and distraction for product developers.

Principle: Make it easy for people to engage in uninterrupted, focused work.

Many people require quiet periods without interruption or distraction so they can focus, so make it easy for them to do this. This might be work from home, private cubicles or do not disturb notices.

Problem: People on Agile teams often cannot focus. The meetings, but also the use of Slack and Teams with desktop notifications, working in an open team room where someone is always walking by – we are no longer getting people’s full brains.

Problem: Teams were forced to work in open spaces, with lots of noise and distractions, with the rationale that it would foster collaboration, justified by the Agile Manifesto’s unsubstantiated assertion that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” – again an extrovert’s view of how collaboration occurs; but studies have shown that collaboration is actually reduced in an open plan work setting; and such environments destroy focus – many books have been written about that, including Susan Cain’s Quiet, Daniel Goleman’s Focus, and Cal Newport’s Deep Work. Yet organizations persist in using that physical layout, because that setup has become an accepted norm, and the higher human density and lower real estate cost per person is also a new norm.

Problem: There is a myth that private offices discourage collaboration. We are unaware of evidence for that. In fact, some of us have experienced very high collaboration when we had private offices, if the team were co-located – that is, if the offices were near each other. Thus, we feel that physical or virtual co-location is the key – not removing walls. (See Insight “Physical presence”.) It also seems contradictory that companies are willing to pay product developers on a high scale, yet give them the office setup of a low wage clerk – implying that the productivity of highly paid people does not matter.

Insight: Complex issues require deep thought, and deep thought is enhanced by periods of isolation. Many – perhaps most? – people do not think as deeply when conversing as they can when they are alone. This is because some working memory is used to maintain one’s awareness of others who are present, and also maintain the thread of a conversation and plan a response. On the other hand, conversation enables people to learn new perspectives, and to make mental connections; but any conclusions reached about a complex issue are often tentative until each person has had time to process it in private, apart from conversation, when they can reflect and analyze the new information over time and verify that it “holds up”.

Insight: Collaboration does not require physical presence. Some forms of collaboration sometimes work better with physical proximity, although other forms might actually work better remotely. For example, some people prefer screen sharing when they need help on a technical topic, rather than having to look across someone else’s desk at their screen. And text has the benefit of preserving someone’s explanation, which one might miss part of when something is explained verbally, particularly if the explainer speaks quickly or is difficult to understand.

It depends on the topic of collaboration and the individuals: for some tasks or topics to be collaborated on, especially complex topics, written communication might be important. It is noted that the open source movement, which consists mostly of remote teams, has been very successful, but that is not proof for all cases.

How do we detect and quickly head off problems if we cannot easily have ad-hoc conversations? There are practices to make remote work effective: Be results oriented – not activity oriented; Use dashboards – not status reports; etc. Proactively check in on people. Subscribe to their online workspaces. Build an individual relationship with each team member.

A book that we like about remote collaboration is Johanna Rothman’s and Mark Kilby’s From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver.

Insight: Open plan offices can be challenging. The effectiveness is very sensitive to the layout. It is also not clear if it increases collaboration, which is the purported benefit – some studies show it does the reverse, but perhaps that is because the layout was not optimal. Open team rooms make private conversations difficult – that might impede creating mentorship relationships between a team lead and the team members: without a private office, a team lead will tend to have fewer one-on-one conversations, especially those that cover one’s performance or mentorship. Open team rooms can be designed to provide a lot of collaboration space, and walls where information radiators can be mounted; perhaps future technology will enable that via full-wall displays, but it has not yet.

It is ironic that an Agile Manifesto principle is, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” – in other words, enable team members to decide how they will work. Yet their office layout is seldom within their control.

The practice of “hot desking,” which is to leave desks unassigned so that people take them on a first come, first served basis, is also a bad practice for development teams. Teams need to be able to build, control, and live in their space to maximize team communication. Hot desking prevents a communal space from developing. On the other hand, if teams are remote, they rely less on physical proximity, and instead a remote team needs to build an online communal space.

Principle: Foster deep exchanges.

Complex issues require deep and detailed exchanges over time. A complex issue cannot be explored in a single time-boxed conversation. Complex issues sometimes benefit from sharing ideas in writing, and then following up with a conversation.

Talking through a complex issue is usually only feasible with a small number of people – no more than a few, and multiple sessions may be needed.

Deep exchanges are necessary to reach understanding of complex issues. If decisions are made in the absence of deep understanding, decisions will be poor quality.

Time-boxed large group ceremonies or meetings serve a different purpose: to share ideas. They are not a good instrument for exploring an issue in depth, and so they do not substitute for deep exchanges.

Insight: Have in-depth conversations. Meetings that merely share information are wasteful of time: information can be shared in other ways, such as through dashboards, or a quick written note. Meetings are necessary to transfer understanding, which is not the same as information. To transfer understanding about complex issues, deep conversation is needed. Too often today this breaks down in meetings with leadership: they want to know “the ask,” but don’t have time to discuss it in depth. That is a dysfunction, and poor understanding leads to bad decisions. Leadership needs to question their participation in information-sharing meetings, and limit their attendance to conversation meetings, and spend the time needed to actually achieve deep understanding of problems.

Insight: A complex issue cannot be properly resolved in short fast-paced meetings, because there is insufficient time to traverse the depth of the issue.

Insight: Deep conversation occurs best among very few participants, because when there are many participants, too many people want to voice their thoughts, and so one is unable to “have the floor” long enough to fully explain one’s entire viewpoint end-to-end. As a result, people make incorrect assumptions about what others are thinking and advocating, and tangential paths are common.

Insight: A complex issue requires extensive small group (or one-on-one) discussions or written exchanges prior to and following a large group meeting.

Insight: Managers need to have fewer meetings, and more conversations. Managers who go from meeting to meeting, rarely with enough time to discuss issues in depth, and always only wanting to get right to “the ask,” do not really understand their organization, and cannot make optimal decisions. The problem is most acute when the organization is in the process of dealing with rapidly changing circumstances or rapidly changing technology, because then managers cannot simply apply judgment from prior similar situations.

As a result, the ability to have prolonged deep conversations has diminished, with managers now only wanting to know “the ask” so they can say yes or no and rush to their next meeting. Thus, leadership is not able to develop and maintain true understanding of what is happening within their organizations – because they never have a chance to talk things through with a range of subject matter experts.

Leadership

Understanding the role of leadership in the context of Agile is essential, because we believe that leadership is the most important issue of all. In fact, we believe that with the right leadership, the methodology of the teams is much less important: the right leadership will guide the teams so that the right methods will be selected and refined; but with the wrong leadership, no methodology will succeed: bad leadership will corrupt any initiative, no matter whether Agile methods are used or not.

Leadership is the central issue. All other issues are refinements.

The issue of leadership has been over-simplified by the Agile community. Leadership is not a one-size-fits-all question. There is no single leadership model that should be applied to all situations. There are many different forms of leadership – some good, some bad – and different forms are called for in different contexts. To aid in our discussion, we have created a leadership taxonomy.

The issue of leadership cannot be sidestepped, because Agile will not work without proper leadership. One also cannot replace leadership with a process, or a lead-by-numbers set of prescriptions. Leadership is personal, and it is an art form. Just as 1990s-era attempts to reduce project management to an artifact creation process did not succeed, similarly, attempts to replace leadership with a process cannot succeed. As long as humans are the primary actors, the issue of leadership must be met head-on.

The original Agile movement seemed to have been partly a reaction to patterns of bad leadership: the autocratic project manager who told everyone how to work, made bad decisions, and made up for the consequences of those decisions by making everyone work longer hours. The boss named Bill Lumbergh in the movie Office Space epitomized this persona.

Unfortunately, the Agile movement’s solution to the extremes of bad leadership was an opposite extreme: a complete absence of formal leadership. The Agile Manifesto speaks of “self organizing teams” – that is, teams without a designated leader. The Agile community has applied this model as a general principle – almost as a mantra – to the point of dismissing the need for appointed leaders such as team leads or managers.

There is also a false assumption in play: that if a team has no designated authority, then the team becomes and remains a team of equals. In fact, leaders usually emerge within a team, and those leaders can be good ones, or bad ones. Emergent leaders have de-facto authority through their influence within the team, and eventually through their de-facto leadership becoming an accepted norm. One important distinction between a leader with designated authority and an emergent de-facto leader is that de-facto leader’s authority is likely to only be recognized within the team, and not outside it.

A simple solution such as removing all formal leadership has not been shown to work at scale and in a repeatable manner. The leaderless Holacracy model used by Zappos was tried at Medium and they found that at scale, “Holacracy was getting in the way of the work.”

Leadership is the most challenging topic for an organization. It is difficult because different kinds of leadership are needed in different situations. Also, leadership is personal: it is a matter of style, and one cannot “lead by recipe,” although there are leadership patterns that can serve as a model.

In large organizations, hierarchies of authority are notorious for cultivating toxic behavior, in which the wrong people are promoted – people who “act like a leader” but who lack true leadership abilities. Bad leaders may force bad decisions on their subordinates, shift blame to others, act politically, or micromanage: such leaders may be people whose actions are self-serving instead of acting with integrity or in the best interests of their organization and its teams. Someone who is well intentioned might also be a bad leader either because they are incompetent, or they are competent but tend to have bad judgment! – but they can still become an appointed leader if they are able to form strong relationships with those above them. Centralized authority also tends to disempower and therefore demotivate people, and fails to fully leverage their detailed knowledge of their work.

We feel that these realities about hierarchical authority are not controversial; and the horrible experience of so many with toxic, demotivating, and over-controlling IT leadership is something that must be addressed. We do not want to point to the problems of removing appointed leadership but then advise bringing back toxic hierarchies under the guise of agility.

The issue of leadership is not simple, and there are many questions that need to be answered: If we want a team to be able to self organize, who sets up the team? Setting up a team usually requires authority. We already mentioned emergent leadership, and within a self organizing team, a de-facto leader usually emerges over time. If a “clique” emerges within a group (ref. LMX Theory), it usually takes someone in authority to dismantle it. And a single team is not the whole picture: in most organizations, there are lots of teams, and product groups, and different functions interacting – what kinds of leadership are needed to coordinate all of those? And who steps back and asks, are we using the right leadership approach for all these teams? And if not, how should we change it? And who decides if someone should have a pay raise? And who negotiates on a team’s behalf with other functions? Someone without authority cannot make commitments for a team. Finally, teams spend money and use resources, and that requires authority and accountability: who has that authority?

An important insight is that just because someone has authority, does not mean that they always use it – someone can have authority but let people decide how to get something done; but there is nothing like authority to get people to pay attention when you ask questions. Knowing when and when not to use one’s authority is one of the most important aspects of good leadership. This is true whether the leader’s authority is explicit or emergent.

These are all difficult questions, and one size does not fit all. We do not intend to provide a treatise on leadership: there is a wealth of thought on the subject – entire libraries worth. However, the issue of leadership is recurrent and central in Agile, and so we must address it. Our aim is to provide practical guidance within the context of “being Agile,” without over-prescribing.

Principle: The most impactful success factor is the leadership paradigm that the organization exhibits and incentivizes.

With the right leader, an underperforming team will improve, and – we believe – will become more “Agile”; but with the wrong leader, any team – even a very “Agile” team – will degrade, irrespective of which “practices” are used by the team. This is true at any level of an organization.

Problem: Agile dismissed the importance of good leadership, replacing it with self organization and emergent or democratic leadership. By elevating the role of the self-organized team and encouraging trust in the team, the Agile Manifesto implied that there was no need for appointed leadership. The Agile community interpreted this as distrust of appointed leaders, and the preferred leadership model became hands-off. Many technical managers stood back, even when things were not working well, and as a result problems festered. While appointed leadership can be problematic, self-organization does not necessarily solve the problem of leadership. Bad leadership being replaced by no leadership still led to bad outcomes. The Agile community’s tendency to dismiss hierarchical or otherwise structured leadership merely replaces one problem (bad leadership and the tendency of hierarchy to breed toxic power-oriented behavior) with another (insufficient leadership).

Insight: Process is not what creates success: good leadership does; but bad process can block success.

Insight: There are different kinds of leadership: As Drucker said, an organization needs (paraphrasing and modernizing to be gender neutral) “an inside person, an outside person, and a person of action”. All are needed. Also, the work involved in managing budgets, hiring people, and functions pertaining to staff mentorship, coaching, and performance assessment are all essential, whether or not they are done in a traditional or non-traditional way.

Problem: Current Agile community ideas and practices seem to have biases that reflect the cultures and communities from which they arose. In particular, the collaborative free-for-all seems particularly aligned with a US “Silicon Valley” ethos.

Insight: Human cultures strongly impact behaviors, such as how people communicate, how they collaborate, how they dissent, as well as assumed relationships based on age, seniority, and so on. These must be accounted for when choosing or trying an approach for how collaboration and decision-making should occur.

Insight: Possessing authority is not the same as acting with authority.

Problem: Hierarchical leadership structures tend to breed toxic, competitive, power-oriented and self-serving behavior among managers.

Insight: The best way to prevent the formation of toxic authority hierarchies is to foster the right leadership models within the organization.

Problem: Power-seeking individuals will exploit a self-organized situation. In some teams, leadership naturally emerges from among team members, but in other teams it does not, or the leadership that emerges is toxic, controlling, or power-seeking. Oversight is needed to ensure that teams have good leadership, whether it originates from the team or is provided from the outside. The essential thing is that leadership is enabling rather than stifling, that it is fair, that it is transparent, and that it includes mentorship and takes an interest in the development of the team and its individuals. And a team should have a say about who can lead it and who cannot – although “have a say” does not mean “choose.”

Insight: Emergent leadership is often important, but it needs to be governed, because it can be positive or negative – that is, it might generate positive outcomes, or not.

Problem: The best leaders are often not recognized by management. People who cultivate good relationships with their bosses are often toxic to subordinates.

Insight: Organization leaders must identify the leadership models they want to encourage; they must incentivize those; they must establish practices that perpetuate the desired leadership styles, and that favor the empowerment of those who use them; and they must demonstrate that style themselves.

Insight: Leadership incentives need to be aligned with the preferred models of leadership. For example, a leader who receives acknowledgement if the team learns important new skills will make sure that their team is always improving.

Insight: Organizations should use practices to ensure that the right people get chosen (whether they are chosen by management or by a team) – people who are fair and empowering and natural helpers to others – i.e., “missionaries not mercenaries.”

Principle: Provide leadership who can both empower individuals and teams, and set direction.

A team needs a big picture vision. A team also sometimes needs structure. And sometimes a team needs direction. At the same time, people tend to make the best decisions about how they should accomplish a goal. A leader should seek to promote both autonomy and alignment towards a greater objective. A leader should use authority with care. A leader should set goals and constraints.

Insight: Leaders need to focus on outcomes, not tasks. Do not overly prescribe how to attain outcomes – do so only when necessary, such as when a correct outcome is urgent (time sensitive and mission critical), or when an assessment is that the team does not have the ability to produce a good outcome. Consider using the “Mission Command” leadership approach.

Insight: It takes either authority or charisma to set a vision that people will begin to follow; but for them to continue to follow with commitment, one must instill trust.

Insight: A leader should know when “how” is strategic. A leader must recognize when how things are being done is strategically important, and take the lead in those cases, to help to decide how.

Insight: It is important for a leader to understand how the work is being done – otherwise, they cannot discern when the way that work is being done is strategically important. The leader should ask questions, and watch for situations in which intervention is needed, preferring to help by generating discussion rather than by dictating a solution.

Insight: A leader should proactively stay aware of what is happening in their organization, and proactively seek to understand cause and effect. They should try to understand it logically and emotionally.

Insight: If a leader is able to inspire teams, then the leader needs to use much less authority – perhaps none – and the outcomes will be better. Ideally, leaders need to be “missionaries, not mercenaries” – that is, their motivations need to center around making their teams as effective as possible, rather than on their personal advancement.

Insight: The higher the level of self-reliance that a team develops, the more sustainable the team’s performance will be, and the more agility the organization will have.

Insight: What people want and what people need to succeed are not always the same thing. A leader needs to judge when people need something other than what they ask for, and whether they should be allowed to decide, because when a leader decides against a team, there is a cost, in terms of their feeling a lack of of self-determination and diminished morale. In the words of James Hunter, in his book The Servant (page 66), “The leader should never settle for mediocrity or second best – people have a need to be pushed to be the best they can be. It may not be what they want, but the leader should always be more concerned with needs than with wants.”

As an example, when people are put into an open plan office that has adjacent quiet spaces, they tend to remain in the open area, even if they have trouble focusing – either because it is more enjoyable or because they feel pressure to be present and be “a team player.” A misconception is that introverts are not friendly or do not enjoy being around others, when in fact their discomfort is when they have to interact with lots of others.

Insight: Be clear on what the goal is. (Hint: Agile is not the goal.) It might be increased profitability, higher quality, shorter time to market, or whatever. Be issue-focused: that is, identify the constraints or causes of the current sub-optimal situation, and think in terms of both immediate causes and root causes. Any change should have clear business objectives. Any behavioral change that is encouraged should have a clear reason why, and that should be explained. Tie end-to-end: from mission -> vision -> strategy -> OKRs -> prioritization. If business agility is an objective, there should be OKRs that assess actual business agility, as well as that assess progress implementing practices that it is believed will increase agility. OKRs are not usually best for assessing individual performance however.

Insight: Provide a coordinating process that teams can escalate to if a situation is beyond their ability. That process should be crafted based on how rapid the decisions need to be.

Principle: Leadership models scale.

A collection of teams behaves like a team, in which each team is a team member; thus the issues that apply to a team also apply to a collection of teams.

Insight: Teams of teams need leadership, just as teams need leadership. Each level of an organization is fundamentally a team.

Insight: The various kinds of leadership that are needed at the team level are also needed at other levels, and vice versa. In the words of Peter Drucker, an “outside person,” an “inside person,” and a “person of action.”

Insight: Points of accountability for product and technology collaboration are needed at every level, from the team level to the product level and outward.

Insight: Cross-functional issues need collaboration and issue resolution processes, at every level of an organization. The agility of those processes have an increasing impact on organization agility, because issues are becoming increasingly cross-functional.

Principle: Organizational models for structure and leadership should evolve.

The design of organization structures, leadership models, and every aspect of an organization, should be seen as a never-ending experiment, always informed by outcomes, and always being fine-tuned – sometimes radically – in order to pursue ever increasing performance.

Insight: A leadership model should be seen as an experiment, and continually reviewed and refined.

Insight: What works best for an organization at one point in its life might not be best at another point in its life; and in particular, organizational norms often need to change as an organization grows.

Principle: Good leaders are open.

Good leaders get others to honestly voice their opinions, and consider those opinions.

Insight: Servant leadership is a particularly effective form of leadership for teams and teams of teams (and other situations as well).

An argument can be made that in an organization setting, some servant leaders still need authority and accountability, in order to be able to support a hierarchy and to be able to make commitments, and also to be able to act quickly, although there is some disagreement on that. Leadership style is personal, but particularly effective modes such as servant leadership should be recognized and encouraged.

Insight: A leader can constructively contribute ideas if it is done in a way that encourages honest reactions. The ideal however is to stimulate others to provide ideas, so that people do not become reliant on the leader having all of the ideas. A good leader listens to the ideas of their people, and encourages open discussion.

Insight: A leader sometimes needs to make the final decision, but when doing so, the leader should take responsibility for the decision, and also recognize that there might be a cost in terms of team commitment and perceived empowerment.

Insight: Leaders need to foster an environment that has psychological safety for contingent (non-permanent) workers to express their opinion.

Insight: Decision-making is a key practice to be designed. About decision-making:

It should include a range of applicable expertise and knowledge – decisions should not be silo decisions.
It should not be dictatorial. Decision making should be collaborative and involve the people who will do the work in the estimation and planning of work.
Leaders sometimes need to make decisions on behalf of a team, and when they do, they must own those decisions, no matter the outcome.
Decisions need to be timely, depending on urgency.
Decisions need to be transparent, with input encouraged and accepted and notice and appropriate reasons given.
Decision-making needs “the right people in the room at the right time, in the right capacity.” It needs to be open and inclusive, but not unnecessarily inclusive (everyone invited to a meeting), which is disruptive.
A cross-functional decision-making process might need a designated “orchestrator.”
Leaders can and should propose their own ideas, but operate as influencers most of the time. It is essential that team members feel safe challenging a leader’s ideas. A preferable way for a leader to propose an idea is to ask a question that leads the team to think of the idea on their own, and only actually state an idea if the team does not come up with it.
The best idea should win on its merits – not on who proposed it.

Principle: A team often needs more than one leader, each of a different kind.

A team often needs multiple leaders of different kinds, whether appointed or otherwise.

Insight: One sole leader can be a “single point of failure.” If that person’s leadership is problematic, there need to be others whom one can appeal to.

Insight: Different leaders often each have a different focus, such as a people focus, a technical focus, or a process focus.

Insight: Teams often need an organizer. In the words of Peter Drucker, that is a “person of action”. The designated team leader can be the organizer, or the organizer can be another team member.

Principle: Self organization and autonomy are aspirations, and should be given according to capability.

The right conditions need to be put in place in order to enable teams to operate without explicit leadership: the right coaching and training, the right mechanisms for group decision-making, the right support systems and oversight for when things go awry.

Insight: In a self organizing team, people with influence usually emerge – so one still ends up with individual leaders. Different people emerge in different situations. For example, among in-person teams it is usually the most charismatic people who become the team-chosen leaders, but for remote teams it tends to be the people who organize the work.

Insight: Self-organization is a matter of degree. Teams and individuals need control over how they work, but they also need mentorship and coaching. Self organization should be encouraged, but overseen. The amount of self-organizational autonomy granted to a team should depend on the team’s maturity.

Problem: Servant leadership was misrepresented. The Agile community – and especially the Scrum community – identified servant leadership as a model for how to lead teams, but described the role as a kind of facilitator without any explicit authority or individual accountability. Yet servant leadership, as described by current authors such as James Hunter and even as originally described by Robert Greenleaf, is still leadership. It is not democracy, and it is not limited to facilitation. Servant leadership emphasizes that a leader needs to develop legitimacy among their followers, through showing that their leadership is good leadership, and that they are trying to help their followers. But servant leadership is still leadership: the leader still says, in the words of Robert Greenleaf, “Follow me.”

Insight: Servant leadership can have explicit authority, or not. There are variations. A servant leader might need authority because people often do not know what is best for them. (We reference the earlier quote by James Hunter, author of The Servant.) It is acknowledged that the leader often does not know what is best either: human endeavors are about judgment, and an aspect of the human condition is that sometimes no one knows what is best. The key aspect of servant leadership is that people follow willingly because they trust the leader. Thus, authority plays a limited role, and a servant leader who has authority rarely uses it.

The details of servant leadership can vary from person to person, but the essential element is that they are motivated most by what helps their teams to achieve the common goal, rather than what helps them personally.

Insight: Someone needs to represent a team when dealing and negotiating with other parts of an organization – and that person needs authority and accountability in order to have standing. Also, the leadership style of that person need not be the same as the leadership style of someone who focuses inward on leading the team.

Insight: Stakeholders need an individual identified, to contact when issues affecting that team arise. They also need to develop trust in an individual, and build a relationship over time, which requires continuity; and so that individual needs to be able to speak for the team, and be able to make commitments on behalf of the team: otherwise, there is no basis for a business relationship between the stakeholder and the team representative.

Insight: If a servant leader has authority, they will use it sparingly, and be accountable for their decisions.

Insight: Servant leadership is effective for guiding teams. Servant leadership is a style of leadership that focuses on helping a team to be maximally effective, rather than directing the team’s every step. It carries both accountability and authority, and both of those are important.

It is important that leadership empowers people to make decisions about how they achieve objectives, and not prescribe every step. The people doing the work often know best how they can get the work done and achieve the goals. That freedom is not a blank check however: in a given situation, a leader might determine that the team is not capable of making the right choice about how to do the work, and might suggest or even mandate a way, while recognizing that doing so might have a large cost, as previously explained.

It is noted that servant leadership comes naturally to some people, but for many others it can be learned, although for some people a servant leadership style is very challenging because it requires substantial “letting go.”

Insight: Authority and accountability are essential in some situations. Examples include: (1) setting up a team; (2) hiring someone; (3) removing someone from a team for problematic behavior; (4) defining a special role for someone who has not been able to work with a team; (5) managing a budget; (6) making purchases using an organization’s funds; (7) negotiating and making agreements with other business stakeholders – including outside ones such as a regulator – on a team’s behalf; (8) setting compensation or giving someone a raise or bonus; (9) defining an organization structure.

Insight: Individuals who act as mentors lead by helping others. Such people are very valuable on a team. This form of leadership is not reserved for a “team lead,” but can be anyone on a team. Marty Cagan proposes that with emergent leadership we want “missionaries not mercenaries” but that is not always what we get.

Principle: Validate ideas through small contained experiments.

Experimentation is an essential element of agility, and the learning that comes from failure is particularly instructional. Experimentation is how one can test ideas and learn. At the same time, large risks need to be identified and mitigated before they become very costly or unrecoverable. Test ideas early and at small scale, so that one may learn from that and avoid failing “large and late.”

Guidance: Determine what the teams are able to do on their own, and empower them and trust them within that range. However, always check on progress and outcomes.

Guidance: Determine if more expertise is needed, and if so, upskill the teams. Seek to advance the maturity and decision-making ability of teams so that they become as independent as possible, and can handle all of the challenges before them without outside help.

Guidance: Do not punish, unless someone has been intentionally irresponsible.

Insight: A leader needs to balance short and long term goals. The need to deliver value in the present, versus the need to improve a team or organization’s capabilities and effectiveness (and lead time).

Problem: Failure was advocated as the “best way to learn.” Coaches often claimed that teams should be allowed to fail in order to learn. That is a misunderstanding of the idea that failure happens sometimes and that if one punishes failure, one might discourage people from trying new approaches, but that small experiments help one to learn and usually avoid failure when it counts. Yes, allowing someone to fail so that they learn is a valid learning strategy, but it is not categorically the best learning strategy.

Insight: Failure is not always the best way to learn. Accepting occasional mistakes is important, because if mistakes are always punished, people will become very conservative and will not try new approaches – leading to a stagnant organization. However, team leads who see a failure coming and allow it are letting down their team: they have an obligation to coach the team and teach them how not to fail, while recognizing that failure will sometimes occur anyway. But remember that one big mistake can cause a disaster. The whole point of making small experiments is to learn early and in a reduced scope, so that the cost of failure is small.

Insight: Risk needs to be managed explicitly through practices such as test coverage, user feedback, tracking production incident rate, etc. Treat the product delivery chain as a system, end-to-end, and try to anticipate every way that it might fail.

Insight: Leaders must actively seek information and act on it – not wait for it to be presented, or passively observe: instead, seek out the truth; ask questions; skip levels; initiate discussions, and make decisions. A team lead or tech lead should be immersed in the “big picture” as well as how the product development and testing should work, know what others are doing, and know the technical and process patterns that are effective. Management should understand the delivery process.

Elon Musk and Jeff Bezos have proven that even the CEO needs to understand the most critical aspects of how the work is done – indeed, determining what is “most critical” is a subjective assessment that they make, informed by an overall understanding of their delivery ecosystem. And business stakeholders cannot make tradeoffs about the value of new platform business features versus improvements to technical agility if they do not understand how the time-to-market value of technical agility and what gives rise to it.

But that does not mean that managers should be micromanaging; being aware does not imply that you give direction. Rather, being aware is how one can discover that something important is being overlooked, at which point one can initiate discussion and a problem resolution process.

Principle: Professional development of individuals is essential.

Help them to learn to work together more effectively. Help them to develop both their career paths and their expertise. Invest in them to enable them to craft a better product. Make it easy for team members to learn from each other and to develop mastery.

Insight: People need to be developed, and that is an important reason that team leads are needed. Encourage people to move around within the organization. Proactively develop their skills and broaden their experience. Allow them to work on things beyond their experience – provide mentorship and coaching when needed so that they can. Ensure that they are not “used up” by a relentless delivery cadence, and that they have time for technical experimentation and learning – “downtime” when they are not expected to be delivering. Rotate people to broaden their experience. Pair junior people with more senior mentors, but be careful to not stifle fresh perspectives. Identify what skills a person wants to learn (and presumably that the org needs), and define a learning path. Long term performance resulting from employee effectiveness and growth needs to be balanced with the short term performance achieved by keeping someone where they are and not investing in their growth. This is often very problematic with respect to contract workers because contract workers need professional development too, yet contract workers are often left out of improvement training: who pays for training should be a separate issue from who must obtain the training.

Teams might need to look forward and predict the skills that will be needed, so that team members and leaders can plan how team members will obtain the needed skills.

Insight: Leadership benefits from experience. Be it domain experience, P&L experience, sales experience, technical experience – leaders need more than training in a methodology.

Insight: Leadership of individuals requires personal relationships and one-on-one communication.

Insight: Team spirit is important, but people also expect to progress in their career, have their achievements acknowledged, and be rewarded for their progress.

Insight: Management of people should be thoughtful. People are the key from which capabilities arise. Each of them are different. They need to feel valued, need to advance and develop, need to feel listened to and need to feel empowered, and need to feel safe. Decision-making can feel chaotic if it is not done thoughtfully. Think through how decisions that affect people will be made, how they will be communicated; how people will be recognized, how they will advance; how they will be able to feel safe, and feel listened to and empowered.

Insight: Leadership is personal. One does not just lead a team; one leads the individuals in a team. So what about one-to-one relationships? Leadership on a personal one-to-one level is important too: things like individual mentorship, empathy, and helping both individuals and teams to solve problems.

Insight: Some leadership approaches can be taught, although not everyone can learn every leadership approach.