The Scrum Pillars at Sophilabs: Adaptation

Agile software development prioritizes the ability to change quickly in response to stakeholder feedback and a dynamic business landscape. This concept is influenced by Lean manufacturing and the Toyota Production System, a people-centric approach that encourages teams to learn from the obstacles they face and then use this information to improve the way they work. The third pillar of Scrum, adaptation, is all about this readiness to respond to change. It's an idea that works hand-in-hand with our company-wide culture of continuous improvement. In our final installment of our Scrum Pillars series, we'll take a look at how adaptation happens in Scrum and how our teams stay adaptive throughout every sprint.

The Scrum Master

The Scrum Master is the team's Scrum expert and a key figure in helping the team adapt. They are a servant-leader who uses empirical knowledge to coach teams to self-organize more effectively. They help the team get the most value out of Scrum and adapt to challenges in ways that enable them to work better together and bring everyone closer to achieving the sprint goals. While the team usually makes decisions collectively, the Scrum Master can advise them on what would most likely yield the maximum value.

The Sprint Backlog

This artifact is made up of user stories and tasks pulled from the product backlog, usually the most refined items from the top of the list. The sprint backlog can change up until the sprint planning session, but further changes in scope should be avoided as much as possible once the sprint starts.

The sprint backlog is all about establishing the what, allowing the team to determine the how. A high-level sprint goal defines what goes into the sprint backlog, and the items themselves should represent business goals rather than technical tasks. This leaves room for the development team to decide how they are going to approach the work and adapt the way they organize themselves throughout the sprint.

Adaptation in Scrum Ceremonies

According to the Scrum Guide, "each event in Scrum is a formal opportunity to inspect and adapt something." ¹ At sophilabs, we strive to take advantage of these events to make changes that will help us work better. Let's take a look at how adaptation occurs in some of the Scrum ceremonies.

Daily Scrum

As we mentioned in our previous posts, the daily scrum is perhaps the most important instance of inspection and adaptation that happens in Scrum. And the most critical part of this ceremony is addressing the impediments and blockers that are holding the team back from reaching the sprint goals. The daily scrum is a very powerful way for the team to not only identify what's not working, but to also begin to shift their approach to make things work better. The Scrum Guide stresses that the daily scrum should "highlight and promote quick decision-making" – that is, the team should use this ceremony as an opportunity to continuously adapt throughout the sprint. ²

Sprint Review

This ceremony is another key instance that allows the team to adapt, as it enables the team to collect stakeholder feedback and know whether what they are doing is valuable. As we discussed in our post on transparency in Scrum, at sophilabs we tend to adjust the dynamics of our sprint reviews based on customer preference. Sometimes our development team leads the review, presenting the new increment and asking for customer input. In other instances, the customer takes the lead, trying out the new piece of working software and giving feedback. In either case, the sprint review is a chance to not only receive feedback on our work, but to also look at changes in the market or in the product's potential use and adapt the path forward accordingly. This often includes adjusting the Product Backlog to reflect how the team will apply what they learned from customer feedback. ³

Sprint Retrospective

As we discussed in detail in our post about inspection, the sprint retrospective is an opportunity for the team to examine how they work together and come up with an action plan to improve communication, collaboration, and efficiency during the next sprint. To get the most out of our retros, our team tends to follow a five-part structure: staging the retro, gathering data, fostering insights, making decisions & mapping future actions, and closing the retro.

The fourth stage – making decisions & mapping future actions – is where the concept of adaptation is most relevant. The goals of this phase are to reach a consensus, define a plan, and come up with doable action items for each team member for the following sprint. One technique we might use is SMART goals (SMART stands for specific, measureable, attainable, relevant, timely). After composing goals according to the SMART guidelines, the team defines the concrete steps they would need to take to achieve these goals.

Another technique asks team members to come up with behaviors or practices they want the team to start, stop, or continue and collect the ideas on a whiteboard or flipchart. After narrowing down the options with a brief discussion, the team votes on the initiatives. To add a bit more nuance to the voting process, each person can give their top three favorite initiatives either one, two, or three dots or X's. The two ideas with the most dots or X's written next to them become the team's action items for the following sprint.

Exercises like Low Hanging Fruit challenge the team to consider what changes would be the most beneficial versus how difficult they would be to implement. A Landscape Diagram requires the team to map ideas on a chart where the x-axis represents certainty about approach and the y-axis represents agreement on issue. The team then uses this visual to decide on actions to take in the short versus long term. ⁴ Whatever the lower-level practices we use, at sophilabs we always make sure there is some kind of voting involved so that everyone has a voice in establishing the plan of action.

Adaptation doesn't happen just because we came up with a great plan during a retrospective, though. Truly practicing this essential part of Scrum means that we need to actually implement incremental changes according to what creates the most value for the team, and we need to hold each other accountable throughout the process.

An Agile approach to software development encourages continual reflection, learning, and growth. We love working with Scrum because it's a great framework to facilitate these things while leaving room for specific techniques and practices that work best for different teams. Scrum is most effective when teams prioritize the fundamental concepts of transparency, inspection, and adaptation, rather than go through the motions without considering the underlying value of the framework. We hope our Scrum Pillars series gave you a good idea of how we work at sophilabs. If you want to find out more, take a minute to read our Playbook!