Skip to content

Implementing agility in a team

In this section we are going to talk about aspects that we should be aware of when implementing Scrum in a team.

Cultural changes to highlight

These are some worth mentioning aspect when implementing agility, for which we want to take care of and address the methodology change properly:

  • Organization model > Service model: Management would be removing impediments for the team to meet the goals, asking “how can I help” and leaders providing strategic directions to the self-organized teams. This is a deep change in how the management is going to be addressed as we go further in the agile implementation journey.

  • Team management > Self organized teams: Promote self-organized teams, they will become more proficient as they would be removing impediments. Let them come up with solutions and be thoughtful in what they need to change to improve the results (go beyond the goal).

  • Roles > Blurring: Current roles could (and should) blur when agility comes in. Be aware of team’s skill sets are well balanced and they can fulfill project requirements.

  • Skills > All skills are supplied inside each team: Be careful of team’s required skills are available to come up with an increment by the end of the sprint. The team must be able to produce the increment, according the committed sprint goal, as a collective result.

  • Releases > Continuous delivery: Every 2 or 3 weeks (initially 3) Three weeks long for the duration of the sprint is a good starting point. Each time a sprint is finished the team must act as if they would be shipping the code to production environment, regardless of the fact that sometimes that would not happen.

  • About code > Collective ownership of code: There is no room for ego here, teammates do not have ranges nor titles. They account for the sprint goal as a team, so avoid talking about proprietary code, or activities that just one person thinks it is his solely responsibility.

  • Continuous improvement > Retrospectives, tell it like it is: trust on each other. Leverage face-to-face communications among team members, be respectful, but thoughtful regarding things that need to be changed, no matter if we are talking about people, tools or processes, the team must identify and eliminate roadblocks by itself.

  • Teammate accountability > Everybody is accountable: there is nowhere to hide. Every person in the team is accountable for the sprint goal, for the entire project. They must be holding back each other for the goal they were committed to.

  • Face-to-face communication > Transparency and trust: Embrace and promote personal and straight communication. Better results come from people interacting directly, in a face-to-face fashion. Scrum elements provide transparency. Be trustful (and trust) and supportive (and support) each other.

Before going deeper, we must describe some ideal conditions under which the process is more likely to succeed:

  • Roles: from the team standpoint, there will be a single source of truth. PO and Customer roles must be defined, and responsibilities clearly identified according to Scrum definitions. Think about the Customer role as the one who is charge of providing the requirement definitions, and who can set expectations about what is valuable for the business. It does not matter if that person is not the “real” customer, he can pretend to be a Customer as long as he or she knows the business, and can depict what the “real” customer wants.

  • The “development team”: If for any reason inside the team a kind of “sub-team” arises, it would be desirable to depict work items using colors apart (or tags) for each “sub-team”. Attention must be payed to not break-down Scrum's philosophy about sprint target: it is a collective responsibility for the team to get right on time to the sprint committed due date.

  • Single backlog: Ideally, there should be a single backlog, including all tasks needed to come up with an increment that adds value by the end of the sprint. By keeping a single product backlog, we can prioritize and get a good overview on how the Sprint is going on as a whole. User stories inside backlog can be identified by mean of tags (or colors, for example) such as “kind of task” (feature, enhancement, bug), “component” (client sdk, server sdk, library, etc), or “sub-team” .

  • Mid size sprint duration: initially the recommended duration is of 3 weeks long. Such duration provides a good balance between time to develop the sprint, and time to see the results, inspect and adjust. Also, it is not too short to overwhelm people with scrum ceremonies and preparation. As a first definition, three weeks is good enough, in the future this duration would be changed according to environmental, organizational, technical, cultural or some other reason demanding to change it. Discussions pointing out this kind of changes arise mainly during retrospective meetings.

Setting up for the first sprint

The following are things to prepare for the first sprint execution. Please note that we will not be starting the whole things from scratch every time, some of these things will remain unchanged and useful in further sprints.

Important

Before each sprint can start up, as a general rule, User Stories in the product backlog must be “ready to be pulled out” in order to be considered during the Sprint Planning. For the very first Sprint, the Product Owner must take care of providing sufficient User Stories to fulfill the Sprint Backlog, in the first sprint planning session. This remains true for further Sprints, but is relevant to mention because this is a pre-condition for the kick-off.

  • Definition of done must be specified, written down, and published for the team to be known at any time. At least an initial one must be coined. “Ready to go to production” can be a used as starting point, but please be realistic about what “done” means for your project. This definition might be changed later, based on what the team considers to be “done” by that moment.

  • Definition of ready: this is not mandatory, but it can help to identify which of the User Stories in the Product backlog need a break-down. This definition is used to check if a User Story in the Product Backlog is ready to be pulled by the team during the Sprint Planning of the upcoming Sprints. This definition must be published and always visible for the team, the same as Definition of Done does.

  • Define first product backlog

  • Backlog contain US from the whole system.

  • Backlog must be prioritized; this is PO’s absolute responsibility. Choose non-consecutive numbering scale, for example 10, 50, 100 letting enough space to allocate stories in between if eventually needed. Numbers are only for ordering, their value doesn't represent relative importance, for example: a priority of 100 is greater than 50, but it does not mean that 100 is twice important than 50. Just use it for ordering US. o Check that USs in the product backlog are ready to be taken, if not then tag or label them so they will be ignored during sprint planning for the upcoming sprint

  • Choose a suitable name for the sprint: each sprint must have a name or phrase recalling why we are doing this, what we are committed to, an elegant way to say something about what we are going to do. Further sprints should have their own names too, therefor be smart about naming, to give the team a reason to fight for.

  • Let the team come up with a solution: unless there is a reason to give pretty sharped US to the team, let them be creative and figure out how to address the development to come up with a solution that satisfies requirements stated in the US. Product owner can address the expectation by means of the scope, description, and acceptance criteria of the User Story. Avoid telling the team how to address the development task.

Sprint Planning meeting

This activity can have a duration of up to 8 hours and is the first activity of each Sprint; each sprint must start with this event. Be aware of having enough User Stories in a “ready to be taken” state by the time the Sprint Planning is going to take place.

  1. Pre-requisites: there are enough USs in the product backlog “ready to be taken” for the team to start the Sprint Planning Session.
  2. Input:
    1. Product backlog
    2. Projected capacity for the sprint
  3. Goal: The purpose of the sprint planning meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the product owner enough confidence to let them do so.
  4. Outcome:
    1. Sprint backlog
    2. Sprint goal or name
    3. A defined sprint demo date
    4. A defined time and place for the daily scrum

Important

For upcoming sprints, it would be desirable to separate backlog refinement meeting from planning meeting, aiming to reduce the duration of sprint planning session, which typically lasts up to 8 hours long for sprints of three weeks, and even more for teams without previous experience. For example, with 3 weeks sprint duration, a meeting once a week of one hour duration could be performed, in which activities such as product backlog refinement, estimation and USs break down into smaller ones take place.

During planning meeting, scope and importance of User stories are set by the Product owner. Estimate is set by the Developers. Do respect what team estimates, and if you do not agree on estimations they provide, go back and make a more detailed review of the scope, try to reduce it by splitting User stories in smaller ones, or even take away that User story from the current sprint. Never try to handle Developers estimations.

Sprint planning agenda

  1. Describe sprint goal
    1. PO must present “his sprint goal”. This goal should be refined later, and summarize most important US to the Developers
    2. A set of US are considered initially candidates to fit into the sprint, those which when done will satisfy what sprint goal stands for
    3. By using a collaborative tool, candidate US must be arranged in a horizontal row, from most important at left-most side to less important ones at right-most end side.
    4. A set of tasks are considered to be committed for the planned sprint, those that the team considers that is able to deal with, within the Sprint defined time.
  2. Estimate stories
    1. The Dev Team must provide an estimation of each of the US, starting from the most important one. If estimation is becoming hard to give, then Dev team can eventually break-down each US in smaller ones, with the assistance of the PO.
    2. It is advisable to break down stories into smaller tasks, this way estimation tends to be more accurate. Also, these smaller tasks become very useful during daily meeting session to see how the team is performing in a more detailed way.
    3. Another benefit of breaking down stories into tasks is that dependencies show up, helping us to know up front if we are going to need help from external teammates, or special skills from someone to assist us during sprint with some task to be completed.
    4. Smaller tasks should be estimated, and each task should be large enough to fit in one workday as much. If it does not, it should be divided again until one day of estimated duration or less is achieved.
    5. Avoid stories with duration smaller than 0.5 workdays. These tasks must be regrouped with other to create a bigger one that can be handled by the team, avoiding micro-management.
    6. Team is committed to unveil what is “under the cover” on each US, so for each US a breakdown in smaller task is carried out. Whilst the team is unveiling each US, the PO must set boundaries on each.
    7. Everybody in the team is committed with the result of the sprint, not only with “his part”. If a sub-team division existed, that can could a “tunnel-vision” of the sprint backlog, be clear about the team commitment on sprint goal.
    8. Planning poker estimation technique (described more in advance) can be used for this aim.
    9. “How-to demo” descriptions of high-importance USs are filled in during this session
  3. Confirm sprint backlog
    1. Let the team decide which stories to commit to the planned sprint, let it recognize by itself what it can perform.
    2. Use Yesterday’s weather and gut feeling techniques for calculating team velocity
    3. Sprint backlog must be confirmed considering each US estimations and team velocity
  4. Close the meeting
    1. Define sprint demo date, and how is it going to be carried out.
    2. Define time and place for the daily scrum.

Daily meetings

The Daily Scrum (or daily meeting) is a 15 minutes time-boxed event for the Developers. It is held every day during the Sprint execution. In it, the Developers plan work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting Upcoming Sprint Work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work of the Sprint Backlog. The Daily Scrum optimizes the probability that the Developers will meet the Sprint Goal. Every day, the Developers should understand how they intend to work together as a self-organized team to accomplish the Sprint Goal and create the anticipated increment by the end of the Sprint.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlights and promotes quick decision-making, and improve the Developers’ level of knowledge. This meeting is fundamental for Scrum's inspection and adaptation.

Daily meeting agenda

  1. Sit everyone around the sprint board (or task board in use).
  2. Each teammate must provide information regarding these questions:
    1. What did I do yesterday that helped our team meet the sprint goal?
    2. What will I do today to help our team meet the sprint goal?
    3. Do I see any impediments that prevent me or our team from meeting the sprint goal?
  3. Keep everyone focusing on the sprint goal, not on individual tasks.
  4. Pull (or invite team members to do it by themselves) tasks on the sprint board according what each team member reports.
  5. If an unplanned item is reported, then add a Post-it for that so it can be discussed later on during sprint review meeting.
  6. At the end of the session sum up all pending story points and plot a new point on burndown chart.

Sprint review (also called “demo”)

The sprint review, or demo, is one of the most important ceremonies in Scrum. It is desirable to extend invitations to stakeholders and everybody who cares about the project.

It keeps stakeholders up to speed with the progress of product development. It allows them to feedback and discuss with the Product Owner and Scrum team any possible amendments to the Product Backlog which would help to maximize value.

A Sprint Review is held at the end of the Sprint to inspect the increment and adapt the Product Backlog, if needed. During the Sprint Review, the Scrum Team and stakeholders make a review together on what was done in the Sprint. Based on that, and any changes made to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status or formal one, and the presentation of the increment is intended to elicit feedback and foster collaboration

Some effects wanted are:

  • Other people learn what your team is doing.
  • The demo attracts vital feedback from stakeholders.
  • Demos are (or should be) a social event where different teams can interact with each other and discuss their work. This is valuable.
  • Doing a demo forces the team to actually finish stuff and release it (even if it is only to a test environment).

Important

In a multi-team context, everyone involved needs to see the integrated product come together on a regular basis. There will always be integration problems, but the earlier you discover them, the easier they are to be solved. Self-organization only works with transparency and feedback loops, a well-executed sprint review provides both.

Key points for a “good” demo

  • Make sure you clearly present the Sprint goal. If there are people at the demo who don’t know anything about your product, take a few minutes to describe the product.
  • Keep the demo on a business-oriented level. Leave out the technical details. Focus on “what did we do” rather than “how did we do it”.
  • Do not demonstrate a bunch of minor bug fixes and trivial features. Mention them but don’t demo them, since that generally takes too long and detracts focus from the more important stories.

Planning the demo

  • Create a comprehensive list of all the work that your team has completed this sprint.
  • Group related stories together to create a narrative speech about involved stories
  • In some cases it might convenient to have two kind of demos: a “public” one with stakeholders in which we are going to talk in a business-oriented language about the increment, and a second one “private” between dev teams to spread knowledge between them.

Agenda

  • Do we really need an agenda for this meeting? too much pressure on the agenda might end up with a quite structured meeting. Give some room for eventual questions, and comments, they will provide valuable feedback.
  • Remember to be timeboxed
  • Let the people participate and interact
  • Take advantage of the stakeholders presence to talk briefly about what is going to be included in the next release
  • Be aware of possible changes in the product backlog: priority changes, new stories, features not present in current stories that need to be pushed into the product backlog again for re-work.

Retrospective

This is a meeting that can be last from one up to three hours long, for a three weeks sprint duration. Maybe some of the topics we are going to talk about here can be moved out and treated individually in meetings apart, due to the time that they might need to be discussed, honoring time-boxing.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

Agenda:

  1. The Scrum master shows the sprint backlog and, with help from the team, summarizes the sprint. Important events and decisions, etc.
  2. Each person gets a chance to say, without being interrupted
    1. what they thought was good,
    2. what they think could have been better,
    3. and what they would like to do differently next sprint.
  3. Check estimated vs. actual velocity. If there is a big difference, try to analyze why.
  4. By the end of the meeting Scrum master tries to summarize concrete suggestions about what we can be done better on the next sprint. Using a board topics can be arranged like this:
    1. Good: If we could redo the same sprint again, we would do these things in the same way.
    2. Could have done better: If we could redo the same sprint again, we would do these things differently.
    3. Improvements: Concrete ideas about how we could improve in the future.
  5. Each person votes to determine which improvements to focus on during next sprint. Based on this, they selected a set of process improvements to focus on, and will follow this up during next retrospective. It is important not too get overambitious here. Focus on just a few improvements per sprint.

A real board topic for a sprint retrospective looks like this:

Sample retrospective board

Note that in this sample voting was made using three irons by person. Most voted actions should be considered for next sprints.