Exploring Team Agility With ScrumHere are some useful resources for those who have adopted Scrum:
Team Agility is neither a variant of Scrum or Kanban although it incorporates practices of both. 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 our Scrum as Example page.
Defining Team Agility
In order for a framework to be effective it must meet the following requirements. It has to:
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:
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.
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 in reality, it is incomplete.
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:
Most Agile team frameworks/methods only meet the 2nd and 3rd requirement listed above. The anti-patterns for these missing requirements are:
Numbers 4 and 5 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
Anti-Patterns of not taking the approach described above
The Roles, Events, Practices and Artifacts of Team-Agility
Because most people are familiar with Scrum, this page 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. But, since Team-Agility is intentionally an operating model, so in it, as well as our approach to Scrum, other ways of manifesting these intentions will also be presented. The main difference between Team-Agility and Scrum is mostly that Team-Agility does not use Scrum terminology while Scrum does.
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.
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.
Team-Agility’s backbone 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.
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 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.
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.
The Product Owner (or equivalent)
Objective: Have a clear liason 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:
In larger development groups they may work with Product Managers in order to determine what the business stakeholders need.
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.
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:
Planning and Managing the Work
Cadence means to do things on a regular beat. There are two different approaches to accomplish this:
Objective: Have minimal delays from the start of working on an item until its completion.
Why: Short cycle time of work minimizes delays and waste. It also improves feedback.
Options: Decompose work into small stories before designing and writing stories.
A sprint provides a time-box within which to fit work. This “time-box” is from the time after planning to the time we set for the end of work. The sprint probably has another day for the demo and retrospection. Scrum’s time-boxing has some interesting side effects which are quite useful such as the following.
Cadence means to have a regular beat. In Scrum, sprints provide the regular beat. The start and end of a sprint provides timing for the following.
Scrum uses the sprint to set the cadence of the above actions. Scrum’s structure provides a great degree of discipline for the teams. This is one reason Scrum is a good starting point for many teams wanting to become Agile.
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 necessary. 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
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 stand-ups 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.
Feedback on our Work
Objective: 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.
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.
Options: 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.
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 backburner 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 timeframes:
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.
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.
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.
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.
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).
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.
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.
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:
Use Visual Controls
Objective: Use visual controls to:
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.
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.
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.