What is Agile Model (2019)
Agile software delivery practices enable teams to deliver more business value more quickly by improving collaboration and using an empirical process to inspect, adapt, and improve business results. This blog explains what is an agile model in great depth.
In today’s competitive business environment, long-term planning and multiyear projects have given way to frequent releases. Agile’s inspect-and-adapt approach fits the bill.
How Agile Is Your Organization?
I have witnessed only a few examples of large organizations that have been successful with true agility, with far more insisting they are agile but merely adopting a couple of techniques or ceremonies within an otherwise command-and-control, low-trust, and traditional operating model.
When I first start an assessment, I interview the leadership at all levels to get some feel for the culture. Here are some comments from actual management interviews:
Sure, we’re agile, but why do we have to bother the customer?
IT knows the customer’s business; can’t I just be the product owner?
I want to adopt Scrum, but I need my MS Project work plan.
Why do we have to meet every day? How about twice a week?
Pair programming doubles our cost. Why spend the money?
Why should we pay for automated build tools?
Even with impediments to self-organization and agility, companies and government agencies are increasingly turning to agile frameworks because they sense, correctly, that by improving their methods and tools, they may increase customer satisfaction, speed delivery of value, and raise the quality of software, systems, and services.
The problem is, they often think that it’s only about changing their methods and tools, and they give short shrift to the power of culture.
Once the domain of mid-size software companies, “agile-like,” a term that describes an organization that adopts some agile ceremonies without the accompanying organizational change, has become mainstream in the IT shops of Fortune 100 companies and government agencies.
All Is Not Well with Agile
While the popularity of agile frameworks like Scrum, Extreme Programming, and Scaled Agile Framework cannot be understated, in some ways, they have been a victim of their own success.
Large companies eager to replicate small company successes; satisfy younger, more self-organizing employees; and to just simply “go agile” have jumped on the agile bandwagon.
Unfortunately, they often give inadequate attention to the changes in governance, infrastructure, measurement, and training required to succeed. The results have been chaotic, with large organizations adopting some elements of
Scrum (e.g., daily standups and sprints) and force-fitting them with more traditional roles and techniques that are in conflict with agile values. This conflict dilutes the value of the very agile ceremonies they use and leaves the organization without the benefits they were hoping to achieve.
Here at AgileCxO, a research and development organization, we sponsor an observation-based organizational assessment and certification program designed to verify that the selected governance, frameworks, ceremonies, techniques, and values are aligned in a way that enables large-scale self-organization and successful agility at scale. This values traceability is essential to successful agile.
AgileCxO’s partners assessed more than two hundred companies between 2010 and 2017 with these results.
More than 90 per cent assigned project managers for task management, oversight, and control of agile teams.
More than half did not conduct regular retrospectives.
Almost half conflated story points with hours yet still considered velocity to be a reliable metric.
Most made no changes to governance, infrastructure, or training to support agile adoption.
Many senior leaders were unable to describe what behaviours were expected in order to achieve sustainable agility.
These obvious conflicts with agile values result in a scenario where leaders may desire agility but continue to apply low-trust, defined process-control models to run the business, when a high-trust, empirical process-control model is required for successful agility.
The Missing Layer in the Operating System
While the Agile Manifesto excels in describing why we do what we do, and industry frameworks and models describe what we need to accomplish, there is little guidance for leaders or teams on how to experience consistent success with self-organization and agility.
This layer isn’t a process, but a set of guide rails that helps leaders and team members recognize what large-scale agile looks like and provide the ability to recognize, evaluate, and improve agile performance. As I often tell conference audiences during my talks, “It’s not magic. You just need to be able to recognize it.”
To succeed with “great big agile,” technology leaders and teams can start by categorizing capability into three interdependent layers: why what, and how.
“Why” models: The set of values and guiding principles that are traced directly to the goals and methods of the organization. With its guiding principles, the
Agile Manifesto is perhaps the best example.
“What” models: The set of frameworks, methods, roles, and artefacts derived from industry-standard models or internal methodologies. These models define what needs to be done and often provide examples that help us understand what we need to do while executing the software product development process.
“How” models: A set of behaviours, actions, and outcomes that helps define and evaluate organizational success and supports the culture, goals, and objectives of the organization. “How” models trace directly to established values, guiding principles, and frameworks to ensure that the behaviours exhibited by teams reflect the values of the organization.
An Operating System for Scalable Agility
At a recent appraisal of a very large-scale agile organization with more than three hundred Scrum teams, our appraisal team was looking for a way to gather more information about how certain agile ceremonies were being performed. Our solution?
We executed an all-day Gemba Walk, whereby we strolled around two large towers watching teams perform standups, pair programming, planning poker, spring demos, and more.
It quickly became obvious that, over time, teams had strayed dramatically from the true meaning of those ceremonies, some to the extent that they were no longer receiving value from them.
It was then that I decided a better model was needed, one that not only described the actions needed to adopt agile frameworks but also described why and how to “be agile.”
The design challenge was that all existing models from which to draw from attempted to depict “process” in two dimensions in a linear format. This isn’t how agile works.
Agile is object-oriented, with guide rails that are instantiated by project teams who are free to improve them, and with services, ceremonies, and techniques being leveraged “as a service,” which is why we never refer to scrum or other agile frameworks as a methodology or process – they are frameworks at best.
Yet, people still try to draw flowcharts, swim lanes, or sequence diagrams to depict their agility.
AgileCxO’s Agile Performance Holarchy (APH) is an organizational operating system that encapsulates all three layers, providing leaders with an integrated view of organizational agile performance.
APH provides agile leaders and teams with a model to build, evaluate, and sustain great agile behaviours and habits. It is not an agile maturity model or a process, but an operating system for sustainable agility.
1. Understand agile values and embed them in the agile agreement.
2. Negotiate with the agile supplier, giving consideration to the following:
Iterative and incremental delivery
3. Continue negotiations until the contract terms and conditions are agreeable to all parties.
4. Document values, contract terms, conditions, and deliverables. For example, adopt a shared definition of done with the agile supplier to enable easier acceptance of deliverables.
5. Execute an agreement so that work can begin. This includes conducting regular retrospectives with the agile supplier to inspect and adapt performance.
6. Monitor and maintain the agile agreement until it is fulfilled or terminated. This involves providing feedback to the procurement department that can be used to select and engage future agile suppliers.
1. Review the current physical space and validate that it reflects the following values:
Seek input from teams for their desired work environment.
Identify any impediments in the current work environment, for example, facilities policies, noise, furniture, physical space
Prioritize workspace improvements, with the team’s input, based on value and constraints, for example, cost, time, building, furniture.
Determine the required visual information management tools, for example, whiteboards, information radiators, screens, and signs.
Make iterative and incremental changes to the team’s agile digs.
Try it and don’t be afraid to fail! You can always improve the team workspace again.
Agile Partner Assessment Description
The purpose of an Agile Partner Assessment is to select an external partner to collaborate with that is committed to agile values and to deliver products and services in an iterative, incremental way.
Review project, product, or service requirements for an agile partner.
Determine what criteria must be met for selection. Criteria should be weighted as necessary, and the evaluation of agile values should be considered.
Select which qualitative or quantitative method will be used to make the selection.
Identify multiple agile partners to be considered.
Compare agile partners against the criteria. If appropriate, request a demonstration or observe the partners in action to collect performance data.
Collaborate with key stakeholders to review comparison results.
Select an agile partner.
Develop and execute an agile agreement.
Automated Build Description
Automated Build is a component of an overall continuous integration or continuous build strategy that increases product quality and development efficiency.
Automated Build is a system that executes unit and regression testing on completed code modules without manual intervention, checks the modules into configuration management (code management) system, compiles them, and, assuming success, builds them into the larger code base for integration, system, and user acceptance testing.
An automated build system can also enforce rules, such as coding standards, and improve code quality using success criteria.
1. Establish common coding standards for formatting, naming, intra-application interfaces, APIs, and static analysis quality checks.
2. Define rules that regulate check-in of code modules based on standards.
3. Enforce the rules through build automation.
4. Automate as much unit and integration testing as possible.
5. Use automation to promote code that has passed all automated tests, and block code that has not passed the required tests.
6. Maintain and improve the automated build system.
Some other Desired Behaviors
1. Define the goal, problem statement, or context that will be addressed by the brainstorming session. Communicate it to all participants before they attend the session.
2. Identify and communicate ground rules.
3. Prepare the boards, tools, and supplies that are needed to conduct the Brainstorming session (e.g., sticky notes, markers, flip charts, boards, mind mapping tools, projector).
4. Identify a capable facilitator.
5. Ensure understanding of the goal, problem statement, or context of the session before brainstorming begins.
6. Be open to all ideas.
7. Ask questions to invite new ideas and involve all participants.
8. Record and display all ideas during the session.
9. Review or summarize all ideas at the end of the session. Identify and assign follow-up actions.
Class, Responsibilities, Collaborators (CRC) Cards Description
CRC Cards (Class, Responsibilities, Collaborators) are typically used when object-oriented design and development is preferred, and are helpful when there is a need to rapidly design one or more product features that may be instantiated as an object within the source code.
First, two or more team members write down the names of the most critical classes involved in the feature on index cards.
Second, the cards are fleshed out with lists of the responsibilities of each class and the names of collaborators (i.e., other dependent classes). Third, team members perform a role-playing exercise and assume the role of one or more classes while playing out a plausible scenario of the design.
1. Identify the core classes that are the building blocks of the product. Look for the nouns in the design documentation to identify three-to-five main classes.
2. Create one index card per class (begin with class names only).
3. Add responsibilities for each class by looking for the verbs in the design documentation. Ask yourself: “What does a class do? What information needs to be maintained?”
4. Determine dependencies with other classes. A class often does not have sufficient information to fulfil its responsibilities. Therefore, it must collaborate (work) with other classes to get the job done.
5. Reposition the cards as needed. To improve the team’s understanding of the system, the cards should be placed on the table in an intuitive manner. Two cards that collaborate with one another should be placed close together on the table, whereas two cards that do not collaborate should be placed far apart.
6. Move classes to the side if they become unnecessary.
7. Add and refine until everyone on the team is satisfied.
Evaluation is a method to understand how work is being done. Whereas a Gemba Walk is to “go and see,” evaluation is to ask, record, and provide feedback to an agile team or functional group.
Evaluations are conducted against a known baseline, and they are performed by an objective, trained resource using a checklist or commonly understood set of criteria.
Results are communicated to the agile team or functional group to help them improve team performance. Evaluations are valuable for understanding the consistency of behaviours across many teams within a large organization.
Evaluator (e.g., agile leader, agile team member, scrum master)
Evaluations are conducted against a defined standard or common set of expectations.
All participants are made aware of both the content and timing of evaluations.
The evaluator gathers useful information that can help improve the team, group, or organization.
Individual team members are not evaluated. Evaluations are conducted on teams or functional groups only.
Foster an environment where everyone is able to evaluate an organization, group, or team that is independent of their own. This may involve establishing an evaluator role that rotates periodically among different people in the organization.
Add improvements and impediments discovered during evaluations to the appropriate backlogs.
Evaluators follow up with the agile team or functional group to verify that improvements were considered appropriate.
Gemba Kaizen is a Japanese concept of continuous improvement designed for enhancing processes. Gemba refers to the location where work is performed, while
Identify business problems that are recognized by the organization.
Observe the known problem using a Gemba Walk.
Identify the root cause. Use of lean techniques such as “five why’s” can be useful in identifying root causes.
Once the root cause is identified, identify one or more solutions.
Work to implement the solution(s). Ensure that all necessary processes or procedures are updated and training is provided.
Monitor the improvements and verify that the solution addressed the original business problem.
Goal, Question, Metric (GQM) Description
The goal, Question, Metric (GQM) is an approach developed in the early 1980s, piloted at the NASA Goddard Space Flight Center; it is used to derive useful measurements from one or more goals.
Goals are established based on an organization’s or team’s mission, vision, strategic goals, and improvement objectives.
One or more questions are identified for each goal to refine the goal into information needs.
One or more metrics are identified to answer each question.
Metrics are selected and related back to the goals to ensure that they measure goal attainment and progress.
One advantage of GQM is that it provides traceability between what is being measured and the goals that are important to an organization or a team.
This traceability focuses measurement activities on metrics that are useful and valuable and eliminates measurement overhead.
Knowing whether there is a return on investment for goals and initiatives creates a culture of continuous improvement and an entrepreneurial, “fail fast” mindset for individuals.
Employ a trained GQM facilitator to plan and manage GQM sessions.
Involve multiple levels of the organization to create measurable goals, the right questions, and useful metrics.
In order to be successful, be willing to invest in systems and tools that provide data that is needed, not just what is currently available.
Define the smallest set of metrics possible to measure achievement of the most important goals first.
Display data and progress using visual information management systems.
Do not create metrics that punish or embarrass individual performers (shaming is not an agile value).
Regularly inspect and adapt the measurement program to fail fast and continually improve.
Lean Coffee Description
Lean Coffee is an agile technique that allows for successful, collaborative meetings with minimal planning or agenda setting.
Other Stakeholders as needed
Agree on a basic theme for the session.
Attendees write topics to be discussed on sticky notes or cards.
Establish a personal or temporary Kanban board with “To Do,” “Doing,” and “Done” columns.
Introduce each topic.
Vote, and rank, each topic for discussion.
Prioritize the ideas by vote, and move the first to the “Doing” column.
Set a timer for five minutes, and timebox the discussion of each idea.
If the timer goes off, the group can vote for an extension for another five minutes.
When time runs out, and no one wishes to continue, move the idea to the “Done” column.
Record outcomes and decisions, and distribute to the relevant stakeholders.
Peer Reviews Description
The purpose of a peer review is to ensure that the highest quality is achieved, given the allotted timebox, prior to releasing a work product to the next stage in the process, or to the customer.
Product Owner (if stories are being reviewed)
Identify the work product for peer review.
Identify peer review participants.
Distribute content to be reviewed.
Confirm the review of work products.
Conduct peer review with invited reviewers.
Record defects, issues, and risks.
Add defects and issues to the backlog with an assignment to a specific team member.
Planning Poker Description
Planning Poker is an agile estimation technique that establishes relative sizing using story points and playing cards. Planning Poker solves the estimation problem by using an estimating game to size backlog items relative to one another.
The relative size of a backlog item is intentionally disconnected from the effort in hours to encourage the team to think in a different way: “roughly right” versus “accurately wrong” is the goal.
In Planning Poker, the agile team, working with a scrum master and the product owner, sizes each epic or user story as part of product backlog development or sprint planning. The product owner’s role is typically informational only, as they are not involved in the building of the actual product.
Review sprint or iteration backlog with the product owner.
For each story that has been presented by the product owner, discuss among the team to ensure that an understanding is reached.
The scrum master counts down from three, and team members each throw down a card that represents the number of points they believe that story to be.
The scrum master facilitates a discussion about why there are differences, ensuring each team member has a chance to present their point of view.
The team throws down another set of cards, based on the information they have just received from their teammates.
The scrum master facilitates the second round of discussions.
If a general consensus is not achieved, discussion continues, and one more round can be played.
At the end of three rounds, teams may choose to average the results of the third round or continue playing until a general consensus is reached.
Project (Team) Chartering Description
The Project (Team) Charter summarizes the project or team’s objectives, scope boundaries, behaviors, and cultural characteristics. The team collaborates to develop the Project (Team) Charter in order to define the common purpose they are working toward. Topics to be considered for inclusion are:
Agreements between the team and suppliers
Agreements between the team and internal service providers
Governance and self-organization guidelines
Roles and Accountabilities
Identify high-priority agile values or other organizational guidelines to adopt.
Hold a dedicated session to agree on mission, purpose, core values, potential obstacles, ground rules, and communications.
Capture information during this session to ensure that the source of the project charter is available to all team members.
Ensure that the project (team) charter is understood and subscribed to by all members of a team.
Post the charter in a visible location.
Plan how often the charter will be reviewed and updated after it has been established.
The purpose of a Training Retrospective is to periodically review how well training is working for a team, functional group, or organization. This retrospective should include all relevant stakeholders such as agile leaders, team members, trainers, mentors, and coaches.
Agile Means That We Collaborate Early and Often
The idea of working in small, cross-functional teams is central to several Agile methodologies. But, as with many other Agile practices, it is much easier to approach this as an operational change than as a cultural change.
In far too many cases, organizations simply add a few dotted lines to the org chart or implement an open-office plan without really thinking through why cross-functional collaboration is valuable to the organization and its customers, and what has impeded it in the past.
And therein lies the greatest challenge of this guiding principle: just because people are on a team together or in a meeting together does not necessarily mean that they are collaborating.
True collaboration requires openness, vulnerability, and the willingness to share ownership over ideas.
It requires asking a question before you know the answer and being prepared to receive an answer you did not expect. It is something that does not come easily for most organizations, no matter how much time people spend in meetings.
This is why our second guiding principle is to collaborate early and often, both within and beyond our teams.
Collaborating early means that we collaborate during upfront strategic conversations as well as downstream tactical ones, opening up the possibility of discovering new and unseen solutions.
Collaborating often means that we continue these conversations throughout the process of creating and delivering, ensuring that strategy and tactics remain aligned and giving us more opportunities to adjust course as needed.
For organizations in which collaboration between particular groups is a well-understood problem, describing the specific silos across which we need to work more closely is one way to specialize this principle for your particular needs.
You might want to say, for example, “We collaborate across functional roles,” or “We collaborate across product teams.”
For some organizations and teams, it might also be worth explicitly denoting what we mean by collaboration. For example, “We collaborate early and often by sharing works-in-progress and asking questions before we know the answer.”
Again, it is important for you to find the framing that speaks most directly to your own organization’s needs and goals.
Escaping the Second Law of Organizational Gravity
At times, the lack of connection and collaboration in even the most well-intentioned organizations can seem bewildering. Even when collaboration is codified in a company’s mission statement or operating principles, people still tend to default to working only with the people in their immediate orbit.
I call this the Second Law of Organizational Gravity: individuals in an organization will prioritize the work that they can complete most easily within the comfort of their own team or silo.
As with all our laws of organizational gravity, this is a force that is rarely named or seen in the open, but one that has an enormous impact on the way that modern organizations work.
Individuals in an organization will prioritize the work that they can complete most easily within the comfort of their own team or silo. Note how the gravitational field at the lower right pulls members of a single team closer to each other and farther away from their colleagues elsewhere in the organization.
The reasons why individuals might choose to prioritize the work that requires the least support from outside their team or silo are not terribly difficult to grasp.
Imagine that you are on the hook for delivering something that your boss has demanded be completely finished by a certain date at a certain time. You know that your deliverable would be stronger if you got input from different teams— but you also know that the people on those teams likely have their own priorities, their own objectives, and their own deadlines to worry about.
Even worse, they might undermine your work—or take credit for your work if it succeeds! Simply put, venture outside of your own team or silo is risky, and minimizing risk is a successful strategy in most modern organizations.
In many ways, Agile is designed to harness the power of this gravitational force by creating empowered, autonomous, and cross-functional teams.
If your immediate team consists of everybody whose work is required to create a successful customer experience, the work that is most important to your customers is more likely to be prioritized.
In practice, however, it is rarely either possible or advisable for a team to actually include every single person whose work touches a given product or project. And so the need to create a culture of collaboration across teams and silos persists even when an organization has formally reorganized itself into small, cross-functional teams.
Moving from a Report and Critique Culture to a Collaborative Culture
In far too many cases, people interested in bringing Agile to their teams or organizations feel that increasing collaboration is not possible without a formal reorganization, whether it is the reshuffling of individuals from functional teams into cross-functional teams;
Mayur Gupta, VP of growth and marketing at Spotify, described to me how even the Spotify model is less a question of org charts, and more a question of culture:
When people refer to the Spotify model, they’re usually talking about guilds, tribes, and blogs. But those are just rituals. I don’t believe that you break down barriers by changing reporting lines.
When you have a truly cross-functional team, reporting lines become irrelevant. The way you run the business, and the way you solve problems inherently has to be done cross-functionally.
As you keep going through your life and career, you realize that what truly drives these changes is culture. That to me is paramount—the culture of your organization. The culture of how you grow individuals, how you inspire your employee base, how you recognize your employee base.
That culture becomes truly cross-functional when you are agnostic of where you sit, and when you start to recognize collaboration as opposed to individual heroism. At the end of the day, we all want to be recognized for the work we do.
If recognition operates in silos or is only given to individuals, then that’s how individuals will seek recognition. We need to recognize teamwork and we need to acknowledge teamwork.
Even for Spotify itself, successful implementation of the Spotify model has less to do with the specifics of the frameworks and reporting structures the company has adopted, and more to do with the culture that it has cultivated.
For many organizations, there is a fundamental—if often unspoken—belief that working together is simply a waste of time and efficiency.
Even when these organizations adopt Agile practices, they have a difficult time imagining what a more collaborative culture might look like beyond “more meetings.” For these organizations, a fundamental cultural shift must take place: the shift from a report- and-critique culture to a collaborative culture.
A report-and-critique culture is one in which teams and functions do their own work and then hold meetings to tell other teams about that work. Those teams, in turn, are only able to offer inputs on something that has already been completed, resulting in contributions that feel more like a critique than collaboration.
For many organizations, this is the sum total of what “meetings” across teams and functions represent.
Some organizations develop a report-and-critique culture as a reaction to misaligned goals and incentives between teams. For example, one team might be held accountable for the number of new customers acquired through marketing efforts, while another team is held accountable for the average revenue earned per customer.
As the first team casts a wide net and brings in low-value customers, the second team’s success metric suffers. The resulting mistrust stifles collaboration and makes it all too easy for either team to blame the other if they fail to reach their respective goals.
More commonly, a report-and-critique culture emerges when individuals only reach out across teams and silos when there is an immediate, tactical dependency to be resolved.
This perpetuates the belief that other teams exist only to derail or complicate your own team’s work, leaving ample room for misunderstanding and little room for true collaboration.
Finally, a report-and-critique culture is often a simple product of the fact that people will generally prefer to share things that are finished, polished, and impressive—especially when sharing with people who might not be immediately familiar with the quality of their day-to-day work.
Shifting from a report-and-critique culture to a collaborative culture is no easy feat and, as with the adoption of Agile principles in general, more of an ongoing journey than a finite transformation.
But at its heart, this shift involves giving people the opportunity to experience collaboration as something that will help them achieve their goals, not something that will delay or derail them in achieving those goals.
Often, the best way to accelerate this shift is simply to begin reaching out to people from other parts of your organization and learning more about their particular goals and objectives—before you need something from them or have something finished and polished to share with them. Alan Bunce, a consultant and former marketing leader at organizations like IBM and
Salesforce.com: The Customer Success Platform To Grow Your Business, described to me how he was able to create a more collaborative culture by encouraging one-on-one relationships between individuals across functions and silos:
At one company where I worked, we had these weekly or bi-weekly product marketing and product management meetings. All 10 of our product managers and all six of our product marketers attended every meeting. There was always an agenda, and it was always useless. These meetings were torture, and you never really got anything out of them.
I try to avoid having those big meetings where there’s an agenda and somebody presents. At the next company where I worked, I agreed with my counterpart, the head of product management, that what we really needed was to develop strong one-on-one relationships between product marketers and product managers. You shouldn’t need to wait for the next meeting. You’re talking to each other informally all the time.
Note that many practitioners I have spoken to have a very different perspective about meetings without formal agendas. This, again, illustrates how different teams and organizations will need to take different steps to move toward a truly collaborative culture.
If, for example, your team is struggling with disorganized meetings that don’t offer any clear value, using formalized agendas to structure space for collaborative decision making might be an important step forward.
If you are working in an organization in which formal agendas are reinforcing the perception that something must be finished and polished before it can be shared, you might take a very different approach.
In either case, there are always opportunities to look beyond transactional and structured meetings and create more space for informal communication. It is often through these conversations that individuals from different teams discover opportunities to work together toward a shared set of goals.
Set expectations clearly
Regardless of whether you have a formalized agenda for a meeting, it is always helpful for people to know why you are asking for their time in the first place.
Beyond being clear about the decisions you seek to make, it is helpful to tell the individual people you are inviting why their particular perspective is important and valuable to you. This makes it clear that you are actively looking for their input and collaboration rather than simply checking a box that corresponds to their role or team.
Don’t call it a meeting!
For many modern organizations, “meeting” is nothing short of a dirty word. Though it might seem trivial, using a term like “hothouse” or “summit” can constitute an appreciable step toward helping people overcome the self-fulfilling belief that anything called a meeting will be a waste of time.
It’s a systems-level intervention, very much in line with Agile principles.
Smith explained that her approach was inspired largely by venture capital firms, who she observed take two critical steps to catalyze their investments: “finding and supporting what works (or is promising)” early and often, and “networking their networks” to accelerate that positive momentum.
Creative, committed, passionate people are solving challenges in their local communities. We can accelerate progress in more places by scouting to find these creative solutions or solutions-in-progress to tough problems that already exist. To scale, find, and share solutions with others working on the same challenges, use the Internet and bring teams together.
Here are a few steps that every organization can take to implement a scout-and-scale approach to their work:
Get in the habit of asking what work has already been done and who is doing it.
In every organization, there is some degree of “tribal knowledge” that people share informally but is not captured in a permanent or easily retrievable way.
One of the best ways to capture this knowledge is to dispel the assumption that if we haven’t heard about something, it doesn’t exist. Get in the habit of asking what’s already been done and by whom.
Questions like, “Have we tried this before?” or, “Who else in the organization is thinking about this same issue?” and even, “Are others outside our organization doing something relevant?” are great places to start.
Let your customer be the bridge between silos, products, or projects.
When scouting solutions from across the organization, don’t forget who you’re solving for.
Keep customer goals and needs front and centre, and you might discover unexpected opportunities to better serve your customers by making connections across functional or project-based teams.
Ask teams and individuals to share the customer insights that led them to their particular solutions, and let those insights lead the way as you look for opportunities to connect and scale the work that has already been done.
Network your networks!
One powerful way to put scout-and-scale into practice is to provide your colleagues with multiple forums to share knowledge across teams.
Drawing from the Spotify model, this might involve creating guilds in which people from across functions can share knowledge about common interests ranging from coffee to proprietary data analysis tools.
Or, drawing from the Scrum framework, this might involve regular meetings in which “ambassadors” from each project team share their progress.
Have a shared language like “scout-and-scale” that speaks to the power of collaboration beyond squishy and easy-to-dismiss terms.
Simply saying, “We should all collaborate with each other more” is often not enough to drive action. Scout-and-scale provides a great template for how you can use more specific and catchy language to generate interest in collaboration.
When we begin by asking what is already working, we give ourselves the opportunity to put more resources behind the solutions that are meeting the goals and needs of our customers.
Adopting a scout-and-scale approach is one way that collaboration can break us out of the company-centric assumption that our first step should be to pitch a big project, secure a budget, or build something that will impress our colleagues and managers.
Agile Practice Deep Dive: The Daily Stand-Up
The daily stand-up, or daily scrum, is the first step that many teams take toward adopting Agile practices, and with good reason.
This daily meeting provides a regularly scheduled opportunity for members of a team to align around their respective progress and their shared goals.
And because it clocks in at under 15 minutes, the daily stand-up can usually be fitted into a team’s existing schedule without feeling like an unreasonably large or disruptive ask.
The rules of the daily stand-up are fairly straightforward: every day, each member of the team stands up and shares information about the work they’re doing as it relates to the team’s goals. The entire meeting is to take no more than 15 minutes—a strict constraint that is reinforced by the fact that nobody is sitting down!
Within the Scrum framework, each member of a team is tasked with answering these three specific questions:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
For teams that are neither developing software nor working in sprints, these questions are often abstracted to the following:
What did I do yesterday that helped the team meet its goals?
What will I do today to help the team meet its goals?
Do I see any impediments that prevent me or the team from meeting our goals?
Many teams abstract this even further, simply asking its members, “What did you do yesterday, what will you do today, and do you have any blockers?”
The daily stand-up can seem almost trivially simple, but it provides a hands-on introduction to some very powerful Agile ideas. First, it provides a relatively low-stakes way to introduce the practice of time-boxing.
For many teams, it is unheard of for a 15-minute meeting to actually take 15 minutes. Once teams are accustomed to holding properly time-boxed daily stand-ups, they are often more comfortable applying the practice of time-boxing to longer meetings and meetings that involve people from outside of their immediate team.
Additionally, the daily stand-up introduces the idea of creating and protecting a regular cadence for communication. For many teams, synchronous team-wide meetings only occur when there is an immediate and transactional need for one.
Holding space for your entire team to interact with one another every day, even if there is no proverbial fire to put out, helps create a true sense of shared purpose and accountability around both day-to-day tasks and broader team goals.
Of course, there are also plenty of ways for a daily stand-up meeting to go awry. In companies with a report-and-critique culture, the question of “What are you doing toward the team’s goals” can feel like an accusation.
One product manager I worked with described the daily stand-up as the “What have you done for the company lately” meeting, a rote and fruitless exercise in which team members defensively spit out as much as they possibly can about their own individual work without listening to or interacting with their colleagues.
When you are truly practising Agile, you’re learning, starting to create your own things. It becomes reflexive. You keep going, you iterate, and you continue moving forward and living it. And once you get to that stage you never go back.
In other words, the daily stand-up is at its most impactful and sustainable when your team feels a sense of collective ownership over this practice. Here are a few steps that you can take to make sure that your daily stand-up meetings are actually adding value and encouraging collaboration:
Be clear about why you are holding the stand-up
As with any Agile practice, the daily stand-up is only useful if you and your team have a clear understanding of why you’re doing it in the first place. Take the time to discuss with your team what the purpose of this Agile practice might be, and be sure to tie it back to your guiding Agile principles and your organization or team’s specific needs.
For example, “We know that our organization is struggling to keep pace with our customers, and we have committed to the principle of collaborating early and often as a way to maximize the immediate impact of our customer research.
Treat the stand-up as a diagnostic
Because it is so simple and straightforward, the daily stand-up often becomes a powerful tool for diagnosing whether your team is stuck in report-and-critique mode or is building a truly collaborative culture.
If people on your team roll their eyes or miss meetings, don’t castigate them for not “doing Agile”—understand what isn’t working for them and talk about how you can address this together.
Change the questions
The three canonical questions of the daily stand-up meeting were designed to keep teams tactically synchronized and focused on their overall goals. But the needs of every team are different, and nearly every Agile practitioner I know has at some point changed these questions to better reflect the needs of their team.
Some have changed them to more explicitly encourage collaboration, like “What opportunities are there for your colleagues to help you today?” Some have gone so far as to ask much more personal questions like, “How much energy do you have today?” to address disconnects between team members’ energy and capacity.
Making changes to any Agile practices, including the daily stand-up, should be done in the name of living up to your Agile principles and achieving your team or organization’s specific goals.
If you and your team are having trouble finding value in the daily stand-up, treat it as a learning opportunity rather than a procedural failure. Have a conversation with your team to find out what value people would like to get out of this practice and why they feel that they are not currently getting that value.
Agree upon small changes you can make, one at a time, and reflect openly on whether they are helping you achieve your goals.
Because the daily stand-up occurs every day, and because it is so often the first step that a team takes toward adopting Agile practices, it makes for a great opportunity to model a collaborative and principles-first approach to Agile in general.
You Might Be on the Right Track If:
People from different teams and functions are spending time together outside of formally scheduled, transactional meetings.
As we have discussed throughout this blog, actually following our guiding principle of collaboration is much more a question of culture than it is a question of org charts or calendar invites.
A lot of important things can happen when people from across teams and functions are spending time together informally during meals, coffee breaks, and after-work activities.
This does not mean that everybody should be, or should feel pressure to be, best friends. But the comfort and rapport that people develop through these informal interactions can have a tremendously positive effect on both an organization’s culture and the quality of its work.
To keep the momentum going around this, you might want to:
Make sure that organizational and team leaders are present during informal events like company lunches to avoid the implicit suggestion that people should be focused on “more important work.”
Collaboration is taking place around upstream strategy as well as downstream tactics
In too many cases, “collaboration” happens only when the high-level strategic decisions for a project have already been made.
For example, a broad group might be consulted on a specific wording choice for an advertising campaign or the specific shade of red to be used in interface design, but the overall shape and objectives of the campaign or product are already set in stone.
This is a classic symptom of an organization that is going through the motions of collaboration but still getting tied down by the Second Law of Organizational
Gravity. When abroad and open conversation about a new idea is seen as an opportunity to make that idea better, not a threat to that idea’s success or survival, an organization is well on its way to becoming more truly collaborative.
To keep the momentum going around this, you might want to:
Hold open “demo days” during which teams can show off works in progress before they are finished and polished.
Ask project leads to co-create a plan for how their respective projects will work together to meet customer needs and goals before any projects are approved or budgeted.
Start each new project with a cross-functional work plan that explicitly includes inflexion points for getting feedback from across the organization.
To keep the momentum going around this, you might want to:
Run ideas past individuals from across the organization when they are still in a relatively early form to incorporate diverse perspectives and create a shared sense of ownership.
Recognize and incentivize collaborative efforts, and/or give employees ways to acknowledge and bring attention to one another’s contributions.
Conduct regular meetings during which people from different teams and functions can share works-in-progress, to incorporate perspectives and expertise from across the organization.
Anybody on your team can take a sick day without work grinding to a halt One classic sign of a high-performing Agile team is that the team can continue to function in the absence of any of its individual members. This is not to say that multiple members of a team need to be experts in the same skill;
I have worked with many Agile product teams, for example, that include only one engineer capable of writing a particular kind of code. But when a team is in the practice of collaborating early and often, the members of that team are able to regroup, adapt, and keep things moving forward.
To keep the momentum going around this, you might want to:
Hold a daily stand-up meeting at the beginning of each day, giving your team the opportunity to regroup and adapt as needed.
Provide opportunities for members of your team to share their skills and knowledge with one another. This could involve pairing team members with different skills to work on the same thing, or hosting informal gatherings during which team members can share their skills with the group at large.
“Trade” a member of your team with a member of another team for a day or a week to expand your team’s skills and knowledge beyond its immediate boundaries.
You Might Be Going Astray If:
Your meetings feel like elementary school blog reports
For organizations that have not evolved past a report-and-critique culture, meetings can feel more like elementary school blog reports than opportunities to collaboratively make important decisions.
If your meetings involve taking turns spouting off the most defensible thing you can conjure while everybody else dozes off or dreads their turn in front of the room, you’ve got some work to do.
If this is happening, you might want to:
Acknowledge that the way you are currently holding meetings is not working and ask for the help and support of your colleagues in making your meetings better.
Sometimes, just opening up this conversation is enough to begin steering things in the right direction and create a shared sense of accountability around meetings instead of treating them like something that is being forced on everybody.
Impose strict time limits on your meetings, and enforce them ruthlessly. When people realize that their time is truly limited, they are more likely to make the most of it. Note that it generally takes at least three to four meetings for people to get used to this and actually begin managing their time differently.
Try making your meetings optional and see who shows up. This will help you to understand who is currently getting value from a given meeting. Work with those people to understand why they find the meeting valuable and what you can do collectively to extend that value to others.
Everything shared between teams is finished and polished
Everybody wants to do a good job, and presenting something that is finished, polished, and impressive often feels like a surefire way to boost your status in an organization. But finished and polished things often send the wrong message: “I want you to be impressed by this, but I don’t really want you to participate.”
Even worse, when feedback is given on something that is polished and finished, it is often met with heavy sighs and huffs of, “Well, this is already pretty much finished,” or, “My boss already signed off on this, I can’t really change anything.”
If this is happening, you might want to:
Have a “no PowerPoints” rule when new ideas and initiatives are being discussed, an idea popularized by Jeff Bezos at Amazon. The time that goes into finishing and polishing a PowerPoint presentation often has nothing to do with the quality of the ideas being presented, and it certainly offers no value to the customer or end user.
Conduct short, high-energy structured brainstorming sessions with people from multiple teams and functions to think about how a particular customer need or goal might be addressed. The tools and practices commonly associated with Design Thinking can be particularly valuable here.
Put new ideas and works-in-progress in a public and highly visible space to invite serendipitous feedback from anybody who happens to be present.
Your inbox is full of requests for asynchronous feedback
Talking through works-in-progress synchronously can be awkward, uncomfortable, and challenging. It is much easier to simply send an email and say, “Please send me your feedback.”
Your bases are covered in that you technically asked for feedback, and you can add as many people as you want to the distribution with minimal additional time expenditure on your part.
But for each person you chose to copy in the thread, there is now a new task on their desk that they must process, prioritize, and find time to address.
If this is happening, you might want to:
Be clear about who you will ask for feedback, and why. You can use a formalized framework such as a RACI (Responsible, Accountable, Consulted, Informed)
Matrix, or just keep an informal list and make sure each person on that list knows what you expect from them and why.
Reply to requests for asynchronous feedback with an offer to meet up for 10 minutes and provide your feedback in person. If the person who emailed you doesn’t have the time to spare, they likely were not all that interested in your feedback in the first place.
Building a Culture of Collaboration
For people whose calendars are already packed with tedious and seemingly unnecessary meetings, the idea of more collaboration can seem wasteful and counterproductive. But truly building a culture of collaboration is about much more than sitting in a room while somebody tells you about the work they just finished.
Making the choice to err on the side of openness—to share things before they are finished and polished, and to ask for input while that input can still inform a project’s overall shape and direction—can contribute to a truly collaborative culture.
When we work toward developing such a culture, the value we deliver to our customers is not bounded by the gaps and silos in our org chart.
Escaping the Third Law of Organizational Gravity
Flexibility is one of the most obvious and well-understood reasons why organizations are drawn to Agile in the first place. However, most organizations still struggle to actually change course in substantial ways, even when numerous people within an organization—including senior leaders—agree that adaptability is critical for that organization’s success.
The reason for this can largely be attributed to what I call the Third Law of Organizational Gravity: a project in motion will stay in motion unless acted upon by the senior-most person who approved it.
In other words, if a particular project, initiative, or product idea has the sign-off of a VP or C-level executive, it is likely to continue apace even if it is clearly not going to meet the desired customer need or company goal.
After all, what’s the point of bringing bad news to your superiors when they will likely be held accountable for a project’s perhaps-inevitable failure?
A project in motion will stay in motion unless acted upon by the senior-most person who approved it.
Returning to our First Law of Organizational Gravity, the senior leaders who would need to intervene are often the farthest removed from direct interaction with customers.
This creates a self-perpetuating system in which it is all but impossible for organizations to adjust course based on new learnings from their customers.
By the time senior leaders get the feedback that should result in a course change, it has usually been scrubbed and sanitized to the point where it reads more like, “Great job, boss!”
This dynamic explains why people in organizations often continue to work on projects that they know are not going to succeed. It also helps to explain why embarrassingly bad marketing campaigns and #socialmediafails persist in this era of rapid customer feedback.
In the calculus of organizational politics, public embarrassment can often seem less risky than telling your boss that something they signed off on is a bad idea.
Personal courage is certainly one way that individuals can work against this law of organizational gravity—but it is not enough. The only way to ensure that change will happen is to make change part of your process.
In other words, those executives signing off on projects need to understand that making room for change is an inextricable part of the projects themselves. In doing so, adjusting course feels more like a commendable example of foresight, and less like a regrettable instance of failure.
We can’t always get an organization to stop doing years-long planning cycles. But we can get them to add a quarterly business review. It’s pretty simple—you start reflecting on how you did last quarter; then you bring in additional information that you want people to know.
Maybe there’s a new Gartner study about how the market is changing, new regulatory requirements, new initiatives from company leaders, or new information about our customers.
Bring that information into the room, describe what you’ve learned since the last time you discussed your plans, and then look ahead. Can you look at some of your initiatives and, based on what you now know, declare them “done enough”?
If you’re 85% of the way toward achieving your goal with one initiative, can you strategically shift your resources to another initiative where you’re only 20% done?
With this approach, we were able to get the whole bank on a cadence of quarterly planning events. It gave them a way to address all kinds of things, like running through audits with thousands of remediations that would have previously ground the bank to a halt.
Instead, they were able to pull the work apart in these quarterly planning events, realize what they could and could not get done, and knock off the highest-priority items. We could have a conversation about which features were customer-delighters, and what the scope of these features might be.
And incorporating language that is already well understood within an organization can help make new ideas and practices feel more approachable and applicable, even as they pose a substantial challenge to business as usual.
The Paradox of Agile
At the heart of most Agile methodologies is the somewhat paradoxical idea that a regular cadence creates more room for flexibility. This is because a fixed and finite cadence—makes responding to change a regular part of the way we work, not a challenge to the way we work.
When I began learning about Agile, I was concerned that a more fixed and frequent structure would make my team slower and less responsive.
Committing to getting something done every two weeks felt much more rigid and regimented than planning to get something done roughly every couple of months or, even better, “whenever it’s good enough.”
To my surprise and delight, though, a shorter fixed cadence actually resulted in my team making bolder and more exciting choices.
We were able to build and test lightweight prototypes for new product directions, knowing that we could always abandon those directions if we learned that they were not adding value to our customers.
And we were able to better plan around the quarterly and yearly goals of the organization knowing that we had the power to adjust course every couple of weeks if we did not appear to be hitting those goals.
Sure enough, nearly all organizations operate under plans that extend beyond the two-week increments of a standard Agile sprint, whether it is a quarterly product roadmap at a small technology startup or a yearly budget for a large enterprise.
Agile practitioners often see any long-term cadence as a threat to true agility, and eventually, declare that being truly Agile is “just not possible in an organization this large and bureaucratic.”
The Customer Success Platform To Grow Your Business, described to me how the most successful Agile practitioners seek out a balance between long-term planning and short-term adjustment:
I’ve never worked at a place, no matter how “Agile,” where you didn’t start the year by thinking about what your budget’s going to be. Especially if you’re working at companies that are gearing up to go public, it’s not like you can say “Oh, we don’t know how much we’re going to spend—we’re Agile!”
The way budgeting cycles are done, sales teams and executives think about what they think they can hit or what their targets ought to be for the year. Then, marketing’s budget is backed out of that.
Agile often carries this sense of, “Hey, at any moment we can do anything”— the reality is you can’t! You have a budget. And very quickly that budget starts to get carved up. That still leaves a lot of room for agility, but it’s by no means a blank sheet of paper. You need to strike a balance between long-term and off-the-cuff.
What that balance looks like will depend a lot on how an organization uses those long-term cycles. Are they chiselled in stone, or are they more guidelines, with an understanding, there will be some adjustment?
If anything, it means that we must be even more proactive and disciplined about establishing shorter cadences that we can use to keep our team’s work aligned with those longer-term plans—and to incorporate the new things we learn from our customers along the way.
Here are a few steps you can take to keep your team’s short-term cadences aligned with long-term goals and planning structures:
List out the fixed cadences of your organization and work with, not against, them
Does your organization have a yearly budgeting cycle? A two-year strategic planning cycle? A quarterly goal-setting process? Draw them all out on a sheet of paper and write down what is actually decided upon in each cycle, who is making those decisions, and what they expect as a result.
Then, think about how you can build a shorter cadence around these cycles that create more room for flexibility while respecting and accommodating organizational planning cycles that are unlikely to change.
When we are planning only in long-term cycles, change of any kind can seem like a demand for frustrating rework. Adding shorter-term cycles allows us more time to get out ahead of changes to our initial plan and reconcile new information with our longer-term goals. We can draw attention to this newfound flexibility by celebrating change rather than decrying it.
In other words, if we realize two short cycles into a much longer cycle that we have been on the wrong track, rather than saying, “Crap, there goes four weeks of work down the drain,” we can say, “We are so lucky that we caught this now and we can adjust course while there’s still time for us to hit our quarterly goals.”
Focus on what’s possible
The tension between short-term agility and long-term planning is one that never fully goes away, and inevitably creates situations in which your team cannot do the exact thing it wants to do at the exact time it wants to do so.
But blaming the organization at large for not being as “Agile” as it should be is likely only to hurt your team’s morale and motivation. Instead, focus on what can be done given the real-world constraints of your organization.
In many cases, embracing this do-what’s-possible approach can actually help make long-term planning cycles more useful by clarifying their purpose and the expectations they create.
As teams and organizations work toward finding the right balance of short-term and long-term planning, they are better equipped to understand and appreciate the value that both can offer.
The Double-Edged Sword of Experimentation
Inevitably, planning for uncertainty means making our best guess and moving forward before we know that everything we do will be a success.
In many Agile and Agile-adjacent approaches, particularly the Lean Startup world, “experimentation” is often framed as the best way for teams and organizations to validate new product ideas and directions in a fast-changing world.
Real-life organizations, unfortunately, do not provide the pristine and sterile environs of a well-maintained laboratory.
The idea of experimentation is an important one to bring to an organization, but it can also be a dangerous one if it imparts a sense of scientific certainty that ultimately contradicts the messy and fast-changing nature of the real world.
At its best, experimentation can help us understand the uncertainty out there in the world, but it can never eliminate that uncertainty.
For teams and individuals looking to make definitively correct decisions, this can be a tough pill to swallow. And, sure enough, there are certain types of decisions that are easier to definitively prove out with an experiment than others.
Deciding, for example, whether to make the “Home” button on a web page round or square would not be a particularly difficult thing to prove out via quantitative A/B testing.
But suppose that you need to decide whether an entirely new line of business is worth getting into or whether an existing product will sink or swim when introduced to an entirely new market.
While it is certainly possible—and worthwhile—to design an experiment that would help you answer these questions, no such experiment would give you the same sense of irrefutable and scientific certainty as that simple A/B test.
In theory, this should mean that teams and organizations wind up spending more time on the more difficult and ambiguous experiments that validate complex, market-based decisions.
But in practice, it often means the opposite: teams and organizations wind up spending a disproportionate amount of time on the experiments that are easiest to validate in absolute quantitative terms, even if these are the least impactful for the business.
When my business partners and I are working with organizations, we often ask them to map out the experiments they are running on a quadrille we call Integrated
It’s also worth noting that people can get fetishistic about experimentation pretty easily, to the detriment of its purpose. Sometimes, an experiment can be much more about qualitative signals; for example, the way people start using a phrase that’s in your marketing materials.
This approach is officially called “artefact analysis.” If we change the wording on our website to “inquiries,” for example, will the content of the emails we receive start to be different? We don’t always have a number, but we know what we’re looking for and why we’re looking.
As this story illustrates, the easiest things to test and measure are not always the most important things to test and measure.
When we begin by asking the questions that are most important to our business and our customers, not the questions that seem easiest to answer with a quantitative experiment, we are being true to the complexity and uncertainty of the world around us.
Agile Is Uncertain, Too
Perhaps the most common antipattern I’ve seen in organizations seeking to implement Agile practices goes a little something like this: “We understand that the world changes quickly, so we are going to implement a set of Agile practices…that are guaranteed to work forever and that we will never need to change.”
Planning for uncertainty in our organizations also means planning for uncertainty in the way we approach Agile—which can be very challenging for organizations.
To navigate this change, teams and organizations must take shared ownership of the processes they use, and build enough trust and transparency to speak candidly about what is working for them, what is not working for them, and why.
This is often difficult to accomplish when Agile is seen as simply a mandate that comes down from on high or is brought in by an army of external consultants. Even when a team of well-intentioned practitioners is driving the adoption of their own
Agile practices, taking time to reflect on and refine those practices can prove challenging. Abhishek Gupta, an engineering manager who has worked with companies like Apple and American Express, described to me how opening a conversation about the goals of a team’s Agile practices can lead to difficult but important changes to that team’s routines and rituals:
One big challenge with Agile is that it becomes a set of things you need to do, without an understanding of the “why.” This is made even worse when Agile is treated as a silver bullet.
“Our projects will be great because we’re doing Agile!” That doesn’t translate if the spirit isn’t there. For people who deeply care about product quality, Agile is a means, not an end.
To confuse the process and the outcome is at the core of the problem here. If you don’t care about product quality, if you don’t care about delivering value to your customers, then Agile won’t save you.
I worked with one team that had been “doing Agile” for a while when I started working with them. I asked them, “Is this something you see as valuable?” And the initial responses I got were, “Oh yes, very, very valuable.”
So for two months, I attended their Agile meetings to see what was working well for them. Every meeting was a similar thing; show off your tickets in [software development tool] Jira, say what are you working on, is it done, is it not done.
The team was much more focused on closing actual tickets than they were on understanding the impact of the work they were doing; it was a lot of process management without giving much thought to actual outcomes. In other words, it was a lot of busywork.
So, after a few months, I had to say to the team, “How is this actually useful to you?” I had a lot of one-on-one meetings with engineers asking for this kind of candid feedback.
And what I heard was that they found it useful to not have to work on too many things at once, to be able to know what they were working on, and have that kind of focus.
So we talked about how we could retain that focus, but bring in more big-picture, directional thinking to make sure that focus was understood through the value we were creating for our customers.
This meant stepping away from a lot of by-the-blog Agile rituals, and asking as a team, “How can we work in a way that best achieves the outcomes we want for ourselves and our customers?”
Indeed, truly embracing the Agile principle of planning for uncertainty means that we must regularly ask our teams that very question, and be open to our answer changing as our goals, our teams, and our customers change.
In most cases, this eventually involves giving up the sense of comfort and safety that comes from doing Agile “by the blog” and finding the particular set of practices that works best for the individuals on our team.
This can be a scary step, but it is worth remembering that the set of practices and frameworks that we now call Agile were themselves developed through trial and error by practitioners before the word “Agile” was ever used to describe them.
When we understand our organizational needs and we follow our guiding principles, we open ourselves up to discovering new ways of working, and we empower our teams to feel ownership over them.