Contents

Introduction A Metaphor for Team Agility- GPS Systems Defining Team Agility The principles of Team Agility The elements of Team Agility The objectives, theory and values of Team Agility The objective of Team Agility The theory of Team Agility Team Agility values Anti-Patterns of not taking this approach Why we must consider separate practices in the context of the whole Describing Team Agility from a Scrum perspective Roles The Product Owner (or equivalent) The Team Agility Coach The development team Planning and managing the work Cadence of the team Estimation Manage WIP by Focusing on Finishing Planning the work

Getting and responding to feedback Keeping people aligned on a daily basis Feedback on the work Continuous improvement Artifacts Product Backlog Iteration (Sprint) Backlog Building the increment Artifact transparency Definition of Ready and Done Practices Based on Explicitly using Lean Thinking Start and finish stories in the same sprint Mitigate and manage dependencies across teams Use Visual Controls Have visible and explicitly-defined workflows Test-First Understanding culture and change Improving your company’s culture (chapter)

Introduction

Team Agility is based on Lean-Thinking and Agile.  It can be considered an integration of Scrum, Kanban and eXtreme Programming based on Lean-Thinking. It is based on principles which have proven to be valuable and recognizes no one-size-fits-all. Team Agility is defined by looking at what is needed to be accomplished at the team level and then incorporates practices of Scrum and Kanban when appropriate. This enables a concrete set of practices while being tailored for the teams using it.

This page presents how to implement the practices of Team Agility. See Team Agility: Lean-Agile at the Team for more information on its principles. If you are using Scrum and having challenges with it, see Scrum as Example.

A metaphor for team agility – GPS systems

Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.

Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.

Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost.  This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.

Defining Team Agility

In order for a framework to be effective it must meet the following requirements. It has to:

• Provide a good starting point for the team involved.
• Avoid overwhelming people with too much change.
• Be specific because people like a well-defined starting point.
• Make it clear to the team what their objectives are so they can readily refine the practices as needed.
• Set the stage for the next level of learning.

The Principles of Team Agility

Although Team Agility provides a description of how teams can best do their work in an Agile organization, the focus is not just on the team. Agile should not be about developer iterations but rather on faster realization of business value with predictability, sustainability and high quality. Since the team is just a part of the people, workflow and artifacts required to achieve this, Team Agility must be taught within that context. Team Agility is therefore designed with the following principles in mind:

• A recognition that the work of the team is part of a bigger picture.
• Teams are part of a complex system and we must consider how the teams interact with the rest of the organization and not focus on just optimizing the work being done by the team.
• Train the team in their part of the Agile Product Management workflow of identifying and refining those parts that are about to be built.
• Recognize we need to select practices that are appropriate for the team and not take a pre-defined set of practices that attempt to work everywhere.

The elements of Team Agility

Team Agility is comprised of the following core elements: principles, roles, workflow and artifacts. Principles are belief systems and attitudes that provide guidance for getting our work done. Our roles, workflow and artifacts will reflect these principles. Roles describe the responsibilities of the individuals involved at the team level. Workflow includes both events and how work gets done. Artifacts are information stored as separate documents or in tools that relate to the work being done as the workflow in which the work is accomplished. While specifics are needed in order for people to adopt team agility, the objectives for each practice is given to enable people to move beyond any starting point. In addition to the objectives, each practice, workflow and artifact will be presented as a spectrum of maturity levels. This will both show different options teams have as well as clarifying the objectives of each of these.

Here are essential principles of Team Agility.

• Adopt a whole system thinking approach.
• All work must be visible.
• Respect both individuals and the culture within which they work.
• Have feedback loops be as short as possible.
• Work only on items of the greatest value to the business.
• How Team Agility is designed to be adopted.

One often hears the goal in defining a framework is for it to be simple. This has led to many simplistic processes. The goal is to be just sufficient. I prefer to call this elegance – enough to get the job done but not so much it complicates understanding. Saying something is simple somewhat implies it’s complete and simple. But it’s more likely to be incomplete and simple.

We want incomplete in an intelligent way. Incompleteness when starting a new way of doing things is important. Trying to learn it all at the beginning is too much for people. The dilemma is that we can’t stay incomplete. As people learn they need to go to the next steps. So we have to start with an incomplete understanding, an incomplete approach, but one which is designed for the people at hand. We have to be intelligent about incompleteness because the starting point has to do the following:

1. Provide a good starting point for the team involved (a one-sized fits approach will miss much of the time).
2. Avoid overwhelming people.
3. Specific because people’s understanding is not deep.
4. Make it clear to the team what their objectives are.
5. Set the stage for the next level of learning.

Most Agile team frameworks/methods only meet the 2nd and 3rd requirement listed above. The anti-patterns for these missing requirements are:

1. The approach is either not-appropriate or misses opportunities that are readily available.
2. The team will not know what to do when impediments to their process come up.
3. The team will not move to the next level when possible.

Not having numbers 4 and 5 above often result in teams abandoning key practices without adopting other practices that would be more appropriate and thereby losing the ability to achieve the key objective the practice was designed for.

While we don’t want to be complex, the goal is not the opposite of complex. It is understanding.

The objectives, theory and values of Team Agility

The objectives of Team Agility

The objective of team agility is to help the organization achieve business agility – the quick realization of business value predictably, sustainable and with high quality. This requires both collaboration across teams and teams working within the context of the organization. This implies agreements such as the Guardrails for the Team and their Scrum Master must be made.

The theory of Team Agility

Systems thinking is considering a system being an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems). Changing one part of the system affects other parts and the whole system, with predictable patterns of behavior. Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system or the operations may result in system failure. The goal of systems thinking is systematically discovering a system’s dynamics, constraints, conditions and elucidating principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field for achieving an optimized end state through various means.

The foundation of Team Agility is Lean Thinking which essentially adds the importance of leadership, attending to time and a commitment to quality. Continuous improvement is based on improving the system being used and creating an environment within which teams can self-organize while attending to the needs of the whole.

For more, see Systems Thinking Philosophy as it Applies to Frameworks, Methods, and Approaches.

While from the Scrum Guide, “Scrum’s roles, events, artifacts, and rules are immutable” none of Team Agility is. As an operating model it is intended to be used to find the best roles, events, artifacts and rules applicable to a team’s situation.

Objective: Our intention is to achieve business agility. We should not striving for local optimization at the team level. Looking at the entire system, or at least at that aspect we have influence on, improves our effectiveness.

Why: We want self-organization to occur within the context of the value stream the development group is in.

Options: Self-organize within the context the development group finds itself in. This requires collaboration between management and the team-coach.

Team Agility values

Team Agility is consistent with the Scrum values of commitment, courage, focus, openness and respect. Team Agility is designed to help facilitate these values when the system people are make it hard for them to become evident.

Anti-patterns of not taking this approach

Here are the anti-patterns, the patterns of undesirable behaviors, that result when you not take the approach describe above.

1. Teams focus on optimizing their work, losing sight of the real objectives.
2. This optimization of the teams comes at the expense of overall value realization.
3. Teams complete stories and features but can’t deliver value as required components being built from other teams are often missing.
4. If we can’t use a practice exactly as stated teams tend to stop doing them and don’t find other practices that could meet the objectives just as well with less effort.

See why there is so much bad Agile out there.

A common anti-pattern is when teams just decide to use Scrum or Kanban instead of looking to see which is more applicable. In reality, one should not be chosing but taking what works from both. One useful step, however, is to see if Scrum is applicable to your team.

Why we must consider separate practices in the context of the whole

When following Scrum the suggestion (demand actually) is not to change any of its core practices, roles, rules or artifacts. However, nothing in Team-Agility is sacrosanct other than ensuring you’re working on your real problems, we must be more careful. Changing one aspect of Team-Agility will undoubtedly have an impact on others. In the same way you can’t take the transmission out of a better car than yours and expect an improvement (it probably won’t even fit) you can’t change practices without attending to how that interacts with others.  For this reason a sub-section entitled: Related practices, etc.: will be included for each aspect of Team-Agility when effectively changing it requires attending to other practices, etc.

Describing Team-Agility from a Scrum perspective

Team-Agility is not a variant of Scrum. However, because most people are familiar with Scrum, this page, with just a few exceptions, describes Team-Agility on an outline based on Scrum. The intention for each role, event, artifact, and rule of Scrum, as described in the Scrum Guide, will be discussed here. However, Team-Agility is based on Lean-Thinking, human psychology and organizational development. Therefore, other practices that both extend Scrum and are sometimes inconsistent with Scrum are presented as useful.

Roles

Team-Agility does not require changing the roles of the team to be Product Owner, Development Team and Scrum Master. Scrum’s objective here is to have a team that focuses on delivering value. Different roles imply different responsibilities. Team-Agility fosters the intended alignment with its focus on time from start to finish as well as an alignment around value realized.

Options:

• Scrum: Product Owner, Development team, Scrum Master
• Team-Agility: Use Scrum’s terms or use the roles in place that people are attached to

The Product Owner (or equivalent)

Objective: Have a clear liaison for the team to go to understand what work needs to be done and why.

Why: The team requires direction on what they should be working on.

Options: Model after Scrum’s Product Owner. Responsibilities include:

• be available to the team to answer questions
• help the team understand the definition of done (DoD) for each story
• manage and refine the team backlog as needed
• sequence the work on the team backlog appropriately and coach the team if they are not working in the proper order
• assess and accept work completed
• work with release management
• In larger development groups they may work with Product Managers in order to determine what the business stakeholders need.

See more on the product owner’s role here.

The Team Agility Coach

Coaching is the practice of supporting individuals, teams, and an organization through the process of achieving a professional result. It differs from consulting, mentoring, and training. It involves more questioning and facilitating than doing particular tasks for the person or team or group. It is more focused on process, discovery, transition, leadership, and mindset than it is on particular projects. The goal is to help people to develop new mindsets to do Lean-Agile, to acquire a new set of tools, and to make adjustments to processes and structures.

The coach helps them gain confidence and effectiveness so that they can sustain the gains.

Coaches seek to build the capability of management, teams, and individuals so that they can quickly become self-sustaining. This involves ever-increasing competency in specific knowledge and skills. The end result is an organization that is well on its way in the transition to an enterprise with the foundation, direction, and process guidance to get there.

• Objective: Have a coach for the team to assist them in improving their definition of workflow and in following it. They are responsible for being the liaison between the team and the rest of the organization.
• Why: Development team members tend to get heads down on their work. Someone needs to be attending to continuous improvement as well as people following their own agreements with each other. Sometimes team members will get stuck but want to push through when an outside observer can notice and help them
• Options: Having a Team Agility Coach be responsible for shepherding the team, creating a trustful environment, facilitating team meetings, asking the difficult questions, removing impediments, making issues and problems visible, keeping the process moving forward, and socializing Lean-Agile within the greater organization. They will also:
  • Protect the team from interruptions to whatever extent possible
  • Be a coach to the team in assisting them to get their work done in a more effective and efficient way
  • Be responsible for the non-work artifacts that the team produces and uses

The Development Team

The ideal case of having a cross-functional development is undeniable in most situations. However, as Agile has spread to organizations with multiple levels of architecture, shared services and ops, it is rare to actually be able to achieve this. In many cases it is not even cost effective to do so. The intention is to reduce handoffs, increase collaboration and create an environment for innovation.

Objective: Have all of the capabilities needed to create value quickly in a predictable, sustainable and high quality fashion. This does not include dependencies between other teams doing work, but relates to when people’s capabilities that are shared across several teams are needed, for example, business intelligence or UX. Development teams should have all of the skills required to produce the software being developed. Ideally this will be for the software being released in its entirety. In larger organizations it may be just a component or module of what is being built. While it is virtually always best for a team to be cross-functional (meaning they have all the skills necessary to implement the PBIs being built) it is often the case that some capabilities are shared with other teams.

Why: Cross-functional teams facilitate the removal of delays and handoffs, while speeding feedback and delivery of value. They also foster creativity and a team spirit.

Options: Where-ever possible create cross-functional teams. When not possible, see if teams being dependent upon can provide team members needed for the necessary time. If all capabilities cannot be made to exist in the team then manage the dependencies on the shared capabilities via a Kanban board so that the delays created by using people outside of the team can be known and managed.

See Achieve Cross-Functionality to the Extent Possible for more.

Planning and managing the work

Cadence of the team

Cadence means to have a regular beat.

The heart of Scrum is the sprint (called an iteration outside of Scrum). A sprint provides a time-box within which work takes place. This “time-box” is from the time after planning to the time set for the end of the work to be completed. Using time-boxing has many positive side effects and should be abandoned with care. Otherwise any changes to the sprint will almost certainly cause damage to the team’s work.

In Scrum, sprints provide the regular beat. The start and end of a sprint provides timing for the following.

• Ensuring the product backlog is ready for the sprint
• When to do planning for the sprint
• When to see what has been completed
• When to demo the work of the sprint
• When to do a retrospection

Scrum uses the sprint to set the cadence of the above actions.

Kanban’s flow model does not require a time-box. However, a cadence to do the above collaborations is useful. In either case the cadence provides for different teams to have a set time for collaboration. A flow model requires the addition of other practices in order to achieve what Scrum achieves with its sprint.  These include:

Objectives: There are several objectives of the sprint. These include:

• A cadence for planning, working, demos, reflection, computing velocity
• A reality-check on whether stories have been truly completed
• shortening the time for potential delivery of the work being done
• A deadline that keeps things a little urgent but not too urgent.
• Providing visibility of the work going into the sprint and what is being accomplished
• having minimal delays from the start of working on an item until its completion.

Why: Short cycle times of work minimizes delays in workflow feedback, communication. This lessens the creation of unplanned work. Visibility of work and a common cadence improves the collaboration of teams working together.

Options:

• Use sprints (or iterations)
  • Include focusing on having any stories that are started in an iteration to get completed in the iteration
  • Have stories be sided so that they can be completed within 2-3 days of their being started
• Use a flow model. This has us look at removing delays and those things contributing to them
  • have small stories
  • have a focus on finishing
  • track cycle-time for each story
  • at predetermined times reflect on where you are so you:
    • have an opportunity to pivot
    • can compute your velocity
  • explicitly have a cadence for planning, working, demos, reflection, computing velocity (these may now be decoupled from each other if there is an advantage to that)

See The Objective of Time-Boxing for more.

Scrum without sprints is not kanban

We often hear teams saying they are doing Kanban when what they’ve really done is abandon sprints.  This is not Kanban. Kanban requires that teams work in a manner that directly provides what sprints provide as side effects.

Suggestion for improving sprints

If a team is having difficulty with their sprints I suggest that they don’t just abandon them. Instead, start following the practices in Kanban in an attempt at doing your sprints better. Improvement is almost certain. One of two things will likely happen. You might find that your sprints improve and doing them is advisable. You might also find that you no longer need them and get the objectives they were trying to achieve.

Estimation

This section has been put in its own chapter. Read it here.

Manage WIP by Focusing on finishing

• Objective: Speed delivery, lower unplanned and wasteful work, create a focus on completion.
• Why: Too much WIP causes delays and unplanned work.
• Options: Focus on finishing and managing work in process.

See full chapter Manage Work In Process (WIP) By Focusing on Finishing.

Planning the work

With the exception of teams which cannot plan their work (e.g., some maintenance organizations, shared services to some extent) planning to some degree is usually useful. If time-boxing is being used it is important to plan the time-box at the beginning of it. In Scrum this is called Sprint planning. If a flow model (e.g., Kanban) is being used, planning is not require except that enough work must be on the product backlog for the team to pull when they need it.

Objective: Improve people’s focus and help people to see the work in order to enhance dependency management.

Why: While planning too far out is usually wasteful, no planning creates surprises and chaos. A blend of micro-planning (what is the next thing we’ll do) and macro-planning (what are we going to do over the next period of time is require both for focus and to see what’s coming up. Longer term planning is often necessary for stakeholders to see when value will be realized.

Options: Micro-planning – a focus on finishing and the use of kanban. Macro-planning can be accomplished by iteration planning or SAFe’s program increment planning. Macro-planning likely will require some form of estimation and velocity

Getting and responding to feedback

Keeping people aligned on a daily basis

Teamwork requires people know what each other is doing, what they can do to help, and who they can call on to help.

• Objective: Have everyone know what each other is doing so they can help out when needed.
• Why: Without awareness of what each of the team members are doing they can’t really be a team. It also won’t be possible to pivot as needed.
• Options: Daily standups are recommended unless mob-programming or paired programming is being done and they are not necessary. Kanban style boards with explicit workflow, while not eliminating the need for the stand-ups, can make standups shorter.
• In Scrum: Daily stand-ups.

Feedback on the work

• Objective (What): Get feedback from Product Owners and make any necessary corrections on direction. Also, get analysis, design, code and test done in short cycles to get feedback on each step.
• Options (How): Demonstrate the software on a regular basis. if the Product Owner is close to the team frequent demonstrations is advisable. Demonstrations can still be done on a regular cadence for people other than the Product Owner.
  • In Scrum: Feedback from Product Owners at end of sprint. Feedback on analysis, design, code and test accomplished by having to complete stories in a sprint.
• Why: Even with good requirements until the product is demonstrable there is always risk that the wrong thing is being built or something better might be better.

Continuous improvement

Objective: Continuously improve the rate of value delivery in a predictably, sustainable manner with high quality. This spans improvement of workflow, quality of code, and fitness for use.

Why: Impediments slow the team down. If they are not made visible then fixing them is often put on a back-burner unintentionally. After initial gains many people are satisfied. The risk is that teams make initial improvements only to fall back and end up where they started. The level of wasted effort in software development is typically extremely high and can be significantly reduced.

Options: Improvement can be made on three time-frames:

1. Continuously
2. Daily
3. On a cadence

True continuous improvement requires explicit workflow and all work being visible. Scrum’s approach with daily standups and retrospectives are also recommended with the exception of daily standups are sometimes not required when pairing or mobbing is also being done.

Do regular retrospectives. Have explicit workflow (Kanban). Make all work visible. Do daily standups. Recommend all of these except can skip daily standups if mob-programming. Attend to the value stream impedance scorecard during retrospectives to see if it is improving. Track impediments discovered on a list so they are visible and not forgotten.

In Scrum: Inspect and adapt anytime a challenge is encountered. Take time to consider how to improve during the retrospective. Anything that slows down delivery is an impediment. Daily standups and retrospectives should also look for impediments.

In addition: Ensure all impediments and blockages are visible.

Why: It is easy for teams to get caught up in their work. There are also often opportunities to improve things if they are kept top of mind. If they are not made visible then fixing them then they may be forgotten about or opportunities to fix them may be lost.

Options: Keep a list of impediments and make any blockages visible on the board.

Artifacts

Depending upon whether a time-boxed based model such as Scrum or a flow based model such as Kanban is being used there will be 2 or one backlog. In both cases a product backlog will contain the items to be built. These are specified by the Product Owner (or equivalent). When time-boxing is used, another backlog, one specifically for the time-box is required. In a flow model, the product backlog will contain both unrefined and ready to develop items.

Product Backlog

It is important to have clarity on what is being built. The product backlog and, if time-boxes are used, the iteration backlog (see below) con

Requirements and Backlog Refinement

Ensure items to be worked on are ready to be worked on

• Objective: Items are not ready to be worked on until it is known what it takes to complete. This includes having success criteria and knowing what capabilities it takes to complete them.
• Why do it: Working on well-defined, understood, right-sized items improves both effectiveness and efficiency.
• Options: Use Given-When-Then or the equivalent. DoR includes size limits, dependencies DoD includes testable specifications. This requires the use of Definition of Ready and Definition of Done.
• In Scrum: Not discussed, but implied.

The appropriate number of items on the backlog are ready to be worked on at the appropriate time

• Objective: Have enough backlog items be ready to be pulled from as appropriate. If Scrum is being used then at the beginning of iteration planning enough stories need to be ready to work on that will sill the sprint. If a flow model is being used the backlog should be refined in a just-in-time manner to give the team work to pull from as needed.
• Why: If too many items are ready then too much refinement will have been done and there is possible wasted effort. If too few are ready then the team may not have enough work to pull.
• Options: Refine the backlog on a periodic or continuous basis.
• In Scrum: Not discussed, but implied.

Iteration (Sprint) Backlog

The sprint backlog only exists when time-boxing is being used as in Scrum or Scrumban. When a flow model is being used, the same objective must still be met, but the items are just the next ones to be pulled on the product backlog.

• Objective: Have a list of stories that the team can work on and finish by the end of the sprint.
• Why: Creates focus. Enables planning. Provides visibility on what needs to be done next.
• Options: Best to have items on the sprint be focused on creating value either through delivery or feedback.

Building the increment

When time-boxing (e.g., Scrum, Scrumban) is being used this is the output at the end of each sprint. When a flow model is being used the team must ensure they have increments built on a regular basis.

• Objective: Create potentially shippable product on a regular, frequent basis.
• Why: If it can be released, value can be realized. If it can’t, feedback on what is being built can be achieve.
• Options: Start with minimum business increments and create vertical slices from it (use business evolution).

Artifact transparency

Definition of Ready and Done

Definition of Done mindset is one of not starting the implementation (or even the next step in a workflow) until you’ve determine how you will know you are done. This includes not only immediate functional acceptance criteria but can also adhering to standards and regulations, and meeting non-functional criteria such as creating or updating documentation and obtaining approval from specific stakeholders. We have found that starting work before making these criteria explicit is one of the leading causes of unpredictability and re-work.

A Definition of Ready mindset is one of not starting the implementation (or the next step in a workflow) until you’re ready to get it to Done. Over time, a team’s Definition of Ready will expand to incorporate additional readiness elements that the team has found to cause failure, rework, and other types of waste when not attended to.

Practices based on explicitly using Lean Thinking

Scrum is a partial implementation of Lean principles. It therefore encourages, perhaps even forces, several improvements. Lean Thinking prescribes transparency in intention. The items listed in this section are somewhat implied by Scrum, but Team Agility suggests making them explicit.

Start and Finish Stories in the Same Iteration

• Objective: Have a short time between the beginning of a story until it is completed to provide:
  • feedback on the stories functionality
  • feedback on the time it took to build the story
  • feedback on any dependencies that might not have been noticed
  • value in moving the solution forward
• Why: this removes delays in workflow, feedback, getting and using information which create unplanned work. It also makes explicit that we shouldn’t have separate analysis, design, code and test sprints.
• Options: this is the way it pretty much needs to be done
• In Scrum: Implied but not explicitly demanded.

Commentary: The Scrum Guide tells us:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective.

During the Sprint:
• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development
Team as more is learned.

The best way to accomplish this is to have small stories that are ready to be worked on when the iteration starts. If the stories are able to be completed in 3 days or less, and if the team focuses on finishing open ones before starting new ones, the chances of having completed stories be completed throughout the iteration rise.

This removes delays in workflow, feedback, getting & using information which create unplanned work. It also makes explicit that we shouldn’t have separate analysis, design, code and test sprints. Options: stories always need to be small In Scrum: Implied but not explicitly stated Unfortunately, this is not always understood. Understanding the why of a practice always makes it more likely it will actually get done

Mitigate and manage dependencies across teams

• Objective: Minimize the cost of dependencies across teams.
• Why: Dependencies between teams usually result in delays in the workflow and can create additional work and unpredictability.
• Options: There are several different approaches that can be taken to eliminate or mitigate dependencies:
  • Using technical practices. The use of mocks, quality design and proper use of dependency injection can either eliminate or at least mitigate many technical dependencies.
  • Changing the structure of the teams. Core teams that are not quite cross-functional can often be temporarily supplemented with people on the teams on which they are dependent upon.
  • Improving the workflow. By creating visibility of the workflow and managing queues between the teams, the adverse affects of these dependencies can be mitigated.
  • Large scale planning. Events similar to SAFe’s program increment planning event can identify dependencies across teams and help teams prepare for their management.
• In Scrum: Scrum does not discuss cross-team dependencies.
  

Use Visual Controls

• Objective: Use visual controls to:
  • show rate of completion of work (e.g., burn down charts)
  • see if stories are being worked in proper order
  • see time taken for each step (e.g., CFD)
  • see type of work being done
• Why: Executives, managers and others dependent upon the team need to see their progress. Visual controls helps the team stay coordinated
• Options: Burn-down / burn-up charts. Cumulative flow diagrams. Special charts as needed.
• In Scrum: Scrum uses information radiators, not visual controls.

Have visible and explicitly-defined workflows

• Objective: Improve collaboration within teams and make it easier for people to move from team to team when required.
• Why: Teams have a great deal of tacit knowledge about their work. While many members may believe that they understand the agreed upon process, experience shows otherwise. Visible and explicitly defined workflows convert this tacit knowledge into explicit knowledge. This also makes it easier for people to move from one team to another.
• Options: The use of Kanban boards (even when doing Scrum) accomplish this with very little overhead. The test is if someone outside of the team can read the board for a few minutes and then after a 10 minute conversation with someone on the team can understand what the team process is.
• In Scrum: Scrum does not discuss explicit workflows.

Test-First at the team

Understanding culture and change

Improving your company’s culture

Agile is intended to create a new culture.  Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being.  While trust and respect is a key value of Agile, it should be a key value for every approach. The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it. This chapter discusses how cultures are a result of management systems in an organization and how to change both the management system and thereby the culture of an organization.

Read the chapter How to improve your culture.