Yesterday’s Weather & Interrupt Buffer — A Scrum Playbook Increment
Authored by Adrian Neo, Joshua Lai, Aloysius Lim, Celine Tay, Wan Siew Onn, Jitendra Vaxhish, Kenneth Roa & Zhi Lin
Supported by Scrum Mastery Singapore.
What is Yesterday’s Weather & Interrupt Buffer?
Both Yesterday’s Weather & Interrupt Buffer are good practices when Scrum Team is doing Sprint Planning together. The former helps the team to know how much work has been done in previous Sprints and using the data provided, have a visibility of how much work the team can do in the upcoming Sprint.
The latter helps the Scrum team to create buffer as most Scrum Team is serving multiple stakeholders across the organisation and is pressured to meet the needs of many stakeholders. Meantime, completing the work required in the Sprint.
1. Objective / Intent
The goal of Yesterday’s weather is to improve the process to reduce the variance in the team’s velocity by reducing outside interference of the team. Changing priorities or problems in the field (sales and marketing demands, combined with management interference) often interrupt the work of Scrum Teams during a Sprint and can cause chronic dysfunction in a team, repeated failure of Sprints, failure to meet release dates, and even company failure.
Interrupt buffer helps the Scrum team to manage these interruptions. When these Scrum patterns are executed well, the Scrum team can focus on their sprint goal, commit to delivering their sprint backlog and adopt good Scrum core practices (Sutherland et al., 2019). The more accurate it is, the more confident the Scrum team will get, especially when managing priorities and/or expectations from stakeholders, internal or external.
A Scrum team is pressured to meet the needs of many stakeholders in the organisation. These stakeholders can be from Sales, Marketing or any other business units (depending on the organisation’s structure). The Scrum team hence becomes critical in meeting the needs of everyone in the organisation, such as solving problems that can arise during development or product use, having technical discussions and so on and so forth.
The level of availability from each team member helps to determine the amount of work the team can undertake in the upcoming Sprint. There is no point for the Scrum team to take up so much work when some / most of the team members are unavailable during the sprint. Either they are on leave, attending training classes, or have another project(s) / product(s) commitments within the organisation etc. It creates a mismatch of expectations to the people outside the Scrum team when they are looking at the items in the Sprint Backlog. People outside the Scrum Team might think the team is working at a full capacity level and in turn, might add more Product Backlog Items for prioritisation.
Everyone in the organisation has different priorities and in some cases, some priorities might clash with each other. As a result, the Scrum team gets interrupted by such priorities and needs to allocate time for such interruptions. The Scrum team also needs to be mindful when working with stakeholders to identify the priorities. Different strategies could be used for working with individuals that are closed-minded or working with a team(s) who grow up in a strong Asian working culture where employees possess a high Power Distance (PD) as compared to their counterparts working outside of Asia as mentioned in the article written by Ayed, Vanderose & Habra (2017).
2. What are the immediate challenges when introducing Yesterday’s Weather and/or Interrupt Buffer into the Sprint?
Challenge 1 — Unstable Team’s Composition
An unstable team’s composition can affect the interactions within a Scrum team. It takes time for a group of individuals to become a true team — a tightly knit unit with members that trust and support each other and that work together well. A team with stable team members tends to know their capacity, which makes it possible for the business to have some predictability and assist in capacity planning.
For instance, management and/or resource planners in the organisation have the tendency to place people based on the project’s needs. If one of the team members’ skillset is niche and is required for every important project, this team member cannot have the full focus to address the issue identified / discussed. Management, too, can also decide who is the best “resource” (headcount) to be assigned to the team. Such practice can affect the team’s composition.
This team member who possesses this niche skill set will have to “jump” from one project to another. Other team members wouldn’t have the opportunity to learn the ropes from the subject matter expert. Not to mention, if there is any burning question(s)/issue(s), the team will need to wait for their turn to clarify as the subject matter expert needs to attend to question(s) from other teams too.
Team will need to re-synergise and understand each other before being able to communicate and work effectively every time there is change in the team’s composition. Time and effort will be required before it is possible to reliably predict and plan the capacity of the team. An unstable team would result in arduous and unreliable forecasting and planning. In turn, making it impossible for the business to have some predictability in the teams’ forecast. This can be seen in Tuckman’s five stages of team development whereby each stage of team development has its own recognisable feelings and behaviours. Gren, Goldman & Jacobsson (2020) discussed that for a team to be a highly performing team, each team will go through five stages as part of the team’s evaluation and reflection.
In summary, unstable membership poses an added challenge and is often considered a valid explanation for the dysfunction or failure of any group that suffers from it as seen in the article written by Bushe & Chu (2011). Constant changes in team composition makes it very difficult to foster teamwork. Some might say it is impossible.
If team members keep changing every sprint, there is insufficient past data. Each individual also has a different working pace, way of working and et cetera. A good practice of having a meaningful velocity is to have the velocity from the previous 3 to 4 Sprints. This, too, can be a challenge if team members keep changing from Sprint to Sprint.
In an organisation where team members come from a resource pool, these individuals often find themselves multitasking across several teams and often on several projects. Such a working arrangement makes instability unbearable (Sutherland et al., 2019) as team members often caught themselves in context-switching.
Challenge 2 — Low Level of of Trust among Team Members
Team is one of the common words of how Agile delivers value. Cockburn & Highsmith (2001) described a team as a collection of individuals that bring a range of capabilities to fulfill a common goal. Understanding the depth and breadth of capabilities in team members provides the team with the flexibility to dynamically allocate capabilities based on the technical context and business need(s).
Low level of trust among the team can lead to passive communication, or in the worst case, communication breakdown. Team members might exhibit undesirable behaviour such as avoiding close collaboration and/or coordination, with minimal support from fellow team members . Such behaviours might hamper the team to complete the common goal.
One of the twelve Agile principles is to promote continuous face-to-face interaction between team members to foster teamwork and build trust within the team. Agile primarily encourages open communication and emphasises fast feedback within the team. Having fast feedback can help to reduce decision latency while increasing the ability to learn fast, fail fast and time to market at a quicker rate.
Low trust causes lack of transparency and in the worst case, minimum or zero feedback among team members due to people being unwilling to share information and expose their inadequacy. Team, in turn, will not be aware of the individual’s progress and work status. To implement these Scrum patterns successfully, the team should be fully aware of the impediments and challenges faced by every team member and identify ways to address the impediments or challenges.
It would be unwise to expect that people will always be amicable, fair and free from prejudice. We are after all humans. Any team will have their own share of infighting, ego conflicts, side switching, peer pressure, browbeating and et cetera. These are traits and attributes attached to every person. Every individual is distinctly different in his / her thinking.
It is important for everyone on the team to speak their minds without any inhibitions. Open communication allows team members to be more engaged and understand that what they do matters in the success of the business and create accountability for both management and employees. Over time, trust is developed as discussed in the article written by Gail, Zolin & Hartman (2009).
Team’s communication, the richness of their interactions and the quality of team members’ conversation can be affected in the long run. In the short run, dynamics between team members is affected. Examples to illustrate this would be inconsistency and disparities in work practices, reduction and unpredictability in communication. This would result in disagreements among team members and a drop in productivity as supported in the article written by Moe & Smite (2008).
Challenge 3 — Interference from Management
Different teams have different velocities especially when one team consists of seasoned developers who have in-depth domain knowledge as compared to another team which comprises developers who might not possess as much in-depth knowledge as the previous team. Introducing patterns to both teams might open a discussion among stakeholders and/or management why both teams are not having the same velocity and/or burndown. The mindset of stakeholders and/or management is that both teams are developers and possess the same skill-sets.
In return, management might disagree and start to interfere and in some cases, challenge the team as Nerur, Mahapatra & Mangalaraj (2005) mentioned in their article.
Furthermore, the work the teams are working on could have different scopes, levels of difficulties and complexities. These traits help to strengthen the notion that different teams can have different velocity.
Management might also perceive the teams being too conservative in their velocity forecast and lack of commitment to attain what the common goal is. Management could ignore the teams’ estimation and interfere by forcing their “appropriate” estimation to the team within a stipulated timeline.
Other examples to illustrate this would be (a): management will question and challenge the teams when multiple Scrum teams are using relative estimation in a project (product) delivery and, (b): the challenge of moving from man hours to Story Points as management are used to measuring progress by man hours.
Management might have the misconception that the less productive team is working slower than the other team that is completing the items in the Sprint Backlog at a faster rate. In the long run, the management’s trust and expectation might start to decrease. Management interference could burden the team unnecessarily with additional team performance metrics and management reporting, thus disrupting the flow of teamwork.
Interference from management can include the management adding more items into the backlog for the less productive team or hiring people from the management track into the less “productive” team to do a root cause analysis. Such behaviours create more distrust between management and the delivery team. Constant interference from management may bring down the team’s happiness and team collaboration. Scrum Team might see interference from management as the management being not appreciative, resulting in an increase of staff attrition rate.
3. Recommendations to kick-start Yesterday’s Weather and/or Interrupt Buffer into the Sprint
4. Self-Assessment Checklist
This self-assessment intends to help you with/without your team reflect honestly on your team’s application of Yesterday’s Weather & Interrupt Buffer. Based on your experience with your team, go through the statements below and tick the response that best represents what you feel about the statement. It is best to take this self-assessment before and after the application of Yesterday’s Weather & Interrupt Buffer for some time. Compare the before and after self-assessment checklists so that you may identify opportunities for growth and plan for improvement and approaches that lie ahead. You could conduct these self-assessments from time to time, which could assist you in your continuous improvement.
5. Authors’ Experience when applying Yesterday’s Weather and/or Interrupt Buffer
My product owners have a tendency to push for more stories into the sprint backlog during sprint planning. My developers managed this situation with Yesterday’s weather. They usually reflect on their past 2–3 sprints’ velocity to forecast their capacity and negotiate with the product owner on the amount of the stories to be committed. Yesterday’s Weather is a data driven approach, heightens transparency and enables healthy conversation between the developers and product owner that keeps the team happy and protected. It keeps the developers’ morale high with a sustainable pace. — Joshua Lai.
Yesterday’s weather addressed the uncertainty from both Product Owner & Developer. PO will be able to predict when the product features are going to launch and therefore be able to plan out the subsequent launching marketing activities accordingly. Developers have a better visibility of product feature goals and will not need to face “when is my features going to be delivered” questions daily. I had frequently applied an Interrupt Buffer to address the situation where resources need to handle more than a role. For example, urgent business as usual tasks can be addressed while a resource is delivering sprint items. These 2 patterns are essential & useful as it’s rare for an organization to have full time resources on one single task / role. — Celine Tay
There is a tendency among management and Product Owner to push (stuff) more stories into the Sprint Backlog for Scrum Team. The Scrum Team can show the velocity the team completed from previous Sprints and invite everyone for a discussion and start to prioritise on what is important for the team to work on and can wait for the following Sprints for those works that are less critical and have less impact. Yesterday’s Weather is a good tool to allow the Scrum Team to be transparent when the team is doing Sprint Planning. There is a saying in the IT industry — “ Data don’t lie.”. Yesterday’s Weather is a data-driven approach and place the facts on the table. —Adrian Neo
References:
Ayed, H., Vanderose, B., & Habra, N. 2017. Agile Cultural Challenges in Europe and Asia: Insights from Practitioners; IEEE/ACM 39th International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP), 153–162, doi: 10.1109/ICSE-SEIP.2017.33.
Bogue, R., 2011. Book Review — Trust & Betrayal in the Workplace Retrieved 25 May, 2021, from https://thorprojects.com/blog/archive/2011/08/13/book-review-trust-betrayal-in-the-workplace/
Bushe, G.R., & Chu, A. 2011. Fluid teams: Solutions to the problems of unstable team membership. Organizational Dynamics, 40.
Cockburn, A., & Highsmith, J., 2001. “Agile software development, the people factor”, Computer, 34 (11) doi: 10.1109/2.963450.
Gren, L., Goldman, A., & Jacobsson, C. 2020. Agile ways of working: A team maturity perspective. J Softw Evol Proc.; 32:e2244. doi: 10.1002/smr.2244.
Gail, T. F., Zolin, R., & Hartman, J. L. 2009. The Central Role of Communication in Developing Trust and Its Effect On Employee Involvement. The Journal of Business Communication (1973), 46(3), 287–310. doi:10.1177/0021943609333522
MindTools, Building Trust Inside Your Team. Retrieved 25 May, 2021, from https://www.mindtools.com/pages/article/building-trust-team.htm
Moe, N. B., & S, D., 2008. “Understanding a lack of trust in Global Software Teams: a multiple-case study”, Software Process: Improvement and Practice, 13 (3) doi: 10.1002/spip.378
Nerur, S., Mahapatra, R., & Mangalaraj. G. 2005. “Challenges of migrating to agile methodologies”, Communication of the ACM, 48 (5): doi: 10.1145/1060710.1060712
Su, A, J., Harvard Business Review. 2019. Do You Really Trust Your Team? (And Do They Trust you?). Retrieved 25 May, 2021, from https://hbr.org/2019/12/do-you-really-trust-your-team-and-do-they-trust-you
Sutherland, J., Coplien, J., Heasman, L., Den Hollander, M., Ramos, C., & The Scrum Patterns Group (2019). Illegitimus Non Interruptus. Retrieved May 15, 2021, from http://scrumbook.org.datasenter.no/product-organization-pattern-language/illegitimus-non-interruptus.html
Sutherland, J., Coplien, J., Heasman, L., Den Hollander, M., Ramos, C., & The Scrum Patterns Group (2019). Stable Team. Retrieved May 15, 2021, from http://scrumbook.org/product-organization-pattern-language/development-team/stable-teams.html
Sutherland, J., Coplien, J., Heasman, L., Den Hollander, M., Ramos, C., & The Scrum Patterns Group (2019). Yesterday’s Weather. Retrieved May 15, 2021, from http://scrumbook.org.datasenter.no/value-stream/estimation-points/yesterday-s-weather.html
Acknowledgement
Special thanks to all Scrum team members (Adrian Neo as Product Owner, Celine Tay as Scrum Master, and Joshua Lai, Aloysius Lim, Wan Siew On, Ngoh Zhi Ling, Kenneth Roa and Jitendra Vaxhish as Developers) who delivered this wonderful playbook increment “Yesterday’s Weather & Interrupt Buffer” within two months’ time.
Kudos to the Scrum Mastery community members who contributed actively in the content brainstorming workshop.
