PMI Agile Practice Guide

BUY-IN TO APPROACH TRUST IN TEAM DECISION-MAKING POWERS OF TEAM TEAM SIZE EXPERIENCE LEVELS ACCESS TO THE CUSTOMER/BUSINESS PROJECT CRITICALITY OF THE PRODUCT OR SERVICE INCREMENTAL DELIVERY

AGILE SUITABILITY FILTERS

Multi-tiered structure. Emphasize value delivery Fixed-price increments Not-to-exceed time and materials

As mentioned earlier in this practice guide, the Agile Manifesto values "customer collaboration over contract negotiation." Many project failures stem from breakdowns in the customer-supplier relationship. Projects incur more risk when those involved in the contract take the perspective of winners vs. losers. A collaborative approach is one that pursues a shared-risk-reward relationship, where all sides win. Some contracting techniques that can formalize this dynamic include the following:

Burndown charts to see where the project is going over time.

Burndown charts show

Burnup charts show the work completed.

Burnup charts show

In iteration-based agile, the team works in iterations (timeboxes of equal duration) to deliver completed features. In flow-based agile, the team pulls features from the backlog based on its capacity to start work rather than on an iteration-based schedule. Agile life cycles are those that fulfill the principles of the Agile Manifesto

CHARACTERISTICS OF AGILE LIFE CYCLES

A combination of predictive, iterative, incremental, and/or agile approaches is a hybrid approach.

CHARACTERISTICS OF HYBRID LIFE CYCLES

Iterative life cycles improve the product or result through successive prototypes or proofs of concept. Projects benefit from iterative life cycles when complexity is high, when the project incurs frequent changes, or when the scope is subject to differing stakeholders' views of the desired final product.

CHARACTERISTICS OF ITERATIVE LIFE CYCLES

Another approach is to use a combination of agile and predictive approaches throughout the life cycle. A combination of both predictive and agile approaches are used in the same project. Using both predictive and agile approaches is a common scenario. It would be misleading to call the approach agile since it clearly does not fully embody the agile mindset, values, and principles. However, it would also be inaccurate to call it predictive since it is a hybrid approach.

COMBINED AGILE AND PREDICTIVE APPROACHES

Organizational culture is difficult to change, but the most important cultural norm in an organization willing to try any new method or technique is enabling a safe work environment. Only in a safe, honest, and transparent environment can team members and leaders truly reflect on their successes to ensure their projects continue to advance, or apply lessons learned on failed projects so they do not fall back into the same patterns.

CREATING AN ENVIRONMENT OF SAFETY

Cross-functional team members, Product owner, and Team facilitator

In agile, three common roles are used:

This approach might be used when a particular element is non-negotiable or not executable using an agile approach. Examples include integrating an external component developed by a different vendor that cannot or will not partner in a collaborative or incremental way. A single integration is required after the component is delivered.

LARGELY AGILE APPROACH WITH A PREDICTIVE COMPONENT

The guidance of the most widespread agile methods such as Scrum and eXtreme Programming focus on the activities of a single, small, usually colocated, cross-functional team. While this is very useful for efforts that require a single team, it may provide insufficient guidance for initiatives that require the collaboration of multiple agile teams in a program or portfolio. A range of frameworks (such as the Scaled Agile Framework, Large Scale Scrum, and Disciplined Agile) and approaches (e.g., Scrum of Scrums) have emerged to cater to just such circumstances. More details on these can be found in Annex A3.

Many projects incur dependencies, even when they are not managed within a given program. For this reason, it is necessary to have an understanding of how agile works within an existing program and portfolio management context.

Predictive life cycles. Iterative life cycles. Incremental life cycles. Agile life cycles.

No life cycle can be perfect for all projects. Instead, each project finds a spot on the continuum that provides an optimum balance of characteristics for its context. Specifically,

Troubleshooting Possibilities Agile chartering for alignment-values, principles, and working agreements

Pain Point Unclear working agreements for the team

Tailoring Options Retrospect more often and select improvements.

Project Factor Rate of process improvement required by the level of team experience

Tailoring Options Many teams find that using a cadence (in the form of a regular timebox) helps them demo, retrospect, and take in new work. In addition, some teams need more flexibility in their acceptance of more work. Teams can use flow-based agile with a cadence to get the best of both worlds.

Project Factor Demand pattern: steady or sporadic

Retrospectives help the team learn from its previous work on the product and its process. One of the principles behind the Agile Manifesto is: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

RETROSPECTIVES The single most important practice is the retrospective because it allows the team to learn about, improve, and adapt its process.

The first value of the Agile Manifesto is individuals and interactions over processes and tools. What better responsibility for a servant leader to take on than to take a hard look at processes that are impeding a team's or organization's agility and work to streamline them? Servant leaders should also look at other processes that are lengthy, causing bottlenecks and impeding a team's or organization's agility. Examples of processes or departments that may need to be addressed include finance, change control boards, or audits.

SERVANT LEADERS REMOVE ORGANIZATIONAL IMPEDIMENTS

These approaches use: Very short feedback loops, Frequent adaptation of process, Reprioritization, Regularly updated plans, and Frequent delivery.

Some teams have evolved project life cycles to use iterative and incremental approaches. Many teams discover that when they explore the requirements iteratively and deliver more often incrementally, the teams adapt to changes more easily. These iterative and incremental approaches reduce waste and rework because the teams gain feedback.

Promoting self-awareness; Listening; Serving those on the team; Helping people grow; Coaching vs. controlling; Promoting safety, respect, and trust; and Promoting the energy and intelligence of others.

The following characteristics of servant leadership enable project leaders to become more agile and facilitate the team's success:

the qualitative (people's feelings) and quantitative (measurements) data, then using that data to find root causes, designing countermeasures, and developing action plans. The project team may end up with many action items to remove impediments.

The retrospective is about looking at

Purpose. Work with the team to define the "why" or purpose so they can engage and coalesce around the goal for the project. The entire team optimizes at the project level, not the person level. People. Once the purpose is established, encourage the team to create an environment where everyone can succeed. Ask each team member to contribute across the project work. Process. Do not plan on following the "perfect" agile process, but instead look for the results. When a cross-functional team delivers finished value often and reflects on the product and process, the teams are agile. It does not matter what the team calls its process.

The role of a servant leader is to facilitate the team's discovery and definition of agile. Servant leaders practice and radiate agile. Servant leaders approach project work in this order:

Story Points Remaining Story Points Done Kanban Board Feature Chart Product Backlog Burnup Chart Earned Value in an Agile Context Cumulative Flow Diagram of Completed Features

WHAT ARE SOME MEASUREMENTS IN AGILE PROJECTS?

Some projects optimize for speed of delivery. Many businesses and initiatives cannot afford to wait for everything to be completed; in these cases, customers are willing to receive a subset of the overall solution. This frequent delivery of smaller deliverables is called an incremental life cycle Incremental life cycles optimize work for delivering value to sponsors or customers more often than a single, final product. As the project continues, the team may deviate from the original vision. The team can manage the deviations, because the team delivers value sooner.

CHARACTERISTICS OF INCREMENTAL LIFE CYCLES

Predictive life cycles expect to take advantage of high certainty around firm requirements, a stable team, and low risk. In order to achieve this approach, the team requires detailed plans to know what to deliver and how. When the team creates detailed requirements and plans at the beginning of the project, they can articulate the constraints. By emphasizing a departmentally efficient, serialized sequence of work, predictive projects do not typically deliver business value until the end of the project.

CHARACTERISTICS OF PREDICTIVE LIFE CYCLES

Educate stakeholders around why and how to be agile. Support the team through mentoring, encouragement, and support. Help the team with technical project management activities like quantitative risk analysis. Celebrate team successes and support and bridge building activities with external groups.

CONSIDER THESE SERVANT LEADER RESPONSIBILITIES

Cross-functional teams consist of team members with all the skills necessary to produce a working product. In software development, cross-functional teams are typically comprised of designers, developers, testers, and any other required roles. The cross-functional development teams consist of professionals who deliver potentially releasable product on a regular cadence. Cross-functional teams are critical because they can deliver finished work in the shortest possible time, with higher quality, without external dependencies.

Cross-functional team member defined

What do we need to do to advance this piece of work? Is anyone working on anything that is not on the board? What do we need to finish as a team? Are there any bottlenecks or blockers to the flow of work?

Flow-based agile has a different approach to standups, focusing on the team's throughput. The team assesses the board from right to left. The questions are:

However, in high-change projects, there is more complexity than one person can manage. Instead, cross-functional teams coordinate their own work and collaborate with the business representative (the product owner). When working on an agile project, project managers shift from being the center to serving the team and the management. In an agile environment, project managers are servant leaders, changing their emphasis to coaching people who want help, fostering greater collaboration on the team, and aligning stakeholder needs. As a servant leader, project managers encourage the distribution of responsibility to the team: to those people who have the knowledge to get work done.

PROJECT MANAGERS USE SERVANT LEADERSHIP

Tailoring Options Consider using the various test-driven development practices. This mistake-proofing discipline makes it difficult for defects to remain undetected.

Project Factor The quality of the product increments is poor

Tailoring Options To scale from one to several agile teams, with minimal disruption, first learn about agile program management or formal scaling frameworks. Then, craft an approach that fits the project context.

Project Factor More than one team is needed to build a product

The value of project managers is not in their position, but in their ability to make everyone else better.

ROLE OF THE PROJECT MANAGER IN AN AGILE ENVIRONMENT

Executive management's willingness to change; Organization's willingness to shift the way it views, reviews, and assesses employees; Centralization or decentralization of project, program, and portfolio management functions; Focus on short-term budgeting and metrics versus long-term goals; and Talent management maturity and capabilities.

Readiness for Change What are some examples of these change-friendly characteristics include:

People are more likely to collaborate. Teams finish valuable work faster. Teams waste much less time because they do not multitask and have to re-establish context.

TEAM COMPOSITION When teams think about how to optimize the flow of value, the following benefits become apparent:

When the team completes a release or ships something. It does not have to be a monumental increment. It can be any release, no matter how small. When more than a few weeks have passed since the previous retrospective. When the team appears to be stuck and completed work is not flowing through the team. When the team reaches any other milestone.

Team members may decide to retrospect at these key times:

Dedicated people Increased focus and productivity Small team, fewer than ten people Cross-functional team members Develop and deliver often Deliver finished value as an independent team Integrate all the work activities to deliver finished work Provide feedback from inside the team and from others, such as the product owner Colocation or ability to manage any location challenges Better communication Improved team dynamics Knowledge sharing Reduced cost of learning Able to commit to working with each other Mixed team of generalists and specialists Specialists provide dedicated expertise and generalists provide flexibility of who does what Team brings their specialist capabilities and often become generalizing specialists, with a focus specialty plus breadth of experience across multiple skills Stable work environment Depend on each other to deliver Agreed-upon approach to the work Simplified team cost calculations (run rate) Preservation and expansion of intellectual capital

What are attributes of Agile Teams?

Individuals and interactions Working software Customer collaboration Responding to change

What are the four values of Agile Manifesto?

Troubleshooting Possibles Agile chartering for purpose-vision, mission, and mission tests

Agile Pain Point Unclear purpose or mission for the team

Why are we doing this project? This is the project vision. Who benefits and how? This may be part of the project vision and/or project purpose. What does done mean for the project? These are the project's release criteria. How are we going to work together? This explains the intended flow of work.

At a minimum, for an agile project, the team needs the project vision or purpose and a clear set of working agreements. An agile project charter answers these questions:

One of the antipatterns typically seen in standups is they become status meetings. Teams who have traditionally worked in a predictive environment may tend to fall into this antipattern since they are used to providing a status. Another antipattern typically seen in standups is that the team begins to solve problems as they become apparent. Standups are for realizing there are problems—not for solving them. Add the issues to a parking lot, and then create another meeting, which might be right after the standup, and solve problems there. Teams run their own standups. When run well, standups can be very useful, provided the nature of the team's work requires intense collaboration. Make a conscious decision about when the team needs, or can effectively use, standups.

Attipatterns during Standups

Work is decomposed into departmental silos, creating dependencies that prevent accelerated delivery instead of building cross-functional teams with guidance from centers of competencies. Procurement strategies are based on short-term pricing strategies, rather than long-term competencies. Leaders are rewarded for local efficiencies rather than end-to-end flow of project delivery or optimizing the whole (in regard to the organization). Employees are specialized contributors with limited tools or incentives to diversify their skills instead of building T-shaped specialists. Decentralized portfolios pull employees simultaneously onto too many projects at once instead of keeping them focused on one project at a time.

Conversely, there are other institutional characteristics that may be roadblocks to achieving the changes associated with organizational agility. Examples of these include:

Changes associated with accelerated delivery. Agile approaches emphasize delivering project outputs early and often. Changes associated with agile approaches.

DRIVERS FOR CHANGE MANAGEMENT All projects are about change. However, there are two key factors that further motivate the use of change management practices in an agile context:

Continuous integration. Test at all levels. Acceptance Test-Driven Development (ATDD). Test-Driven Development (TDD) and Behavior-Driven Development (BDD). Spikes (timeboxed research or experiments).

EXECUTION PRACTICES THAT HELP TEAMS DELIVER VALUE The following technical practices, many of which come from eXtreme Programming, may help the team to deliver at their maximum speed:

Agile teams are cross-functional, but the people often do not start off that way. However, many successful agile teams are made up of generalizing specialists, or "T-shaped" people. This means team members have both a focus specialty plus a breadth of experience across multiple skills, rather than a single specialization. Agile team members work to develop such characteristics due to intense collaboration and self-organization to swarm and get work done quickly, which requires them to routinely help each other. A single person's throughput is not relevant. Focusing on a single person's throughput may even be harmful if it creates a bottleneck for the rest of the team. The goal is for the team to optimize the delivery of finished work to get feedback. If the customer desires great results, such as rapid feature delivery with excellent quality, the team cannot be structured just with specialist roles in an attempt to maximize resource efficiency. The team's objective is flow efficiency, optimizing the throughput of the entire team. Small batch sizes promote working together as a team. The product owner's job is to make sure the team works on the highest-value work.

GENERALIZING SPECIALISTS

Iterations help a team create a cadence for delivery and many kinds of feedback. Teams produce increments of value for delivery and feedback. The first part of this delivery is a demonstration. Teams receive feedback about how the product looks and operates through a demo. Team members retrospect to see how they can inspect and adapt their process to succeed. Demonstrations or reviews are a necessary part of the agile project flow. Schedule the demonstration as appropriate for the team's delivery cadence.

HOW ITERATIONS AND INCREMENTS HELP DELIVER WORKING PRODUCT

Project teams may design a hybrid life cycle based on project risks. For example, a campus construction project may have multiple buildings to improve and build. An incremental approach would focus resources on completing some buildings earlier than others, accelerating the return on investment. Each individual delivery may be sufficiently well known to benefit from a predictive life cycle for that building alone.

HYBRID LIFE CYCLES AS FIT-FOR-PURPOSE

Team values, such as sustainable pace and core hours; Working agreements, such as what "ready" means so the team can take in work; what "done" means so the team can judge completeness consistently; respecting the timebox; or the use of work-in-process limits; Ground rules, such as one person talking in a meeting; and Group norms, such as how the team treats meeting times.

Here are some chartering ideas for team members to use as a basis for their social contract:

Each team's capacity is different. Each product owner's typical story size is different. Teams consider their story size so they do not try to commit to more stories than there is team capacity to complete within one iteration. When people are unavailable (e.g., holidays, vacations, or anything that prevents people from participating in the next set of work), the product owner understands that the team has reduced capacity. The team will not be able to finish the same amount of work as it finished in the previous time period. When teams have a reduced capacity, they will only plan for work that meets that capacity. Teams estimate what they can complete, which is a measure of capacity (see Section 4.10 for examples). Teams cannot predict with 100% certainty what they can deliver, as they cannot know the unexpected. When product owners make the stories smaller and teams see progress in the form of a finished product, teams learn what they are able to do for the future. Agile teams do not plan just once in one single chunk. Instead, agile teams plan a little, deliver, learn, and then replan a little more in an ongoing cycle. TIP Draw the team's attention to the antipattern and help the team to discover how to improve its standups.

How is Planning for Iteration-Based Agile Accomplished?

Visible and active executive sponsorship, Change management practices, including communication and coaching, Progressively pacing the adoption of agile practices on a project-by-project basis Incremental introduction of agile practices to the team; and Leading by example by using agile techniques and practices where possible.

However, in response to these organizational impediments to agility, project leaders can try various approaches to accelerate a cultural compatibility for:

In addition to servant leadership, team members emphasize their interpersonal and emotional intelligence skills—not just technical skills. Everyone on the team works to exhibit more initiative, integrity, emotional intelligence, honesty, collaboration, humility, and willingness to communicate in various ways so that the entire team can work together well.

INTERPERSONAL SKILLS VERSUS TECHNICAL SKILLS

Agile teams rarely limit their practices to one agile approach. Each project context has its own peculiarities, such as the varied mix of team member skills and backgrounds; the various components of the product under development; and the age, scale, criticality, complexity, and regulatory constraints of the environment in which the work takes place.

MIXING AGILE APPROACHES

How can the project team act in an agile manner? What can the team deliver quickly and obtain early feedback to benefit the next delivery cycle? How can the team act in a transparent manner? What work can be avoided in order to focus on high-priority items? How can a servant-leadership approach benefit the achievement of the team's goals?

Managing a project using an agile approach requires that the project team adopt an agile mindset. The answers to the following questions will help to develop an implementation strategy:

Troubleshooting Possibilities Ask the people who are part of projects to self-organize as cross-functional teams. Use servant leadership skills to help the managers understand why agile needs cross-functional teams.

Pain Points Siloed teams, instead of cross-functional teams

Figure 3-8 shows a small agile element within a chiefly predictive project. In this case, a portion of the project with uncertainty, complexity, or opportunity for scope creep is being tackled in an agile way, but the remainder of the project is being managed using predictive approaches.

PREDOMINANTLY PREDICTIVE APPROACH WITH SOME AGILE COMPONENTS

Troubleshooting Possibilities Servant leadership to work with this stakeholder (and possibly product owner).

Pain Point Impossible stakeholder demands

Troubleshooting Possibilities Reduce story size by splitting stories. Use relative estimation with the entire team to estimate. Consider agile modeling or spiking to understand what the story is.

Pain Point Inaccurate estimation

Troubleshooting Possibilities Rank with value including cost of delay divided by duration (CD3) and other value models

Pain Point Inefficiently ordered product backlog items

Troubleshooting Possibilities Plan to the team's capacity and not more. Ask people to stop multitasking and be dedicated to one team. Ask the team to work as pairs, a swarm, or mob to even out the capabilities across the entire team.

Pain Point Rush/wait uneven flow of work

Troubleshooting Possibilities Capture no more than three items to improve at each retrospective. Ask the servant leader to help the team learn how to integrate those items.

Pain Point Slow or no improvement in the teamwork process

Troubleshooting Possibilities A servant leader can help clear these obstacles. If the team doesn't know the options they have, consider a coach. Sometimes, the team needs to escalate stories the team or servant leader has not been able to remove.

Pain Point Team struggles with obstacles

Troubleshooting Possibilities Refactoring, agile modeling, pervasive testing, automated code quality analysis, definition of done

Pain Point Technical Debt (degraded code quality)

Troubleshooting Possibilities Instead of much upfront work, consider team spikes to learn. In addition, measure the WIP during the beginning of the project and see what the team's options are to deliver value instead of designs. Shorten iterations and create a robust definition of done.

Pain Point Too much upfront work leading to rework

Troubleshooting Possibilities Help sponsors and stakeholders craft a product vision. Consider building a product roadmap using specification by example, user story mapping, and impact mapping. Bring the team and product owner together to clarify the expectations and value of a requirement. Progressively decompose roadmap into backlog of smaller, concrete requirements.

Pain Point Unclear Requirements

Troubleshooting Possibilities Help the team learn that they self-manage their work. Consider kanban boards to see the flow of work. Consider a daily standup to walk the board and see what work is where.

Pain Point Unclear work assignments or work progress

Troubleshooting Possibilities Ask the team to check in more often, use kanban boards to see the flow of work and work in progress limits to understand the impact of the demands on the team or product. Also track impediments and impediment removal on an impediment board.

Pain Point Unexpected or unforeseen delays

Troubleshooting Possibilities Product owner and team workshop stories together. Create a definition of ready for the stories. Consider splitting stories to use smaller stories.

Pain Point Work delays/overruns due to Insufficiently refined product backlog items

Troubleshooting Possibilities Team defines definition of done for stories including acceptance criteria. Also add release criteria for projects.

Pain Point Work is not complete

Troubleshooting Possibilities Ask the product owner to become an integral part of the team.

Pain Point False starts, wasted efforts

Troubleshooting Possibilities User experience design practices included in the development team involve users early and often.

Pain Point Poor user experience

Troubleshooting Possibilities For software and non-software encourage the team always to be thinking "What is the simplest thing that would work?" and apply the agile principle of "Simplicity--the art of maximizing the amount of work not done". These help reduce complexity.

Pain Point Too much product complexity

Troubleshooting Possibilities Agile chartering for context-boundaries, committed assets, and prospective analysis

Pain Point Unclear team context

Troubleshooting Possibilities Consider the technical practices that work for the environment. Some possibilities are: pair work, collective product ownership, pervasive testing (test-driven and automated testing approaches) and a robust definition of done.

Pain Points Defects

The product owner is responsible for guiding the direction of the product. Product owners rank the work based on its business value. Product owners work with their teams daily by providing product feedback and setting direction on the next piece of functionality to be developed/delivered. That means the work is small, often small enough to be described on one index card. The product owner works with stakeholders, customers, and the teams to define the product direction. Typically, product owners have a business background and bring deep subject matter expertise to the decisions. Sometimes, the product owner requests help from people with deep domain expertise, such as architects, or deep customer expertise, such as product managers. Product owners need training on how to organize and manage the flow of work through the team. In agile, the product owners create the backlog for and with the team. The backlog helps the teams see how to deliver the highest value without creating waste. A critical success factor for agile teams is strong product ownership. Without attention to the highest value for the customer, the agile team may create features that are not appreciated, or otherwise insufficiently valuable, therefore wasting effort.

Product owner description

Tailoring Options Consider starting by training team members in the fundamentals of the agile mindset and principles. If the team decides to use a specific approach such as Scrum or Kanban, provide a workshop on that approach so the team members can learn how to use it.

Project Factor The project team members are inexperienced in the use of agile approaches

Predictive life cycle. A more traditional approach, with the bulk of planning occurring upfront, then executing in a single pass; a sequential process. Iterative life cycle. An approach that allows feedback for unfinished work to improve and modify that work. Incremental life cycle. An approach that provides finished deliverables that the customer may be able to use immediately. Agile life cycle. An approach that is both iterative and incremental to refine work items and deliver frequently.

Projects come in many shapes and there are a variety of ways to undertake them. Project teams need awareness of the characteristics and options available to select the approach most likely to be successful for the situation. This practice guide refers to four types of life cycles, defined as follows:

Servant leaders manage relationships to build communication and coordination within the team and across the organization. These relationships help the leaders navigate the organization to support the team. This kind of support helps to remove impediments and facilitates the team to streamline its processes. Because servant leaders understand agile and practice a specific approach to agile, they can assist in fulfilling the team's needs

SERVANT LEADER RESPONSIBILITIES

Facilitators help everyone do their best thinking and work. Facilitators encourage the team's participation, understanding, and shared responsibility for the team's output. Facilitators help the team create acceptable solutions. Servant leaders promote collaboration and conversation within the team and between teams. For example, a servant leader helps to expose and communicate bottlenecks inside and between teams. Then the teams resolve those bottlenecks. Additionally, a facilitator encourages collaboration through interactive meetings, informal dialog, and knowledge sharing. Servant leaders do this by becoming impartial bridge-builders and coaches, rather than by making decisions for which others should be responsible.

SERVANT LEADERS FACILITATE

Servant leaders work to fulfill the needs of the teams, projects, and organization. Servant leaders may work with facilities for a team space, work with management to enable the team to focus on one project at a time, or work with the product owner to develop stories with the team. Some servant leaders work with auditors to refine the processes needed in regulatory environments, and some servant leaders work with the finance department to transition the organization to incremental budgeting. The servant leader focuses on paving the way for the team to do its best work. The servant leader influences projects and encourages the organization to think differently.

SERVANT LEADERS PAVE THE WAY FOR OTHERS' CONTRIBUTION

Teams need a space in which they can work together, to understand their state as a team, and to collaborate. Some agile teams all work in one room together. Some teams have a team workspace for their standups and charts, and work on their own in cubicles or offices. When teams have geographically distributed members, the team decides how much of their workplace is virtual and how much is physical. Technology such as document sharing, video conferencing, and other virtual collaboration tools help people collaborate remotely. Geographically distributed teams need virtual workspaces. In addition, consider getting the team together in person at regular intervals so the team can build trust and learn how to work together. Some techniques to consider for managing communication in dispersed teams are fishbowl windows and remote pairing: Create a fishbowl window by setting up long-lived video conferencing links between the various locations in which the team is dispersed. People start the link at the beginning of a workday, and close it at the end. In this way, people can see and engage spontaneously with each other, reducing the collaboration lag otherwise inherent in the geographical separation. Set up remote pairing by using virtual conferencing tools to share screens, including voice and video links. As long as the time zone differences are accounted for, this may prove almost as effective as face-to-face pairing.

Team Workspaces

The third role typically seen on agile teams is of a team facilitator, a servant leader. This role may be called a project manager, scrum master, project team lead, team coach, or team facilitator. All agile teams need servant leadership on the team. People need time to build their servant leadership skills of facilitation, coaching, and impediment removal. Initially, many organizations invite external agile coaches to help them when their internal coaching capability is not yet fully developed. External coaches have the advantage of experience, but the disadvantage of weak relationships in the client organization. Internal coaches, on the other hand, have strong relationships in their organization, but may lack the breadth of experience that would make them highly effective.

Team facilitator

Encourage the team to work as triads of developer, tester, business analyst/product owner to discuss and write the story. Present the overall story concept to the team. The team discusses and refines it into as many stories as required. Work with the team to find various ways to explore and write the stories together, making sure all of the stories are small enough so the team can produce a steady flow of completed work. Consider becoming able to complete a story at least once a day.

There are many ways for the product owner to conduct backlog preparation and refinement meetings, including for example:

Just-in-time refinement for flow-based agile. The team takes the next card off the to-do column and discusses it. Many iteration-based agile teams use a timeboxed 1-hour discussion midway through a 2-week iteration. (The team selects an iteration duration that provides them frequent-enough feedback.) Multiple refinement discussions for iteration-based agile teams. Teams can use this when they are new to the product, the product area, or the problem domain.

There is no consensus on how long the refinement should be. There is a continuum of:

Require research and development; Have high rates of change; Have unclear or unknown requirements, uncertainty, or risk; or Have a final goal that is hard to describe.

These iterative, incremental, and agile approaches work well for projects that involve new or novel tools, techniques, materials, or application domains. (Refer to Section 3 on Life Cycle Selection). They also work well for projects that:

Teams use standups to microcommit to each other, uncover problems, and ensure the work flows smoothly through the team. Timebox the standup to no longer than 15 minutes. The team "walks" the Kanban or task board in some way, and anyone from the team can facilitate the standup. In iteration-based agile, everyone answers the following questions in a round-robin fashion: What did I complete since the last standup? What am I planning to complete between now and the next standup? What are my impediments (or risks or problems)? Questions like these generate answers that allow the team to self-organize and hold each other accountable for completing the work they committed to the day before and throughout the iteration.

What are Daily Standups?

The team can measure completed work in a feature burnup/burndown chart and in a product backlog burnup chart. These charts provide trends of completion over time, as shown in Figure 5-4. Feature burnup/burndown charts may show that requirements grew during the project. The features complete line shows that the team completes features at a regular pace. The total features line shows how the project's total features changed over time. The features remaining burndown line shows that the rate of feature completion varies. Every time features are added to the project, the burndown line changes.

What are Feature Charts?

As the team completes the features usually in the form of user stories, the team periodically demonstrates the working product. The product owner sees the demonstration and accepts or declines stories. In iteration-based agile, the team demonstrates all completed work items at the end of the iteration. In flow-based agile, the team demonstrates completed work when it is time to do so, usually when enough features have accumulated into a set that is coherent. Teams, including the product owner, need feedback to decide how early to ask for product feedback. As a general guideline, demonstrate whatever the team has as a working product at least once every 2 weeks. That frequency is enough for most teams, so team members can get feedback that prevents them from heading in a wrong direction. That is also frequent enough so that the teams can keep the product development clean enough to build a complete product as often as they want or need to. A fundamental part of what makes a project agile is the frequent delivery of a working product. A team that does not demonstrate or release cannot learn fast enough and is likely not adopting agile techniques. The team may require additional coaching to enable frequent delivery.

What are demonstrations/reviews in Agile?

They are for in the moment measurements. They help a team understand how much more work they have and whether the team might finish on time. Ex Kanban Board

What are lead time, and cycle time (predictability measures) and when are they are useful

The backlog is the ordered list of all the work, presented in story form, for a team. There is no need to create all of the stories for the entire project before the work starts—only enough to understand the first release in broad brushstrokes and then sufficient items for the next iteration. Product owners (or a product owner value team that includes the product manager and all relevant product owners for that area of the product,) might produce a product roadmap to show the anticipated sequence of deliverables over time. The product owner replans the roadmap based on what the team produces.

What is Backlog Preparation?

The purpose of these meetings is to refine enough stories so the team understands what the stories are and how large the stories are in relation to each other.

What is Backlog Refinement?

Traditional EVM metrics like schedule performance index (SPI) and cost performance index (CPI) can be easily translated into agile terms. For example, if the team planned to complete 30 story points in an iteration, but only completed 25 then the SPI is 25/30 or 0.83 (the team is working at only 83% of the rate planned).

What is a Earned Value in An Agile Context

A cumulative flow diagram, illustrated in Figure 5-7, shows the work in progress across a board. If a team has many stories waiting for test, the testing band will swell. Work accumulation can be seen at a glance.

What is a cumulative flow diagram?

Earned value in agile is based on finished features, as shown in Figure 5-5. The product backlog burnup chart shows completed work compared to total expected work at interval milestones or iterations.

What is the Product Backlog Chart?

A facilitator from the team leads them through an activity to rank the importance of each improvement item. Once the improvement items are ranked by the team, the team chooses the appropriate number to work on for the next iteration (or adds work to the flow if flow-based).

What is the facilitator's role at the Sprint Retrospective?