Increasing Your Team Agility with Several Small Interventions

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

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.

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

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.

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

• 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

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

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

• 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

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.

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.

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

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

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.

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

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

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

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

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.

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

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

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

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

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

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?

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

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.

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.

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

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

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

• 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