Increasing Your Team Agility with Several Small Interventions

Cover Page Of Limmat Reframe´s Agile Booster Deck
  • Simple guidance on long established agile practices. Definitely not too fancy to get started on agility.
  • Get the shareable and printable version of this card-deck that can serve your team as inspiration for new patterns of behaviour.
  • Discover what practices the most profitable businesses use  & how you can do the same, to your advantage!

Sign up to our weekly mail below & get instant access to this free deck:

How to improve team agiliy in a measurable fashion

An overview of LimmatReframe´s approach to boosting the agility of teams

Defining targets for the Team

In an initial brief meeting an understanding for the current context is being established. This allows to tailor details of the program to your team´s specific circumstances. Based on your needs a focus could e.g. be either operational or strategic agility.


Initial measurement of learning culture & Team Agility

In an online survey, participants are asked about the priority & maturity level of certain forms of collaboration that underlie agility. This allows for an individual adjustment of the workshop contents as well as a measurement of success after completion of the project


Team-specific information

Based on the strategic priorities of the teams and the results of the initial survey on working methods and team dynamics, the team receives targeted information by e-mail. These contents serve to briefly introduce agile concepts & working methods, which are later applied in practice in the workshop.


Goal Setting & Activation Workshop

The time allocation of the activities and methodical focus of the workshop are determined based on the initial data collection of the team. Strategic priorities are broken down into subgoals and agile ways of working are applied to team specific cases. This produces a relevant output in terms of content & gives the team practical experience with agile ways of collabrotion.

The Agile Booster Deck

LimmatReframe Agile Booster Deck overview

Many firms have agile ambitions. Some approach their journey towards a more agile future top down. But agile is something that has to happen „on the ground“ – within dispersed teams across the organization. The importance of top-support non-withstanding here
are a few practices that are at the core of different streams of practice of agile.
The best of success on your transformation towards valuing:

  • Individuals and Interactions Over Processes and Tools
  • Working Software Over Comprehensive Documentation
  • Customer Collaboration Over Contract Negotiation
  • Responding to Change Over Following a Plan

Self-Organized and Cross-Functional Teams

Agile Booster Deck LimmatReframe showing the cross functional Teams

A self-organizing and cross-functional team consists typically of a Product/Service Owner, a team that delivers the work and a person that facilitates the team to get things done (the so called “Scrum Master”).

How it works

The team is self-organizing and has all the capabilities to deliver the work. It has 3 to 9 members. It chooses itself how best to accomplish the work.

  • Product Owner is accountable for the properties & business value of the product.
  • Scrum Master ensures that the Scrum Team can perform at their best.
  • Team is responsible for delivering the work.

What you achieve

  • creating room for creativity, innovation, self-organization and acknowledgment for my team’s expertise.

Kan-Ban Board and visualization of to do's & Work in Progress

Agile Booster Deck LimmatReframe showing the Kan-Ban-Board visualization of WIP

Initially popularized in Lean-Management the Kan-Ban Board serves as a visual representation of the work a team has agreed to complete in a sprint/ iteration. This representation should be accessible to all team-members physically or digitally.

How it works

  • Visual signals: For each work item a card/post-it is created on a big wall visible for everyone in the team (for teams located in different locations, online “wall” application exist – e.g. Trello)
  • Columns: For each specific activity a column is created. All columns together represent a workflow (exemplary columns: to do, in progress, done).

What you achieve

  • an increase in coordination and information sharing especially with remote teams
  • an increase in workflow efficiency & continuous delivery
  • a visualization and forecast of resource requirements for upcoming work
  • Everybody sees who is working on what & how much is currently being worked on

Product Backlog

Agile Booster Deck LimmatReframe showing the Product Backlog

The backlog is a prioritized list of everything that is known to be needed to be done/get developed for a product/service. It is the single source of client requirements.

How it works

  • Order the list (e.g. by added value to client) based on client feedback.
  • Items within the backlog can be re-prioritized whenever priorities change.
  • Items at the top of the backlog are described in detail, while the resolution of the items decreases with their priority
  • Prioritized items have a clear description, a definition of “done”, an estimated time requirement and highlight the value add.

What you achieve

  • a higher engagement from your client since she/he sees his input having an impact on your prioritization.
  • a wiser prioritization due to the visibility of the backlog and regular (e.g. monthly) reviews with the entire team.

Definition of Ready

Agile Booster Deck LimmatReframe showing the Definition of Ready

The Definition of Ready (DOR) functions as an agreement of terms between project owner and working team on how working packages need to be specified prior to the team “picking up work”.

How it works

  • The DOR contains certain criteria a User Story must meet before it can be assigned to the Sprint Backlog.
  • The Team mutually defines the DoR.
  • e.g. must be ‘enough’ detail; and estimated, etc.
  • Is functional and scalable to meet any industry

What you achieve

Clear set of criteria based on which the work is understood to be described in sufficient detail as that it could be “picked” up by the team for an upcoming sprint.

  • a common understanding of what is required to be able to start a work package.
  • transparency in working packages requirements and hence reducing decreased quality in delivery due to assumptions.

Definition of Done

Agile Booster Deck LimmatReframe showing the Definition of Done

The definition of Done (DOD) holds the shared acceptance criteria (or understanding of what needs to be done) that are common to every single item/work package delivered by the team.

How it works

The basic experience from which this practice grew is, that if everyone working on any work package has a shared understanding of what “done” means for that work package, opportunity for frustrating disagreements are reduced. Therefore, 

  • the idea is to define clear and understandable criteria for the delivery team of “done” when planning work packages and deliverables.
  • The team mutually defines the DoD (e.g. tested, documented, etc.).

What you achieve

  • a common understanding of what is required to finish a work package.
  • transparency in delivering work packages and hence reducing decreased quality in delivery due to assumptions and misunderstandings.

Sprint Backlog

Agile Booster Deck LimmatReframe showing the Sprint Backlog

The sprint backlog functions as the single source of “what needs to be done” during a cycle. It is owned and updated by the team.

How it works

  • Contains the User Stories for the current iteration (Sprint) and becomes the To-Do list for the Sprint.
  • The content of the Sprint Backlog will not be changed during the Sprint.
  • User Stories might be refined in the Sprint.
  • This artefact is owned and updated by the Team.

What you achieve

  • Clear overview for the team how much has been and still needs to be achieved for the cycle´s / sprints goal.
  • Clear overview on how much work is in progress (and therefore value at risk).
  • Increased transparency throughout the team.

SPRINTS - Delivery in Iterations

Agile Booster Deck LimmatReframe showing the delivery in iterations Sprint-based delivery

Sprints are a reoccurring development cycle of a consistent duration (e.g. one month) with the goal to create a usable version of a product/service (increment) by the end of each cycle.

How it works

  • Break down bigger deliverables into items that can be developed in cycles & are of value on their own.
  • Each cycle focuses on delivering a useable and functional version of a product/ service that has the most value to the client (increment).
  • No changes of the scope for the Sprint during the Sprint - whereas future-directed priorities and requirements might change.

What you achieve

  • delivering value to clients from an early stage on.
  • a higher commitment from my team to achieve the sprint (e.g. monthly) goals agreed on in the sprint planning.
  • reducing risk and increasing predictability to (e.g. one month).

Sprint Planning

Agile Booster Deck LimmatReframe showing the Sprint Planning

The Sprint Planning is an event where the team agrees upon a visible (e.g. monthly) plan that shows all identified items/work packages required to deliver a usable and functional deliverable (increment) at the end of the cycle.

How it works

At the beginning of each sprint, agree with the entire team on:

  • what tasks are required to deliver towards the current goal
  • how much of the backlog can be delivered and
  • how the work will be done

What you achieve

  • transparency within my team on what is worked on.
  • increased ownership & commitment within my team, since they decide what tasks are required and how they are performed to achieve our monthly goals.

Sprint Review

Agile Booster Deck LimmatReframe showing the Sprint Review

The sprint review inspects the product/ service deliverable at the end of the cycle/sprint in order to adapt the priorities within the product/service backlog. Involves the whole team and other stakeholders (e.g. clients).

How it works

  • Demonstrate to project stakeholders at the end of the cycle what has been developed (inspect).
  • The goal is to get challenged and collect feedback on the delivered value to the client.
  • Product Owner accepts or rejects the Sprint output.

What you achieve

  • an increased engagement and trust level from your client since they are involved regularly, can provide feedback and see the added value of project deliverables increase over time.
  • project adaptability and a reduction of risk and impact of sunk cost.

Sprint Retrospective

Agile Booster Deck LimmatReframe showing the Retrospective
The retrospective is a meeting with the entire team to reflect after each cycle/sprint on what went well and what less in the cycle. The goal of this session is to identify and implement actions for improved collaboration going forward.

How it works

A team meeting after each cycle with the sole purpose to understand the “lessons learned” and decide jointly how to act moving forward. Ask each team member:

  • What worked well for us?
  • What did not work well for us?
  • What actions can we take to improve our process going forward?

What you achieve

  • collaboration, trust and ownership within the team – we are transparent about what works and what not.
  • continuous improvement.

Dailies / Regular Check-ins

Agile Booster Deck LimmatReframe showing the Daily or Regular Check-ins

Dailies are a 15-minute check-in meeting with the objective to inspect the progress towards the (sprint's) goal and to align within the team how to complete the outstanding work.

How it works

The team meets to check-in on the progress:

  • What did I do yesterday?
  • What will I do today?
  • What dependencies do I see that my team needs to be aware of?
  • Do I see any impediments?

The event is time-boxed, usually takes no more than 15 minutes – and takes place at exactly the same time each day.

What you achieve

  • better team collaboration & commitment – agreement on how to work together & to be self-organizing to accomplish the agreed goal.
  • reducing risk of not delivering products/ services at the end of the cycle since my team raises impediments/issues early.

Work in Progress Limits

Agile Booster Deck LimmatReframe showing the WIP Limits

WIP -Limits are a simple limitation on work items/packages that are worked on by the team at any given time.

How it works

  • Provide a limit of work items/packages that can be worked on by the team. When the limit is “maxed-out”, the team needs to finish the existing items before adding new items to the workflow.
  • On a Kanban board each work item/packages is visualized by a card.

What you achieve

  • to reduce work overload by limiting the number of items marked as “work in progress”
  • to deliver value to the client sooner by focusing on a few work items at a given time that are driven by the team and not just one individual
  • reducing value at risk the team is handling

Establishing new behavioral patterns

Based on the agile booster deck - which provides concise access to 12 agile practices - I offer to lead each your teams through reviews in the months following the workshop in order to firmly anchor these forms of cooperation in everyday life.


Measuring the impact on the team

After completion of the project and the support of the teams in the context of the retrospectives, the setting of priorities for different types of cooperation and their maturity within the teams will be surveyed once again.
By comparing the initial and final results, the success of the project can be quantified. 

Sign up to our weekly mail below & get instant access to this free deck:


  • Marsick und Watkins (2003) paper on the DLOQ Questionnaire (also of interest, by the same: DOI: 10.1177/1523422303005002002)
  • Joël Krapf's PHD thesis "Lernkulturentwicklung zur Steigerung der Organisationalen Agilität" (available online)
  • 9 lies about work (Marcus Buckingham & Ashley Goodall)

have a look at my Resources page, too.

  • Zurich, Switzerland
  • +41 (0) 79 769 29 42
  • Book a 30´ call with Sebastian