What is Agile (The Complete Guide 2019)

What is Agile

What is Agile 

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.

 

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.

 

Why Agile Matters

One hundred percent of the organizations I work with have expressed an interest in “going agile,” if they have not already done so. This is a strategic decision that has deep-rooted cultural implications and should not be taken lightly. Many leaders do not realize the extent to which they have to change the way they behave.

 

There are several reasons why an organization should transition to a model that is agile and self-organizing:

Agile frameworks reduce the cost of failure. It is conventional wisdom in the technology industry that failure is inevitable, with many companies seeing failure rates greater than fifty percent.

 

Research conducted by organizations such as the Project Management Institute and the Software Engineering Institute has consistently confirmed high failure rates, so it makes sense to seek solutions that assume a low level of early failure and to simply reduce its cost.

 

Failure is not just an option; it should be expected. A foundational premise of agile is the acknowledgment that early failure is normal, and we should plan to fail fast and learn as much as we can.

 

This reduces a project’s cost while allowing teams to redirect efforts toward a more successful approach through the use of experimentation, retrospectives, and short, time-boxed iterations.

 

Quality professionals will recognize this as an application of W. Edwards Deming’s “plan-do-check-act” framework of continuous improvement applied in short iterations.

 

Agile methods deliver business value to end users more quickly. Value is delivered more quickly with an iterative and incremental delivery approach due to low-value features being de-prioritized or discarded, freeing up valuable resources to focus on the high-priority needs of the customer.

 

Self-organization pushes decision making downward, freeing leaders to focus on strategy. For decades, the technology industry has explored ways to push decisions downward. Agile frameworks finally provide a model that can make that a reality, if only leaders are willing to accept their role as enablers rather than task managers.

 

A successful agile team requires minimal oversight, makes day-to-day operational decisions, collaborates with business customers, and delivers business value without the need for continuous management intervention.

 

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.

Out of more than two hundred companies assessed by AgileCxO and its partners:

  • More than 90 percent 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 behaviors were expected in order to achieve sustainable agility.

 

Agile Performance Holarchy and CMMI assessment results performed by AgileCxO and Transformation Partners 2010–2018.

 

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.

 

This friction, often manifesting itself as “Scrummerfall” or “ScrumBut” (“we’re agile, but…”), corrupts and degrades the very performance that agile leaders are seeking to achieve.

 

Jim Bouchard, the author of The Sensei Leader, sums it up: “Don’t even attempt to transform your organization until you can transform yourself.”

 

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 artifacts 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 behaviors, 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 behaviors 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, xp, 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 behaviors and habits. It is not an agile maturity model or a process, but an operating system for sustainable agility.

 

Agile Agreement Description

An agile agreement is a contract that exists between an agile organization and an agile supplier. While entering into contracts is not new, aligning supplier contracts with agile product development is a contemporary concept.

 

A traditional supplier contract is a low-trust, command-and-control artifact that relies on milestones and deliverables to manage the contract and process payment.

 

An agile agreement is different in that it requires a high-trust, iterative, and incremental approach to supplier management. An agile agreement defines the agile terms and conditions for both parties, the fixed product development time period, and the variable scope of work that the supplier will perform.

 

Typical Roles

  • Agile Leader
  • Agile Supplier
  • Procurement Department
  • Product Owner

 

Desired Behaviors

1. Understand agile values and embed them in the agile agreement.

2. Negotiate with the agile supplier, giving consideration to the following:

  • a. Transparency
  • b. Collaboration
  • c. Failing fast
  • d. Iterative and incremental delivery
  • e. Risk
  • f. Stakeholder Engagement
  • g. Scope
  • h. Release schedule

 

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.

 

Agile Digs Description

Agile digs describe the physical or virtual workspace that a leader provides for an agile team. Agile digs is a work environment that aligns with agile values such as collaboration and visibility.

 

To promote collaboration, the workspace enables team members to talk freely, see one another, and gather together in common spaces. To enable visibility, agile digs include wall space, whiteboards, and information radiators.

 

The ideal agile digs environment is a mixed-media space that allows for team collaboration, customer engagement, and individual work.

 

Leaders should discuss environmental requirements with each team to determine what works for them, and let teams determine the best solutions. Leaders can then implement and guide improvements to ensure the best environment for each team.

Typical Roles

  • Agile Leader
  • Agile Team
  • Facilities Manager

 

Desired Behaviors

1. Review the current physical space and validate that it reflects the following values:

  • a. Collaboration
  • b. Focus
  • c. Transparency
  • d. Visibility

2. Seek input from teams for their desired work environment.

 

3. Identify any impediments in the current work environment, for example, facilities policies, noise, furniture, physical space.

 

4. Prioritize workspace improvements, with the team’s input, based on value and constraints, for example, cost, time, building, furniture.

 

5. Determine the required visual information management tools, for example, whiteboards, information radiators, screens, and signs.

 

6. Make iterative and incremental changes to the team’s agile digs.

 

7. 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.

 

It is important to carefully analyze and select an agile partner who aligns with your organization. In order to make an informed decision, start with reviewing the organizational agile values and identifying criteria that must be met.

 

Next, conduct research to identify multiple companies that can be evaluated. Last, ensure that key stakeholders are included in making a final selection.

 

Desired Behaviors

1. Review project, product, or service requirements for an agile partner.

2. Determine what criteria must be met for selection. Criteria should be weighted as necessary, and evaluation of agile values should be considered.

3. Select which qualitative or quantitative method will be used to make the selection.

4. Identify multiple agile partners to be considered.

5. Compare agile partners against the criteria. If appropriate, request a demonstration or observe the partners in action to collect performance data.

6. Collaborate with key stakeholders to review comparison results.

7. Select an agile partner.

8. Develop and execute an agile agreement.

 

All Hands Raised Description

The purpose of All Hands Raised is for formal and informal leaders to share goals and objectives with teams and functional groups, and more importantly, receive feedback and proactive acknowledgment.

 

As the number and size of teams increase, All Hands Raised provides a structured, yet agile, framework for the sharing of vision and goals, responding to direct questions, and listening to the voice of the organization.

 

The All Hands Raised also helps prevent the corporate version of the “telephone game” wherein important messaging is diluted and transformed beyond recognition.

Typical Roles

  • Agile Leader
  • Agile Team
  • Product Owner
  • Scrum Master
  • Program Manager
  • Agile Partner
  • Business Customer

 

Desired Behaviors

  • 1. Develop a regular schedule for All Hands Raised events to be held at least biannually.
  • 2. Request input from teams prior to the event, including what teams need to be successful, and impediments they are experiencing.
  • 3. Meet in a common area that allows teams to see and hear leadership directly.
  • 4. Do not try to solve problems during the All Hands Raised meeting. Use it simply to communicate information and listen.
  • 5. Create a backlog of ideas and improvement suggestions gathered at the meeting.
  • 6. Have fun and get to know your organization!

 

The arc of Conversation Description

The Arc of Conversation is a communication framework used to resolve a concern or overcome an impediment. It involves coaching and active listening from one party and honest, direct communication from the other party.

 

The key to the art of conversation is for the “coach” to provide a comfortable environment for the “coachee” to speak their mind. The desired results of this communication framework are a common understanding of the issues, identification of possible solutions, and a shared accountability for the resulting actions.

 

Typical Roles

  • Coach
  • Coachee
  • Scrum Master
  • Team Member

 

Desired Behaviors

1. Select a neutral, private location for the conversation to take place.

2. Keep the conversation positive.

3. Keep moving forward, and do not dwell on any one comment or issue.

4. Beginning: Start the conversation

  • a. Open the conversation with words and body language that create a comfortable space.
  • b. Invite coachee to express their concerns openly without judgment or consequences.
  • c. Provide room for the coachee to speak, vent, and explain.
  • d. Practice active listening and empathy.

5. Middle: Ask questions

  • a. Ask the coachee questions that inspire thought and insight.
  • b. Ask questions that help the coachee to reach their own conclusions without leading them to predetermined outcomes.
  • c. Do not attempt to solve the problem at this stage of the conversation.

6. End: Support the outcome

  • a. Once the coachee has chosen the action to take, support them by defining accountabilities for any actions to be taken.
  • b. Thank the coachee for their trust and openness, and invite them to participate in similar conversations in the future.

 

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.

 

Typical Roles

  • Team Member
  • Chief Engineer
  • Software Architect

 

Desired Behaviors

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 the 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.

 

Backlog Grooming Description

Backlog grooming (sometimes called story-time) is a common technique used by product owners and teams to clarify, size, and prioritize the backlog of epics and user stories before and during a sprint.

 

The product owner has accountability for the product backlog and engages in regular, collaborative discussions with the agile team to review and revise it.

 

The agile team supports backlog grooming by providing knowledge of the product or service being developed and the relative size of the epics and user stories in the backlog. New epics and user stories may emerge as a result of backlog grooming.

 

It is the responsibility of the product owner to capture these within the product backlog along with their acceptance criteria.

 

Backlog grooming typically includes a negotiation between the product owner and the agile team on which user stories will be added, removed, or revised. The user stories at the top of the backlog are typically included in the next sprint or iteration.

 

Additional backlogs, other than the product backlog, may be groomed to prioritize work items related to continuous improvement or non-product-related activities. In these cases, the stakeholders and frequency of backlog grooming may vary.

 

Typical Roles

  • Agile Team
  • Business SME (subject matter expert)
  • Product Owner

 

Desired Behaviors

1. Create the initial product backlog by collecting and documenting epics and/or user stories associated with the desired product.

 

2. Sequence the user stories in the backlog based on business value and priority. The highest priority user stories are at the top of the backlog, and the lowest priority user stories are at the bottom.

 

3. Review and evaluate the user stories (product owner and agile team) using a defined set of quality criteria (e.g., INVEST (Independent, Negotiable, Valuable, Estimable, Sized, and Testable)).

 

4. Identify user stories that do not meet the criteria and update them accordingly.

5. Establish or update traceability between epics, user stories, and child user stories.

 

6. If backlog grooming is occurring mid-sprint, identify the stories that are most likely to be included in the upcoming sprint.

 

Best Practices Board Description

A Best Practices Board displays the best ideas, work products, and lessons learned from one or more agile teams, functional group, or manager for the benefit of the entire agile community. Best practices are harvested from retrospectives conducted by agile teams, functional groups, and the enterprise.

 

Defined criteria are used to select best practices that are truly “best in class.” Someone is assigned the accountability for posting and maintaining best practices on a physical or virtual board.

 

The Best Practices Board is located in an area that is accessible to all members of the agile community. This could be a whiteboard in a common area, a filterable list in a tool or wiki page, or a large digital screen in each team area.

 

Typical Roles

  • Agile Leader
  • Team Member
  • Scrum Master

 

Desired Behaviors

1. Determine optimal locations for Best Practices Boards. Ensure that they are in common areas where all teams and groups can access them.

 

2. Assign at least one person with the role and accountability for updating each Best Practices Board.

 

3. Communicate the criteria for best practices to all team members and ensure that they are understood.

 

4. Develop expectations for when best practices are shared, and at what frequency.

 

5. Ensure that all team members review the relevant Best Practices Boards prior to each project kickoff.

 

6. Monitor Best Practices Boards to ensure that they meet the established criteria, contain current information and are used by projects and groups.

7. Team members know where the Best Practices Board is located, and they review it periodically and when initiating new projects.

 

Big Room Planning / Release Zero Description

Big Room Planning (Scaled Agile Framework), sometimes called Release Zero (Agile CMMI), is a broadly attended, intensely focused stakeholder event, often lasting for two days or more, where long-term planning, interdependency identification, systems learning, organizational architecture, and the performance and planning framework for a successful program is established.

 

Typical Roles

  • Program Sponsor(s)
  • Agile Leader(s)
  • Team Members
  • Scrum Master (s)
  • Product Owner(s)
  • Systems Architect(s)

 

Marketing Team

Business Development Team Desired Behaviors

On your mark…

1. Prepare for the event with a robust value stream/business process mapping.

 

2. Develop a draft for an organizational structure that supports and promotes agile values. This could include governance infrastructure that supports self-organization and relentless, continuous improvement; and a tool-chain that supports as much automation as can be afforded by the organization.

 

3. Explore and document the organizational capacity and constraints that will impact the program using available productivity data.

Get set…

1. Identify, train, and coach potential leaders at all levels.

2. Ensure all participants and stakeholders, especially leaders, are keenly aware of agile values, frameworks, and techniques, and understand the value of embracing an agile organizational architecture.

 

Brainstorming Description

Brainstorming is a group discussion technique used to generate new ideas or solutions related to a goal or a problem. A brainstorming session has a facilitator who welcomes all ideas and records them as they are offered.

 

Participants quickly and spontaneously state their ideas in a manner that evokes kernels of corn being popped. The group avoids evaluating or critiquing the ideas during the brainstorming session.

 

The facilitator helps the group to avoid planning or determining how the ideas will be implemented. Brainstorming sessions may be time-boxed or terminated when there are no more ideas to offer (or kernels of corn to pop). For a successful brainstorming session, establish ground rules such as:

  • Check all titles and authorities at the door.
  • Set duration of the brainstorming session.
  • Allow no solution engineering, only idea generation.

 

Define the follow-up process.

  1. Typical Roles
  2. Agile Leader
  3. Agile Team
  4. Scrum Master
  5. Product Owner
  6. SME

 

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.

 

Burn Down Chart Description

A burndown chart is an information radiator that visually depicts a “value trajectory” of the sprint/iteration.

 

Based on the number of story points an agile team is historically able to “burn down” during each sprint (“velocity”), the burndown chart helps the product owner, agile team, and leadership to understand whether or not they will deliver the desired business value and functionality that was identified in the forecast during sprint/iteration planning.

 

A burndown chart can be used to monitor value delivered during a sprint or a release. A sprint burndown chart visually depicts the value delivered, and what is remaining in the forecast for the current sprint/iteration.

 

Agile teams that are engaged in multi-sprint releases may also use a release burndown chart to depict progress across all sprints in the release.

 

Release burndown charts are useful for product owners and leadership to understand overall business value delivered, but they require agile teams to have consistent membership and fixed sprint duration for all sprints in the release.

 

Agile teams may also use the burnup chart, which depicts similar data but is oriented toward what is yet to be completed rather than what has been delivered.

 

Typical Roles

  • Agile Leader
  • Product Owner
  • Agile Team

 

Desired Behaviors

1. The source for the story points on the y-axis (vertical axis) in the burndown chart comes from the sprint forecast. This is the total number of story points for the user stories that the agile team committed to for this sprint.

2. Use story points, not hours or days, to indicate value delivered or work accomplished.

3. Update the burndown chart at the end of each day, or during the daily stand-up meeting.

4. Place the duration of the sprint/iteration along the x-axis (horizontal axis) in the burndown chart.

5. Use the burndown chart throughout the sprint to understand how much work (or value) the agile team has accomplished so far and how much work (or value) remains to be done.

 

Confirmation Description

User stories have three critical components often called the 3Cs: card, conversation, and confirmation. User stories are often written on cards or a digital equivalent. The card does not contain all the information but is a reminder of what the story is about for the requirements discovery and backlog grooming ceremony.

 

The detail about each requirement, epic, or story is communicated from the product owner to the agile team through conversation that involves an exchange of views, scenarios, and operational workflow. The product owner typically defines the confirmation, or acceptance criteria, directly before user stories are selected for each sprint.

 

Communication of the confirmation criteria to the agile team ensures that the team and the product owner have a shared understanding of the product’s features and functions.

 

The product owner may also capture confirmation criteria in acceptance tests that are performed for each user story. When the acceptance tests yield passing results, it confirms to the customer that the associated user story is truly done.

 

Typical Roles

  • Scrum Team
  • Product Owner
  • Stakeholder
  • Scrum Master

 

Desired Behaviors

1. Specific acceptance criteria (definition of done) is established for each user story.

2. The acceptance criteria are shared with, and agreed to, by the team.

3. The product owner confirms that each story is complete before it can be considered “done.”

4. All acceptance tests are in a passing state before product or service is delivered.

 

Continuous Deployment Description

Continuous Deployment is an extension of continuous integration, and it is focused on minimizing the time between product development and that product being used by end users.

 

Continuous deployment is the process that takes validated features from continuous integration and deploys them into the production environment where they are tested and prepared for release.

 

The goal is to deliver incremental and valuable solutions to the end users as frequently as possible.

 

To enable continuous deployment, the team typically relies on automation tools.

Typical Roles

  • Scrum Team
  • Product Owner
  • Scrum Master
  • Stakeholder

 

Desired Behaviors

  • 1. Maintain development and testing environments to match the production environment as closely as possible.
  • 2. Build a staging environment that replicates the production environment.
  • 3. Deploy validated code to the staging environment after each iteration.
  • 4. Automate the testing of the features and system functionality.
  • 5. Deploy the infrastructure and supporting code structure to automate deployment.

 

Continuous Integration Description

Continuous Integration (CI) refers to the assembly of product components in incremental stages, using a purposeful strategy and defined procedures.

 

CI integration is an approach to continuous testing and product integration that was first introduced in extreme programming (XP), but is now common in almost all successful agile projects.

 

In a CI environment, an application is built and unit tested, and in some cases integration tested, using automated tools, each time new code is “checked-in” to the code management system.

 

Desired Behaviors

1. Set up a code repository for configuration management.

2. Build servers and scripts to automate the integration and testing of checked-in code configured to build and compile the application at frequent intervals.

3. Commit code to the baseline repository as it is completed to enforce early integration testing.

4. Run automated unit and integration tests at frequent intervals.

5. Publish and review the results.

 

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.

 

Typical Roles

  • Agile Team
  • Product Owner
  • Business SME

 

Desired Behaviors

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 fulfill 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.

 

Daily Stand-Up Description

The Daily Stand-Up (or “Daily Scrum” or “Daily Meeting”) is an agile technique that is popular with most agile teams.

 

It is used to maintain a shared understanding of progress, identify impediments and risks early (“fail fast”), and increase collaboration and transparency among team members.

 

As the name indicates, the meeting occurs every day, and participants often stand for the duration of the meeting in order to encourage brevity.

 

There are primarily two approaches to conducting a Daily Stand-Up meeting. The first is to conduct a meeting where information is provided based on the active user stories for the current sprint. The other method, known as “round-robin,” is used to share information related to current tasks, forecast, and any impediments each team member may have.

 

The Daily Stand-Up meeting is usually facilitated by the scrum master and involves all agile team members.

 

Depending on the maturity of the team, and the level of trust with product owners and other stakeholders, it may be useful to include extended team members, but typical attendees are those who are performing tasks related to the goal of the current sprint.

 

Typical Roles

  • Scrum Master
  • Agile Team
  • Product Owner (optional)
  • Extended Team Members (optional)

 

Desired Behaviors

1. Conduct the Daily Stand-Up at the same time each day in order to decrease complexity.

2. Hold the meeting face to face, if possible, or using virtual technology if face to face is not possible.

3. The scrum master facilitates the workflow of the meeting.

4. Timebox the Daily Stand-Up to 15 minutes or less.

5. Each team member shares:

  • a. What was completed since the last Daily Stand-Up?
  • b. What is planned for completion today?
  • c. What issues or risks are impeding progress.

6. With large teams, consider the use of a “token” to identify the team member who is speaking.

7. The scrum master records the impediments, risks, and issues that are identified during the meeting.

8. The scrum masterworks to remove impediments, reduce risks, and resolve issues outside of the Daily Stand-Up meeting.

 

Definition of Done Description

The definition of done (DOD) is a fundamental element of any agile project that helps maintain quality and limit the scope. It is an agreement within the team that defines what must be completed for each user story in order to be presented at a sprint review with the product owner.

 

Definition of done can be applied to epics, user stories, and tasks using unique criteria to define when each is “done.” The DOD can be extended to each agile including sprint planning, sprint demos, retrospectives, and backlog grooming in order to achieve team agreement that each ceremony is complete.

 

In that case, the DOD defines the tasks and work items required to complete each agile ceremony.

 

Definition of Done Examples:

  • Code and test cases are written.
  • The code was peer-reviewed and met coding standards.
  • Code passed all relevant unit tests.
  • User story was tested and passed all associated tests.
  • The code was deployed to the system test environment and passed system tests.
  • A code was deployed to an integration environment and passed integration tests.

 

User story/test cases passed User Acceptance Testing (UAT). The UAT is based on the acceptance criteria that were established for the user story.

 

The remaining hours for a task are set to zero and a user story is moved to “Done” on the scrum board.

 

Required product documentation (e.g., User Guide, Installation Guide, design documents) was produced, reviewed, and approved. Any build, deployment, or configuration changes were implemented, documented, and communicated.

 

Typical Roles

  • Agile Team
  • Product Owner

 

Desired Behaviors

1. Convene the team and agree on which work products and ceremonies will be subject to the definition of done.

 

2. Convene the agile team to establish and agree upon the definition of done for a typical user story, and any other work product subject to the DOD.

 

3. Post the DOD as an information radiator in a location visible to all team members.

 

4. Use the DOD to determine if each user story or work product is complete before moving it to the “Done” column on the task board.

 

5. Discuss the effectiveness of the team’s DOD at each sprint retrospective. Adjust the DOD as necessary.

 

Definition of Ready Description

A definition of ready (DOR) enables a team to specify certain preconditions that must be met before a user story can be accepted into a sprint.

 

The goal of the DOR is to identify defects in the story before work has commenced, thereby reducing defects early, when they are the least costly to address.

User stories that are "ready" are clear, concise, sized appropriately for a sprint, and most importantly, actionable.

 

Typical Roles

  • 1. Agile Team
  • 2. Product Owner
  • 3. Scrum Master

 

Desired Behaviors

1. Develop a checklist to outline the criteria for the agile team’s definition of ready.

2. Apply the INVEST (or other) criteria to ensure that a user story is Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable.

 

3. Avoid rules that require full compliance to DOR at all times, allowing for exceptions based on specific attributes of the user story.

 

4. Post the definition of ready in the location visible to all team members.

 

5. Use the definition of ready during the sprint planning meeting to determine if user stories can be accepted into the sprint backlog.

 

6. Discuss the effectiveness of the team’s definition of ready at the sprint retrospective. Adjust as the team becomes more aware of what makes up a good, actionable user story.

 

Dot Voting Description

Dot Voting is a technique that allows an agile team to quickly select or prioritize items with input from all team members. Each team member is given the same number of dot stickers and instructed to place the stickers near the list of items they wish to select or prioritize. Team members may place as many dots as they wish on any item(s) on the list.

 

Items with the most dots are selected or prioritized based on the number of dots they receive. This technique is frequently used during the sprint retrospective to help prioritize improvements.

 

Typical Roles

  • 1. Agile Team
  • 2. Scrum Master
  • 3. Product Owner

 

Desired Behaviors

1. Post the options (e.g., user stories, items, solutions, improvements) on the wall using sticky notes, flip charts, or another visible medium.

 

2. Explain the goal of the session (e.g., select the best alternative, rank order user stories) and why each vote is important. Discuss the options and answer any questions from participants.

 

3. Give the same number of dots to each participant. Alternatively, a marker may be used to the team member can record their vote directly on the sticky note or flip chart.

4. Ask the participants to vote by placing their dots. Participants should apply dots under or beside the items they prioritize.

 

5. Count the votes and announce the items with the highest number of votes. If ranking is required, rank order the items from the most number of dots to the least.

 

6. Briefly discuss the items that were selected or prioritized the highest. If the participants are not in agreement with the voting outcome, take the following action:

 

  • a. Arrange the votes into three groups to represent high, medium, and low priorities.
  • b. Discuss the items in each group.
  • c. Move items around to create a high-priority list.
  • d. Take a new vote with items in the high-priority list.

 

Epics Description

An epic is a large user story that describes a body of work that cannot be completed in a single sprint. Teams will break down an epic into smaller user stories that can be accepted and completed within a single sprint.

 

The product owner has responsibility for writing epics and the user stories that result from them. Both epics and user stories are maintained in the product backlog.

 

Sprint allocation is not the only reason to break down an epic. Customers often request features that are complex and that need to be broken down into smaller components to be understood and implemented by the team. These pics need to be subdivided into smaller user stories.

 

If a user story requires more than one agile team to complete the work, the story would be considered an epic, as this story will need to be divided into at least two user stories, one for each agile team.

 

Typical Roles

  • Agile Team
  • Product Owner

 

Desired Behaviors

1. Epics are identified during initial product visioning, release planning, or backlog grooming. The product owner records epics and adds them to the product backlog.

 

2. Epics are broken down into user stories during backlog grooming, sprint planning, or other regular team events. The breakdown process is often iterative and involves the product owner and the agile team.

 

3. Agile frameworks have no standard measurement for what makes a user story an epic, although it is commonly understood that an epic can span multiple sprints, but a user story must be contained in one.

 

Evaluation Description

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 behaviors across many teams within a large organization.

 

Typical Roles

  • Evaluator (e.g., agile leader, agile team member, scrum master)
  • Agile Team

 

Desired Behaviors

1. Evaluations are conducted against a defined standard or common set of expectations.

2. All participants are made aware of both the content and timing of evaluations.

3. The evaluator gathers useful information that can help improve the team, group, or organization.

4. Individual team members are not evaluated. Evaluations are conducted on teams or functional groups only.

5. 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.

6. Add improvements and impediments discovered during evaluations to the appropriate backlogs.

7. Evaluators follow up with the agile team or functional group to verify that improvements were considered appropriate.

 

Frequent ReleasesbDescription

Frequent Releases is a looser and more relaxed version of Continuous Deployment. Their primary purpose is to put new or updated products into the hands of the end- user community quickly to gather feedback and respond rapidly to change requests.

 

A release plan is used to define the frequency and timing of releases, and they can occur after each sprint or on a calendar schedule. Monthly releases that include the product increments of two two-week sprints are common among large agile organizations.

 

Typical Roles

  • Agile Team
  • Product Owner

 

Desired Behaviors

1. Develop a frequent release plan. Include the agile team(s) and any other roles that are responsible for development and deployment in the creation of the frequent release plan.

2. Define the timing of each release.

3. Groom and define the epic and user story content of the next two to three releases.

4. Keep the frequent release plan up to date.

5. Display the frequent release plan in the agile team’s workspace using visual information management systems.

 

Gemba Walks Description

A Gemba Walk is a technique used to observe and understand how work is being performed. Gemba is taken from the Japanese word gembutsu, meaning “real thing” or “real place,” and a Gemba Walk has the following elements: observation (watching people perform work in-person);

 

location (observing people at the actual location where work is performed); teaming (interacting with people performing the work).

 

Gemba Walks provide an up-close, detailed view of behaviors in action and are a powerful tool for identifying process improvement opportunities and new ways to support the agile team. They are also useful methods for leaders to see how agile teams are demonstrating agile values.

 

Typical Roles

  • Agile Leader
  • Scrum Master
  • Agile Coach
  • Agile Team or Functional Group

 

Desired Behaviors

1. Gemba Walks are performed at the location where work activities occur.

2. Observe teams while they work, and ask questions if appropriate.

3. Understand the workers’ perspectives on how the work is performed, including their view of problems and improvement suggestions.

4. Do not use the Gemba Walk to solve problems.

5. Record observations and improvement opportunities.

6. Provide timely feedback to the team or functional group.

 

Gemba Kaizen

Gemba Kaizen is a Japanese concept of continuous improvement designed for enhancing processes. Gemba refers to the location where work is performed, while

 

Kaizen is tied to the improvements. Gemba Kaizen includes identifying changes, making improvements, monitoring changes, and readjusting as necessary.

 

An individual, group of people or an improvement suggestion system can perform Kaizen. Having a strategic system in place to monitor improvements will lead to great results in the long-term overall improvement.

Typical Roles

  • Agile CXO
  • Agile Leader
  • Agile Team

 

Desired Behaviors

1. Identify business problems that are recognized by the organization.

2. Observe the known problem using a Gemba Walk.

3. Identify the root cause. Use of lean techniques such as “five why’s” can be useful in identifying root causes.

4. Once the root cause is identified, identify one or more solutions.

5. Work to implement the solution(s). Ensure that all necessary processes or procedures are updated and training is provided.

6. 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.

 

Typical Roles

  • Agile Leader
  • Agile Team
  • Managers
  • Product Owner
  • Scrum Master

 

Desired Behaviors

1. Employ a trained GQM facilitator to plan and manage GQM sessions.

2. Involve multiple levels of the organization to create measurable goals, the right questions, and useful metrics.

3. 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.

4. Define the smallest set of metrics possible to measure achievement of the most important goals first.

5. Display data and progress using visual information management systems.

6. Do not create metrics that punish or embarrass individual performers (shaming is not an agile value).

7. Regularly inspect and adapt the measurement program to fail fast and continually improve.

 

Incremental Development Description

Incremental Development is the practice of breaking the delivery of features or functions into small pieces that can be envisioned, built, tested, and delivered in a predictable, timeboxed period of time.

 

Through the completion of multiple increments, a working system is created and delivered that fulfills the functional and nonfunctional requirements. The approach requires multidiscipline engagement and the creation of a design and other documentation in matching increments.

 

Paired with Iterative Development, it is a powerful and predictable work management system that forms the basis of most agile frameworks.

 

Typical Roles

  • Product Owner
  • Agile Team
  • Scrum Master

 

Desired Behaviors

1. Include the team(s) responsible for the development and delivery of the product in the creation of the incremental development plan.

2. Break up the planned functionality into the smallest possible increments.

3. Keep the plan, designs, and another documentation current with each iteration.

4. Inspect and adapt the plan as learning occurs during each increment.

5. Display the plan using visual information management systems.

 

Kamishibai (Board and Cards) Description

A Kamishibai Board is a visual information management system used to plan and capture the results of process audits on the most critical processes in the organization. The primary purpose is to give leaders a schedule for when to audit a process and what behaviors to observe.

 

A Kamishibai Board is often part of the Gemba, the location where work is performed. The board shows the status and results of the required audits for each team or group and displays notes about issues, risks, and corrective actions. The primary goal of the board is to enable immediate problem resolution.

 

Kamishibai Cards, also known as “T-cards,” is used to define, allocate, and visualize process level audits carried out by project managers (or team leaders) and leaders who are one or two levels above in the organizational governance structure.

 

The T-cards are randomly selected from a box by a leader so that the checks are random.

Typical Roles

  • Agile Leader
  • Project Manager
  • Team Leader
  • Leadership Team

 

Desired Behaviors

1. Determine which processes, changes, or improvements are most important to the team or organization. These will become the focus of the

 

Kamishibai checks.

2. Identify the agile teams, projects, or groups for the checks (or process audits).

3. Assign an agile leader to each team, project, or group to conduct the audit.

4. Create the initial set of T-cards.

5. Deploy the Kamishibai boards to each team or group.

6. Define expectations for how often the checks are done, and who is required to do them.

7. Add Kamishibai as part of Gemba Walks.

8. Ensure that a coaching, learning, and improvement culture resulting from Kamishibai checks is maintained.

 

Kanban Board Description

A Kanban Board is a visual work management system that enables understanding and optimization of continuous work being performed by a team or functional group. The board depicts the state of work across the top, and the flow of work as it goes through each state.

 

A basic Kanban Board has stated for “waiting,” “in progress,” and “completed.” Teams are free to adapt the board and can define as many states as needed to understand how much work is to be done, being done, and is done.

 

A major goal of Kanban is to limit work in progress to drive improvements in efficiency and throughput. Choose Kanban when the work in the “waiting” state is not easily predictable, or when the type of work is driven by demand.

 

Kanban works well in many settings, and it is popular with teams that do application support and maintenance activities.

Typical Roles

Agile Team

 

Desired Behaviors

1. Define the desired work states for the Kanban Board.

2. Use visual information management systems to create, maintain, and display the board.

3. Define team rules for limiting the work in progress.

4. Add work to the “waiting” queue.

5. Record basic information, such as the name of each team member who is doing the work in each state, and how much time the work item was in each state.

6. Periodically analyze data from the Kanban Board to make improvements and increase the amount of work that can be “in progress.”

 

Kano Model Description

The Kano Model is a technique used in product development to identify the most appropriate mix of features in order to maximize the satisfaction of a product.

 

When using the Kano Model, product features are grouped into three categories: Basic, Performance, and Exciters.

The Basic category contains features that the product is expected to have. For example, if the product is an automobile, turn signals would be considered a basic feature.

 

These features do not drive satisfaction with the product, but the absence of a Basic feature can lessen customer satisfaction with a product. The Performance category contains features that can drive a linear increase in satisfaction.

 

Features that fall into the Exciter category are the type of features that can differentiate the product and make it stand out from the competition in the market.

 

The Kano Model also includes an approach for evaluating results from customer surveys. The surveys provide data on the specific product features that are desirable and undesirable to customers.

 

Applying survey results to the Kano Model helps product owners to prioritize product features and make decisions about which features to include in the product backlog.

 

Typical Roles

  • Product Owner
  • Product Management Team
  • Agile Team

 

Desired Behaviors

1. Product features are categorized as Basic, Performance, or Exciters.

2. Product vision and roadmap include features that fall into the Performance and Exciter categories.

3. Basic features are included in the product backlog.

4. The Kano Model is used to evaluate customer survey results and customer feedback. Product features are assigned to categories in the model.

5. The product backlog is updated with additional features from the Performance and Exciter categories as determined by the product owner.

 

Lean Coffee Description

Lean Coffee is an agile technique that allows for successful, collaborative meetings with minimal planning or agenda setting. Personal Kanban boards, sticky notes, sharpies, and innovative voting techniques such as not voting, fist-to-five, or even dart-guns with targets are often used to aid in the collaboration and decision-making process.

 

Typical Roles

  • Team Member
  • Scrum Master
  • Other Stakeholders as needed

 

Desired Behaviors

1. Agree on a basic theme for the session.

2. Attendees write topics to be discussed on sticky notes or cards.

3. Establish a personal or temporary Kanban board with “To Do,” “Doing,” and “Done” columns.

4. Introduce each topic.

5. Vote, and rank, each topic for discussion.

6. Prioritize the ideas by vote, and move the first to the “Doing” column.

7. Set a time for five minutes, and timebox the discussion of each idea.

8. If the timer goes off, the group can vote for an extension for another five minutes.

9. When time runs out, and no one wishes to continue, move the idea to the “Done” column.

10. Record outcomes and decisions, and distribute to the relevant stakeholders.

 

Mob Programming Description

Mob programming is a technique used by a collaborative software development team to rapidly solve a problem or to write complex software. Mob programming is similar to pair programming, but with two distinctions. First, mob programming uses as many developers as possible so that many perspectives lead to a more complete solution.

 

Secondly, mob programming is performed on-demand, and it is not a standard behavior for the team.

 

Typical Roles

  • Agile Team
  • Product Owner
  • Scrum Master

 

Desired Behaviors

1. Determine when and how the agile team should use mob programming. Include the conditions and procedures in the agile team’s charter or team agreement.

2. Identify the best mix of team members based on the problem to be solved by mob programming.

3. Have the scrum master facilitate the session to make sure it is effective and valuable.

4. Ensure that agile values are exhibited.

5. Ensure that team agreement are respected.

6. Conduct a short retrospective at the end of each session to improve future sessions.

7. Share learning beyond the agile team.

 

Obeya Room Description

Obeya is Japanese for “big room.” It refers to a dedicated space where team members meet to collaborate and solve problems. It is set in an environment that supports the free flow of information and communication between team members and other stakeholders.

 

An Obeya Room helps to minimize barriers that can stifle communication and inhibit collaboration; and the use of charts, graphs, boards, sticky notes, and other visual information management tools are commonplace in

 

Obeya Rooms as they assist with collaborative problem-solving.

 

Typical Roles

  • Agile Leader
  • Agile Team

 

Desired Behaviors

1. Create a dedicated collaboration area that exists solely to serve as an Obeya room.

2. Assign a defined purpose for each Obeya Room.

3. Ensure that all information is displayed using visual formats (e.g., charts, graphs, dashboards) to communicate information.

 

Open Space Technology Description

Open Space Technology is a way to enable a diverse group of people, in any kind of organization, to create inspired meetings and events where the outcome is unclear. In Open Space sessions, participants create and manage their own agenda of parallel working sessions around a central theme of strategic importance.

 

Open Space works best when the work to be done is complex, the people and ideas involved are diverse, the passion for resolution (and potential for conflict) are high, and there is an urgency to identify solutions.

 

Typical Roles

  • Agile Team
  • Agile Leader
  • Business SME
  • Product Owner

 

Desired Behaviors

1. Identify the major themes that will set the boundaries around Open Space discussions and agendas.

 

2. Raise issues that are most important to a representative subset of Open Space meeting participants.

 

3. Plan the Open Space meeting with the assumption that all of the issues and ideas raised will be addressed by those participants most interested, qualified, and capable of resolving them.

 

4. Conduct the Open Space meeting in a timeframe no longer than one or two days. Within that time, all of the most important ideas, discussion, data, recommendations, conclusions, questions for further study, and plans for immediate action will be documented in one comprehensive report.

 

This report will be finished and in the hands of participants when they leave.

 

5. Take advantage of visual information techniques, including photographs, to record Open Space information.

 

6. Prioritize the information generated during the Open Space. This may be done at the end of the Open Space meeting, or in a brief follow-up session.

 

7. Make the results of the Open Space event available to the entire organization or community within days of the event.

 

Pair Programming Description

Pair programming is a software development technique in which two developers work together to complete a coding task. They generally work at one workstation with one programmer being the “driver” and the other being the “navigator.” The navigator reviews code as the driver is entering it, performing a sort of real-time code review.

 

While this typically appears increases the cost of programming, the reward of increased code quality far exceeds the investment in time and effort.

 

Another approach to pairing programming has one developer coding, while the other unit tests. In other cases, a developer codes while another sits next to the developer, helping to interpret the requirements and ensuring a higher level of code quality.

 

Regardless of how the pairing is done, the direct and immediate feedback loop of working together improves the quality of the resulting system at a lower cost.

 

Typical Roles

  • 1. Software Developers
  • 2. Agile Team

 

Desired Behaviors

1. Create a physical infrastructure that supports a pair programming working arrangement.

2. Decide the role each developer is going to play, and codify it in the team agreement.

3. Begin pairing and maintain the roles agreed to at the beginning of the pairing session.

4. If at any time during the pairing session, the pair becomes ineffective, revisit the objectives for the session and adjust responsibilities to ensure that the objectives are met.

 

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.

 

Typical Roles

Author

  • Agile
  • Product Owner (if stories are being reviewed)
  • Scrum Master

 

Desired Behaviors

  • 1. Identify work product for peer review.
  • 2. Identify peer review participants.
  • 3. Distribute content to be reviewed.
  • 4. Confirm review of work products.
  • 5. Conduct peer review with invited reviewers.
  • 6. Record defects, issues, and risks.
  • 7. 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 building of the actual product.

 

Typical Roles

  • Agile Team
  • Scrum Master
  • Product Owner

 

Desired Behaviors

1. Review sprint or iteration backlog with the product owner.

2. For each story that has been presented by the product owner, discuss among the team to ensure that an understanding is reached.

3. 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.

4. The scrum master facilitates a discussion about why there are differences, ensuring each team member has a chance to present their point of view.

5. The team throws down another set of cards, based on the information they have just received from their teammates.

6. The scrum master facilitates the second round of discussions.

7. If a general consensus is not achieved, discussion continues, and one more round can be played.

8. 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.

 

Product Backlogs Description

The product backlog is a prioritized list of everything that may be included in the product. It can include epics, stories, features, bugs (if the product is in production, or if there have been releases of the product in prior sprints), documentation changes, and any other tasks required by the product owner or agile team.

 

The product owner owns the backlog and the priority of the items on it. The product owner may seek input from stakeholders, business representatives, and the agile team to help set the priority, but the owner is responsible. The backlog is maintained during the sprints through the backlog grooming ceremony.

 

Additional backlogs may be maintained to prioritize work associated with the team or organization such as the following:

 

Impediment Backlog

Use an impediment backlog to rapidly capture impediments raised during daily stand-ups, keep them visible to the team, and keep progress toward removing them transparent. An impediment is any item that is hindering the work of the team and reducing the likelihood of meeting a commitment.

 

Training Backlog

A training backlog is a prioritized list of training required for the product or organization.

 

Improvement Backlog

An improvement backlog is a prioritized list of improvements for the product or organization.

 

Enterprise Impediment Backlog

Enterprise impediment backlogs are used to prioritize and manage impediments that are barriers to sustained agile effectiveness and delivering increased value to customers.

 

Enterprise Cascading Backlogs

Enterprise cascading backlogs consist of multiply related backlogs associated with a particular program or organization. These backlogs are managed by a single product owner or product owner team.

 

Managing multiple enterprises cascading backlogs requires a regular pattern and integrated set of practices on a hierarchy of backlogs that facilitates transparency and traceability.

 

Typical Roles

  • Agile Team
  • Scrum Master
  • Product Owner

 

Desired Behaviors

1. Ensure that all backlogs are a set of prioritized features, both functional and nonfunctional, which are known to be needed, and are the single, authoritative sources of needs for the product or service.

 

2. Ensure the backlog is owned by a product owner, and that they are responsible for prioritizing and managing it through the use of the backlog grooming ceremony.

 

3. Keep the backlog as the foundation of an agile project regardless of the ceremonies and techniques being employed.

 

4. Make the backlog available to all team members using visual information management techniques.

 

Product Scenarios Description

Product scenarios are used to describe how a user will interact with a product to perform actions to achieve a specified goal and tie the who, what, when, why, where, and how in order to provide the overall context of those user actions.

 

In order for a product scenario to be effective, it utilizes user profiles (personas) and focuses on the key interactions between the user and the product.

 

The use of product scenarios can help narrow the focus to which product features would provide the most value to customers.

 

Typical Roles

  • Agile Team
  • Product Management Team
  • Business SMEs
  • Product Owner

 

Desired Behaviors

1. Adopt user profiles or personas in product scenarios.

2. Focus on the actions that end users perform in pursuit of a goal.

3. Scenarios should be technology and system agnostic.

 

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:

  • Agile Values
  • Common expectations
  • Communications
  • Agreements between the team and suppliers
  • Agreements between the team and internal service providers
  • Governance and self-organization guidelines
  • Roles and Accountabilities

 

Typical Roles

  • Agile Team
  • Scrum Master

 

Desired Behaviors

1. Identify high-priority agile values or other organizational guidelines to adopted.

2. Hold a dedicated session to agree on mission, purpose, core values, potential obstacles, ground rules, and communications.

3. Capture information during this session to ensure that the source of the project charter is available to all team members.

4. Ensure that the project (team) charter is understood and subscribed to by all members of a team.

5. Post the charter in a visible location.

6. Plan how often the charter will be reviewed and updated after it has been established.

 

Prototyping/Spike Description

A prototype, or sometimes called a “spike” if it’s limited in scope or functionality, is a technique used by agile teams to create a product or service proof-of-concept in order to quickly solicit feedback about the design from customers and end users, or to help the team understand the user stories.

 

Prototypes or spikes can be developed in various ways depending on the type of feedback desired. For example, they can be created using basic materials (e.g., pen and paper) or sophisticated technologies (e.g., markup languages).

 

Prototypes or spikes allow customers to interact with a product giving product teams insight into which features are most important to the end user. The ability to experiment with multiple prototype iterations, and test various concepts in the field, provides critical input into refining the product vision.

 

Typical Roles

  • Product Owner
  • Product Management Team
  • Agile Team
  • End Users

 

Desired Behaviors

  • 1. Design prototypes/spikes to generate feedback on features, characteristics, and usability.
  • 2. Observe end users as they explore each prototype/spike.
  • 3. Gather end-user information to help refine the overall product direction.
  • 4. Experiment with multiple iterations of prototypes/spikes.
  • 5. Groom the product backlog after each prototype/spike to ensure that specific functionality is added, removed, or updated.

 

Release Planning Description

The purpose of release planning is to project a long-term plan for delivering specific functionality on a loose schedule to meet a business requirement. The used of fixed plans, budget, and functionality, commonly seen in “waterfall-style” planning, is discouraged. The release plan is a vision, based on known variables, of what may be released along with a given timeline.

 

Release Planning requires a prioritized product backlog that is managed by the product owner and is a view into the potential functionality that might exist at a specific point in time.

 

The product owner is responsible for conveying the product vision and business objectives to the development team, and discussing a basic sequence of iterations or sprints that, if nothing changes, would result in a delivery schedule.

 

During release planning, the product owner and the agile team collaborate on which features will be delivered in each release, and the agile team can plan for needed capabilities and resources, sprint duration, and estimate the expected number of sprints that may be required to meet the release forecast.

 

The product owner, in collaboration with the agile teams, should review and revise the release plan after each iteration or sprint, based on feedback received during sprint demos and backlog grooming.

 

Typical Roles

  • Agile Team
  • Customer
  • Business SME
  • Marketing, Sales, or Business Development
  • Product Owner

 

Desired Behaviors

1. Prioritize the product backlog and product features during and after each iteration/sprint.

 

2. Focus on the highest-value features in the early sprints, leaving the lower-value features until later sprints, or even negotiate them away after the teams learn more about them.

 

3. Loosely allocate epics or stories to sprints within the release plan based on their known variables and business priority.

 

Retrospectives Description

The purpose of a retrospective is for each team or functional group to reflect on actions, results, and behaviors from the current sprint, and identify potential improvements for the next.

 

Retrospectives align to one of the core principals from the Agile Manifesto, which states “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

 

Retrospectives should be conducted regularly at the conclusion of each iteration or sprint to capture feedback and encourage continuous improvement. There are many different types of retrospectives, but they are all similar in purpose: to learn and improve.

 

During a retrospective, a team or functional group identifies what went well, what did not go well, and then identifies what actions might be taken to improve performance during the next iteration or sprint.

 

An effective retrospective requires that each participant feels comfortable providing feedback, and it is important that the scrum master/facilitator works to build trust in collaborative relationships among team members.

 

Enterprise Retrospective

The intention of an Enterprise Retrospective is to improve the performance of an overall organization. This retrospective is not just one agile team, but multiple, often represented by each scrum master.

 

This ceremony should be planned out to identify the schedule, approach, location, and process scope. This retrospective may have a reduced frequency as it is more resource intensive than a Team Retrospective, and may not be aligned with a specific sprint.

 

Heartbeat Retrospective

A Heartbeat Retrospective begins with ensuring the team is fully aware that the purpose is to learn from mistakes and not assign blame. Other characteristics of this type of retrospective include a timeboxed approach with a maximum of 90 minutes, taking place outside the normal team room, and the team decides who is welcome to attend this meeting.

 

Sprint Retrospective

While all agile teams should work to continuously improve, it is important to set aside time to proactively find ways to improve. The Sprint Retrospective is conducted at the end of each sprint, and the entire team, including the scrum master and product owner (if there is a high level of trust), should participate.

 

Typically, a Sprint Retrospective is one hour but may vary based on how long the spring duration was and whether there are contentious topics to discuss.

 

Training Retrospective

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.

 

Milestone Retrospective

For a project or initiative that has been underway for an extended duration, or has been completed, a Milestone Retrospective can be valuable. This retrospective takes more time because of the length of the project being reviewed, and could span for one to three days.

 

Milestone retrospectives are generally facilitated by someone external to the team to review long-term or strategic impacts, work relationships, and governance.

 

Confirmation Retrospective

A Confirmation Retrospective is intended to review training results in order to improve an overall organization. This retrospective may allow teams to practice new skills or training methods to solidify training approaches and ensure that there is consistency across the organization.

 

Typical Roles

  • Agile Team
  • Functional Group
  • Scrum Master

 

Desired Behaviors

  • 1. Establish a regular frequency for retrospectives.
  • 2. Gather a team or functional group to conduct retrospective at the end of each sprint or iteration, if appropriate.
  • 3. During each retrospective, discuss challenges and capture lessons learned.
  • 4. During retrospective, discuss and capture what went well, what did not go well, and ideas for improvement for the next sprint.
  • 5. At the conclusion of the retrospective, identify actions to be taken to improve.
  • 6. Add actionable items to the improvement backlog.

 

Review Description

The review is a well-defined and formal method for ensuring that a work product meets team or organizational expectations, and to ensure that defects are identified and corrected as early as possible.

 

The review is an opportunity to “fail fast.” Unlike a Gemba Walk, which is to “go and see,” a review is to “ask, record, and provide feedback.” Reviews are useful to gather a broad set of perspectives, develop knowledge of less-experienced team members, and to standardize improvements across teams and the organization.

 

Reviews can be informal observations, or can use formal checklists and process baselines, but should always generate data that can be used to share learning and prevent the recurrence of common problems.

 

Typical Roles

  • Reviewer
  • Scrum Master
  • Agile Team
  • Functional Group Members

 

Desired Behaviors

1. Review against a set of common expectations.

2. Ensure that everyone is aware of both the content and timing of a review.

3. Gather useful data and information that can improve the team, group, or organization.

4. Have an objective team member facilitate the review.

5. Add improvements and impediments discovered during reviews to the appropriate backlogs.

 

Roles and Accountabilities Game Description

The purpose of the “Roles and Accountabilities” game is to build a common understanding of team roles and accountabilities and to encourage self-subscription to accountabilities.

 

This game identifies key roles and accountabilities on index cards, then has the team align the accountabilities to each role. While aligning accountabilities, the team can work through ambiguous or contentious accountabilities, and the scrum master may assist by helping team members reach the best conclusion.

 

This game may be applied to different types of teams in an organization where clarity and common understanding are needed. At the conclusion of the game, team members can self- subscribe to roles and all the accountabilities for each role that have been defined.

 

Typical Roles

  • Agile Team
  • Functional Team
  • Scrum Master

 

Desired Behaviors

1. Identify participants that are needed for the roles and accountabilities game.

2. Prepare for the game. Provide large sticky notes for roles, small sticky notes for accountabilities, wall space, and markers.

3. Divide the participants into groups, with two groups being sufficient for smaller teams.

4. Using a timeboxed approach, ask each team to define all potential roles within the team, and post them on large sticky notes.

5. Each group peer reviews the other’s work and adds/removes/ combines roles as appropriate.

6. Each team discusses and defines the accountabilities for each role and records them under the appropriate roles.

7. Each group peer reviews the other’s work and adds/removes/ combines accountabilities as appropriate.

8. Team members can now self-subscribe to roles that have been defined.

 

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;

 

or the establishment of a multitiered cross-functional system that operates on the “squad,” “tribe,” “blog,” and “guild” level (often called the “Spotify model”).

 

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 the 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, a 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.

 

The Room Where It Happens

Many organizations seek to instill the Agile value of collaboration by creating open and flexible floorplans, sometimes called Agile zones or, in some cases,

 

Agile cities. As a rule, you need not spend too much time in one of these zones to determine whether its energy matches its title. Some Agile zones buzz with interaction, creativity, and collaboration.

 

Others are tense, stifled, and permeated by the palpable discomfort of individuals desperately vying for any crumbs of personal space.

 

The difference has less to do with the spaces themselves, and more to do with the teams that inhabit them. For teams that are used to working in a synchronous, face-to-face way, an open Agile zone can be an ideal working environment.

 

But if a team communicates primarily via asynchronous email threads, Google Docs comments, and PowerPoint presentations, an open Agile zone is at best irrelevant and at worst enormously distracting.

 

These asynchronous methods of communication have become the default for many teams, including teams that are entirely colocated. In many cases, working this way just seems easier;

 

shooting off a quick email or tagging someone in a Google Docs thread doesn’t take much time at all, and it certainly feels like a less onerous task than throwing yet another meeting on people’s already-packed calendars.

 

And yet, each of these actions incurs a cascading cost of time and attention that is often difficult to see and measure.

 

Sure, it does not take long to add a few more people to an email thread or to pop a few comments in a document to show that you’re paying attention. But for the people receiving those emails and comments, this can add up to a mountain of ambiguously prioritized busywork detached from clear goals and outcomes.

 

This dynamic often results in a lot of time being lost without a lot of decisions being made. And when you’re on an email thread with 20 other people, it can be difficult to know what a “decision” even is. Does everybody need to agree?

 

Is the lack of feedback an implicit sign of approval? This lack of clarity often makes it particularly difficult for a team to move forward with any kind of work that requires input from multiple people.

 

He described to me how taking this “hothouse” approach has helped his teams collaborate more closely and hit their deadlines:

 

We’ve operated under the very simple principle that we’re not going to communicate over email and PowerPoint presentation; we’re going to put the designers and the technical folks into a room with the business owners and let them do their work.

 

I’ve always called it a “hothouse” approach, and I’ve been using it since before I knew anything about Agile. Putting the right people together, we are able to make decisions and make progress really fast.

 

It’s also much harder to create negative working relationships when you sit in the room with someone and figure something out. There are boundaries of civility that generally apply to how you will interact with the person who is sitting across from you.

 

Email, meanwhile, can become a passive-aggressive medium when misused—making it possibly the worst tool for Agile ever invented. The wrong people can be copied, and people who don’t need to be copied are sometimes copied.

 

And even the people who should be copied get a lot of things they don’t need to see. Beyond that, people’s ability to perceive and deliver content and context is challenged over email. In situations where we need to make decisions and move fast, PowerPoint and email slow progress.

 

I don’t think there’s a neat formula for who should be in the room. Decision makers should be there, and team leaders trusted by the people who aren’t in the room, for sure. There’s also certainly a number at which gathering people in the same room becomes unwieldy and doesn’t work so much anymore. 

 

As this example illustrates, sometimes just putting people in a room together— even if it’s too many people and even if it isn’t exactly the right people—is enough to make significant progress. Here are a few steps you can take to get in the habit of making decisions “in the room”:

 

Decide what you are going to decide

To make sure that the time people spend together is impactful, get out ahead of thinking through what decisions you’re actually hoping to make in each synchronous meeting.

 

Resist the urge to punt on these decisions and send things around for asynchronous feedback when the meeting is over, which often becomes a huge time-suck and, as Thomas Stubbs suggested, opens up lots of room for miscommunication and hurt feelings.

 

If the group gets stuck trying to reach a “perfect” decision, try asking the question, “Would our current decision leave us in a better position than the one we are in right now?” If the answer is yes, commit to your decision in its current form, and commit to reevaluating that decision at an agreed-upon time in the future.

 

Practice time-boxing

One idea that informs multiple Agile practices is that of time-boxing or establishing an absolute upper bound to the amount of time allotted for a given meeting.

 

The first couple of times a team actually enforces a time box, it usually does not go that well. Critical decisions are left unmade, the most talkative people in the room go off on tangents, and everybody leaves feeling defeated and confused. But by the third or fourth time-boxed meeting, there is usually an appreciable change.

 

Once people actually believe that a meeting will end within a given timeframe, they are much more inclined to prioritize the conversations that will help that meeting achieve its intended purpose. They are also much less likely to resist synchronous meetings out of fear that such meetings will go on forever and produce no tangible result.

 

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.

 

Disentangle “synchronous” from “colocated”

For remote and distributed teams, finding ways to work together “in the room” can be particularly challenging. But it is helpful to approach this challenge by clearly differentiating synchronous work from colocated work.

 

Once this distinction has been made, it is much easier to ask questions like, “What kinds of decisions should we be making synchronously?” and, “How will we use asynchronous channels like email and document comments in a way that helps us achieve our goals?”

 

For teams of all kinds, drawing attention to the differences between synchronous and asynchronous modes of communication can open up space for more people to participate meaningfully in the process of making decisions, which in turn fosters a greater sense of shared accountability.

 

Even though sending a PowerPoint deck around to 50 people and asking for feedback might feel like the easiest way to get something done, it is definitely not the most collaborative—or the most efficient.

 

Making Connections to “Scout and Scale”

Knowledge management can be a huge challenge for large and small organizations alike. As priorities shift and personnel turn over, there is a substantial risk of lessons that have already been learned to go unheeded, and work that has already been done being redone.

 

Embracing the guiding principle of collaborating early and often gives us one important step that we can take to reduce these risks: asking our colleagues what has already been done and by whom before we rush to executing new work within our particular team.

 

Embracing this approach allows us to take a broader view of our overall goals and shine a bigger and brighter light on the things that are already helping us to meet those goals.

 

Shift7 CEO and former United States CTO Megan Smith described to me the scout-and-scale approach that she used successfully to address big, challenging problems in the public sector:

 

In my work with the government and my work with Shift7, I have cultivated a scout-and-scale approach, which is to say, I don’t build stuff, I find the people who are building it and connect them.

 

The way to get to the future is solution making through inclusion, and the first step is often just asking, “What have you already got? Who already solved this problem?” It’s usually multiple people, and we can connect these people to resources and to one another to scale these solutions.

 

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 center, 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 (and, if you are so inclined, some off-the-shelf language) 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.

 

Indeed, the simple fact of holding a daily stand-up will in no way guarantee that you are actually building a collaborative culture. As IBM CMO Michelle Peluso told me:

 

You can’t check the box of “oh, we’re doing stand-ups” and really understand what it means to be Agile. When you are truly practicing 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.

 

So, we are going to have a daily stand-up meeting to stay focused on our customer-facing goals.”

 

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.”

 

Utilize “Lunch Roulette” or another mechanism for making informal connections across far-flung parts of your organization.

 

Hold open “lunch-and-learn” meetings during which people can share interests outside of their day-to-day work (such as how to make great coffee at the office or how to research an awesome vacation).

 

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 an 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 inflection 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.

 

Get in the habit of including the kind of feedback you need and the timeframe in which you need it in your email subject lines. For example, “Newest Version of Campaign Plan [Approval Needed by Friday],” or, “Latest Product Mockups [FYI, No Feedback Needed].”

 

Summary: 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.

 

Kathryn Kuhn, an experienced Agile practitioner and advocate who has worked with organizations like Teradata, Oracle, and Hewlett-Packard, described to me how a large financial services organization was able to better plan for uncertainty by adding shorter, quarterly cycles to their existing years-long planning cycles, and framing up this shorter cadence in a language that resonated with the organization itself:

 

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.

 

We could discuss the trade-offs of each approach, rather than letting them get decided by inertia and inaction.

 

One key to our success was using the language of the organization itself— terms like “good enough for now,” and “done enough.” Or, “great idea, not yet.” This gave people a vocabulary to talk about prioritization without being too technical or too dismissive.

 

As this example illustrates, even in organizations that plan in year-long cycles, there is room to build in more frequent opportunities to share knowledge and adjust course.

 

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: Using Structure to Achieve Flexibility

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 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 (especially newly indoctrinated ones who have been through a lot of training) 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.”

 

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 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 from 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 chiseled in stone, or are they more guidelines, with an understanding, there will be some adjustment?

 

If those longer-term guidelines are used not as the absolute truth, but as a directional guide, that still leaves a lot of room for agility. But once things become fixed and bureaucratic, “you said $10.1 million, not $9.9 million,” then things get trickier.

 

As both this example and Kathryn Kuhn’s story from earlier in this blog illustrate, having yearly plans in place does not mean that we must abandon our quest for agility.

 

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.

 

Celebrate 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 (the blog The Lean Startup is full of great examples), 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 “artifact 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 that see Agile as a box they can check off rather than an ongoing journey that will itself require a constant embrace of change.

 

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.

 

Agile Practice Deep Dive: The Retrospective

If Agile is the engine that helps you achieve escape velocity and overcome the laws of organizational gravity, the retrospective is the valve that stops that engine from overheating and burning out.

 

A retrospective is a meeting at the end of a sprint or the completion of a project during which a team reflects on the way they work together and identifies changes they can make for the next sprint or project.

 

Note that the goal of a retrospective is explicitly not to critique the actual work that was just completed, but rather to reflect on how the team completed that work.

 

The retrospective constitutes an important opportunity for teams to build a shared sense of purpose and ownership around the way they work. It is a chance to first ask the question, “Is the way we’re working helping us live up to our principles and achieve our goals,” and then, “What are we going to do about it next time?”

 

For many teams I’ve worked with, especially those outside of product and engineering, speaking openly about what is and is not working can be an uncomfortable prospect.

 

People often assume that the way they currently work must have been put into place for a very good reason and that questioning it might amount to undermining somebody else’s experience or authority.

 

But I have been truly amazed at how many times a particular practice or artifact—like a regularly scheduled meeting that provides no real value or a campaign planning template that demands way too much information—turns out to be a simple historical accident that nobody has felt empowered to reevaluate.

 

I have participated in many retrospectives, for example, in which somebody sheepishly suggests that a long-standing practice is no longer serving the team, only for everybody else in the room—including that team’s leader—to react in swift and violent agreement.

 

Moments like this can have an immediate and incredibly positive effect on a team’s morale and productivity, but they simply do not occur unless you create space for them.

 

One of the fantastic things about retrospectives is that you can run them at the end of any project, regardless of whether that project involves any other Agile practices.

 

Adding a retrospective to any regularly scheduled work such as a monthly newsletter or quarterly planning meeting can open up a new kind of space for teams to discuss how they work together and why. 

 

Most issues can be solved with communication, and a lot of companies miss the human side of things. They think that Agile is going to make people faster, but people are not robots! And there are a lot of silly issues and miscommunications that can become big problems unless you bring people together for an open dialogue.

 

Sometimes, just the safety net of being able to express yourself in front of your team is enough to get started—and once you have that, you start to get a team into the state of flow. And for me, that starts with the retrospective.

 

Each Agile ceremony has its reason. But to me, the retrospective is the key to continuous improvement. Without that, a strict and regimented framework is all you’ve got.

 

We’ve talked to a lot of Scrum masters who have trouble communicating the value of Agile to their teams. And if you have that problem, you need to start from the beginning. You need to open up that dialogue and give everybody on the team the opportunity to say what they really feel.

 

There will almost certainly be conflict, but that conflict is good—it’s what drives you to the next level. Without bringing that conflict into the open, a lot of teams are stuck in that first level, unable to work through the very first challenges that they find in a newly formed team.

 

Retrospectives are often challenging for the very reason that they are ultimately so valuable: they open up space where people can voice their doubts, questions, and uncertainties about the way that they work together.

 

These conversations are rarely comfortable, and they rarely yield easy or certain answers. But the simple fact of the retrospective is often enough to begin addressing the unspoken beliefs and assumptions that can leave teams feeling stuck and disempowered. Here are a few tips for keeping your retrospective on track:

 

Model vulnerability and uncertainty

If you are the person bringing Agile practices to your team, your teammates look to you to understand how they are “supposed” to behave during a retrospective.

 

This might leave you feeling like you need to have all the right answers or to defend the Agile practices you’ve introduced.

 

But the best thing you can do for your team is to model the kind of openness and honesty that will enable you to continuously adapt and improve. If somebody asks about a particular practice and you don’t have a good answer, feel free to say, “I don’t really know. What does everybody else think?”

 

Stay focused on what you are going to do next time

In many organizations, taking time to reflect on the way a team works only happens when there is a major problem. As a result, retrospectives can devolve into evasiveness and finger-pointing.

 

The engineering teams at Etsy solved this problem by holding what they call “blameless postmortems,” in which participants can openly reflect on mistakes they made without fearing retribution.

 

But another step you can take to avoid the blame game is to shift the conversation toward what you will do differently for the next sprint or project. For example, “Regardless of who was responsible for what happened last time, what can we all do together next time to make things better?”

 

Treat future changes as experiments, not mandates

Regularly scheduled retrospectives provide your team with the opportunity to adjust course after each sprint or project. This means that there is very little risk associated with trying a new practice or approach; after all, if it isn’t working, you will have the opportunity to change it or roll it back during your next retrospective.

 

Remind your team that every change you make is essentially an experiment; you won’t know whether it works until you try it, and you are prepared to adjust course based on what you learn.

 

Keep your principles in focus

I’ve often found it helpful to have my team or organization’s guiding Agile principles physically present during a retrospective. This helps to keep the team focused not just on how they are working together, but also on why they are changing the way they work in the first place.

 

These principles can also serve as a powerful mediator when there is a disagreement, enabling you to ask, “Which of these approaches is most aligned with our guiding principles?” rather than,

“Which of these approaches do we like more?”

 

Hold space for what is working

Although running a retrospective is a critical way to adjust course when things are not working well for your team, it is also a critical way to acknowledge the things that are working well for your team.

 

One approach I’ve found helpful is to ask each team member to quickly write down three things that worked well and three things they think could be changed for the next sprint or project. This gives equal time to the things that are worth protecting and the things that stand to be refined.

 

Break the ice

A team’s first couple of retrospectives can be particularly awkward. Sometimes, it is helpful to bring a sense of fun and ease to a retrospective by starting with an icebreaker or framing the retrospective itself as a kind of game.

 

Mindful Team, whose co-founder Emma Obanye provided the insightful commentary about retrospectives earlier in this blog, offers a card game called The Retrospective Game that can provide a great first step for teams that are not used to sharing reflections in a group.

 

Finally, and perhaps most importantly, resist the temptation to cancel your retrospectives if you have a lot of work to do. For teams and organizations that see

 

Agile just as a means to increase velocity, the retrospective can seem like a waste of productive time—after all, you aren’t actually making anything, just sitting around and talking about how you make things.

 

But making time for a team to reflect on how it works is a non-negotiable if you want that team to embrace any new ways of working.

 

In the absence of a retrospective, it is inevitable that any set of Agile practices will fail to achieve their full potential, as the team implementing those practices comes to see them as just another form of “business as usual” that they are powerless to question or adapt.

 

You are regularly killing off projects that are not creating value for your customers

 

In most organizations, abandoning or killing off a project feels like a failure. The person responsible for that project runs the risk of losing status, resources, and in some cases even their job.

But, in organizations that have truly embraced uncertainty, killing off a project is a sign of success.

 

It means that you are open to the possibility of your customers and your market changing, and will not sink additional resources into something that you have learned is no longer likely to succeed.

 

If you’ve reached the point where a project lead is comfortable saying, “I think we should kill this idea and put our resources elsewhere,” you are well on your way to building a truly Agile organization.

 

To keep the momentum going around this, you might want to:

Acknowledge and celebrate team and project leads who are brave enough to adjust course and substantially redirect a project already in progress.

 

Make sure that the success of every project is measured not just by operational metrics such as “on time” and “on a budget,” but also by the value, it creates for your customers.

 

Keep a record of what projects were abandoned and for what reason so as to avoid these projects being accidentally revisited without this context.

 

When specific Agile practices are not working for your team, you work together to change them

 

It might feel like the ultimate end goal of an Agile journey is to have your entire organization 100% onboard to a single, stable, and consistent set of practices and rituals. But this goal runs deeply counter to the very first statement of the Agile Manifesto: “Individuals and interactions over processes and tools.”

 

As the individuals in your organization and the individuals you serve change, so too must your Agile practices. If the way you work is evolving to meet the needs of your team, this is a sign that you are being true to the principles of Agile, not a sign that you have failed at implementing the practices of Agile.

 

To keep the momentum going around this, you might want to:

 

Share information about your evolving Agile practices beyond your team. Some teams I’ve worked with, for example, send out memos stating what change they made, what effect they hoped this change would have, what effect it actually had, and what they are going to do about it moving forward.

 

Have open and candid conversations with your team, at both a group and one-on-one level, about what value they are deriving from Agile practices.

 

Put a name to the set of practices that are working for you and your teams, such as the Spotify model or Enterprise Design Thinking, to foster a sense of collective ownership of the practices that you are utilizing.

 

You are withholding important information until the next year planning or budgeting meeting

 

One of the dangers with regular organizational cadences is that they can compel people to withhold important information until what they consider to be the officially sanctioned time and place.

 

This can happen when engineers don’t share critical blockers until the next daily stand-up, or when marketers shelve customer insights until the next campaign planning cycle. This self-imposed delay can result in wasted resources, missed opportunities, and crippling bottlenecks when that regular cadence does come around.

 

If this is happening, you might want to:

Schedule more frequent “check-ins” between infrequent meetings to track progress and share new information.

 

Have a discussion with your team about what type of information constitutes an out-of-cadence “emergency” and should be communicated immediately, and to whom it should be communicated.

 

Create a formal template or practice for handling “emergency” information that comes in from customers, clients, or executives. This helps you retain some sense of structure and procedure while still accounting for the reality that important new information could arise at any time.

 

You are working a certain way “because it’s Agile”—and that’s it

Just because a particular practice is Agile does not mean that it’s a good fit for your organization or that it will help you deliver more value to your customers in a faster and more flexible way.

 

If the best justification you can think of for working a certain way is “because it’s Agile,” then it is very unlikely that you and your teammates are cultivating a shared sense of purpose and ownership over the way that you work together.

 

If this is happening, you might want to:

Communicate clearly that whatever practices you implemented initially are only a starting point. Set clear expectations that the way your team or organization is working six months from now should and must be different from what that framework or methodology looks like on paper.

 

Push back on absolute quantitative metrics for Agile adoption (such as “20% of our projects must be Agile within the next five years”) because they can easily turn the entire universe of Agile practices and principles into a meaningless checkbox.

 

Run a deprivation test; cease all Agile rituals and ceremonies for a week, and see what happens. Afterward, run a retrospective with your team and use this as an opportunity to “hit reset” and initiate a frank conversation about what is and is not working.

 

The three guiding principles we have covered so far capture three concepts that are at the very heart of what makes Agile such a powerful movement: customer centricity, collaboration, and openness to change.

 

Committing to any one of these three guiding principles can make an immediate difference for any team or organization looking to work with, not against, the realities of a fast-changing world.

 

But the real magic happens when these three principles are applied together to create a harmonious cycle of learning, collaborating, and delivering.

 

As this cycle gains momentum, so too does the belief that real change is possible. The alchemical union of principles and practices at the heart of Agile provides teams not just with a new way of working, but with the permission to ask why they are working a certain way—often for the first time.

 

As teams take more ownership over the way that they work, they become more comfortable challenging the fundamental beliefs and expectations that have allowed “business as usual” to persist through prior attempts at organizational change.

 

Creating space for meaningful, sustainable, and ongoing change means accepting the fact that there is no single framework or set of practices that will lead every organization to guaranteed success.

 

Agile reminds us that organizations are not operational puzzles to be solved, but rather collections of individuals working together to meet the fast-changing needs of their customers. This means that every individual has a role to play in making their organization fast, flexible, and customer-first.

 

In this sense, “Agile for Everybody” is not just a statement about the broad applicability of Agile principles, but also a reminder that Agile is at its most potent and transformative when everybody in an organization, regardless of their level, their team, or their role, apply those principles to their day-to-day work.

 

Leadership in the Agile Organization

Many of my conversations with Agile practitioners took a swift and immediate turn toward the topic of leadership. A 2006 Harvard Business Review article titled “Embracing Agile” speaks to how many Agile initiatives wind up being undermined by the very organizational leaders who often demand them:

 

When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as “Just enough to be dangerous.” They may throw around agile-related terms (“sprints,” “time boxes”) and claim that their companies are becoming more and more nimble. But because they haven’t gone through training, they don’t really understand the approach.

 

Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.

 

For what it’s worth, I believe that training is only part of the solution here. I know many people who have been through hours and hours of Agile training and still have no clear idea of what is expected of them and why.

 

The bigger challenge, as I learned from my first experience with Agile, is that the underlying values of Agile—the substantive ideas lurking behind all that shiny jargon—are often at odds with the behaviors and expectations that organizational leaders have developed through years of successfully navigating “business as usual.”

 

Indeed, each of our three laws of organizational gravity also exerts a force on our organization’s leaders,

 

The Three Laws of Organizational Gravity often create situations in which the people feel that it is against their best interest to bring to the attention of their managers any information about the way they work or the people they serve that might be perceived as “bad news.”

 

This adds up to a situation in which leaders have a very difficult time gaining an accurate understanding of the challenges facing both their colleagues and their customers.

 

And that, in turn, can leave employees feeling misunderstood and powerless—how are their leaders supposed to make things better if they don’t even understand what’s going on?

 

When organizational leaders have largely been insulated from the on-the-ground challenges facing both their employees and their customers, they are often left with the impression that “business as usual” is working just fine. It is no surprise, then, that their initial interest in Agile often privileges incremental operational improvements over substantive cultural change.

 

When enlisting team and organizational leaders in support of any Agile initiative, it is important to start from a place of empathy, not an accusation. Do not assume that leaders are being willfully dismissive or difficult if they don’t seem to understand what these new ideas mean, or if they seem hung up on superficial improvements.

 

Break the cycle of strategically withholding and sugar-coating information by being open, honest, and candid, and giving the leaders with whom you are speaking a chance to respond in kind.

 

We’re trying to help people really understand this, on both a personal and a corporate level. It doesn’t really matter what tools you use—Agile, Scrum, whatever.

 

The thing we all have in common is either we’re adding value as defined by the marketplace or we’re adding waste. And, in order to continue adding value and eliminating waste, we need to be constantly improving. What a lot of leaders don’t anticipate is that “continuous improvement” means continuously admitting to and addressing your own mistakes.

 

Indeed, while “continuous improvement” is an easy enough concept to agree to in theory, organizational leaders are often ill-prepared for the emotional labor that goes into admitting that their best efforts may still have fallen short, or that the needs of their organization may have outpaced their own vision or experience.

 

This is particularly important when we are working with the people who often feel like they have the most to lose in a transition toward Agile practices: middle managers.

 

Many of these middle managers have spent their entire careers carefully managing the flow of information upward and downward—something that actually runs quite counter to the mandates for transparency and collaboration that come with Agile.

 

As IBM CMO Michelle Peluso pointed out, implementing the practices and principles of Agile often means reshaping the role of middle management:

 

In huge companies, there are often a lot of people who sit at the middle management layer and spend all day moving information up and down.

 

They gather information from their direct reports, they send it up the ranks, they get information from farther up the ranks, and they break it down and share it with their direct reports. If you are truly Agile, you don’t need this kind of hub-and-spoke model.

 

The teams have to solve things themselves. If you’re going on an Agile journey, you need to embrace the idea that you’re going to get rid of some middle management.

 

The good news is, a lot of great middle managers can be repurposed to do more impactful things. While there is less need for shuttling information up and down, there is a much greater need for things like Agile coaching and cross-functional guild leadership. That can open up exciting new career paths for people.

 

But it can be very hard for people who are used to measuring their success by the number of direct reports they have, and suddenly find themselves in this cross-functional world.

 

There’s a real sense of, “We earned our way here, we spent years getting to this point.” It’s very frustrating and very emotionally difficult for people, for very real reasons. You need to approach it with empathy and tackle it head-on.

 

I do think that oftentimes when you think about describing Agile to a team, it is framed up in terms of why it’s good for the organization at large. But it’s also important to ask, “Why are YOU going to be a better leader if you go Agile?” For starters, having a successful Agile transformation on your résumé can make you a hot commodity.

 

But beyond that, embracing Agile means that you get to work side by side with data scientists, creatives, engineers—you get to really see and understand how they do their work. It creates an extraordinary learning environment.

 

It’s important to be very clear about what people can expect individually; there are some really personal things about the journey to Agile that I think need to be understood and reinforced.

 

Respecting this personal dimension gives us a way to approach Agile that holds true to its founding values. It gives us a chance to build stronger and more transparent relationships between and among organizational leaders.

 

And it gives us a chance to approach colleagues who may be fearful or resistant to change with openness, empathy, and curiosity that will ultimately help us implement Agile principles and practices in a more impactful and inclusive way.

Recommend