On June the 8th Scrum.org hosted a webinar on the subject of using Scrum in Biotech research. The webinar was moderated by myself with Tyson Bertmaring Head of Partner Success at Dyno Therapeutics and Matt Abbinanti, Senior Program Manager at CRISPR Therapeutics. The webinar included descriptions by both Matt and Tyson on how and why their organizations are using Scrum. Unfortunately, we did not get to all the questions posed by the audience. In this blog, we try and address some of them. For the purpose of simplicity, we have grouped similar questions.
For context, CRISPR Therapeutics is using Scrum in one part of their organization. Dyno Therapeutics is employing Scrum throughout its research organization. And of course, the opinion provided by both Matt and Tyson are their own opinions are not the opinions of both organizations :-)
How do you map the sometimes very long experiments to Sprints that can only be up to 4 weeks in length (as defined in the Scrum Guide)?
Of course, science takes time and experiments will run longer than the Sprint Length. But asking the question ‘what can we do in these 2 weeks to move towards the goal’ is a valuable question for the team. The other key ingredient of doing Scrum for biotech research is breaking down the work and putting it in the Product Backlog. For example, if you have an experiment that comprises 30 things, but you can only do 10 of them in this Sprint it is important to put the other 20 things into the backlog for future Sprints. This discipline ensures transparency about future work. It also helps ensure that the team is not overwhelmed with a sense of not knowing what may come next. Transparency is a key part of Scrum and having all of this work clear and transparent ensures that the team is always moving forward and also not over committing. It also provides an opportunity to do things differently if problems arise. The team can ALL work together on a solution which might mean other people picking up work, or finding an alternative solution, in a self-organizing way that doesn’t depend on traditional top-down direction.
To work in this way does require discipline. The work has to go into the Product Backlog rather than solely in someone's head. It also ensures that the team spends time understanding the Product Backlog to work out what they can do and if they can help when problems arise. Of course, this level of discipline can be a challenge for people that are always very busy. Scrum does not solve that problem, but it does make it very transparent so that when something is not in the backlog it is very clear to everyone, and we review and improve. One interesting side effect of the use of Scrum is the focus on value-adding work. By making goals, and subsequent work transparent and by putting in space (events) that allow the team to inspect that transparent work a fundamental question can be asked ‘does this work help us move towards our goal?’. It highlights value vs work. Scrum is a great way to get work done, but an even better approach to delivering value.
From our experience the only way to learn how to do this is practice. There are no real rules about when to break down a Product Backlog Item (PBI), or when to roll them up. The one rule is to try and create backlog items that fit within a Sprint. Sprint Planning is the opportunity to break things down and this requires preparation. Of course, items will be added to the backlog that is unknown and fuzzy, but those items should be refined prior to Sprint Planning.
It seems counterintuitive, but shorter Sprints actually help by focusing the team and frequently inspecting the Product Backlog, Product Goal, and the “product” itself. Each Sprint gives your team the opportunity to adjust where it is going so the team focuses on what is most important.
Who is the Product Owner, Developers, and Scrum Master? And when do you decide on who is in or not in the Scrum Team?
Dyno Therapeutics initiated its experiment with Scrum by including its entire R&D organization, multiple teams across the experimental wet lab, and computational data science-oriented teams. Each team has a Product Owner and someone on the team volunteers to serve as a Scrum Master, each team is composed of those who “report” to, or through to, the Product Owner. Each Developer, or team member, is 100% assigned to their corresponding team. You can read more about Dyno’s framework here.
In the case of CRISPR Therapeutics, the Product Owner is the person responsible for the potential therapy. Selecting Developers was also pretty straight forward being the people who are working on ‘developing’ that new therapy. Decisions about who was or wasn’t in the team basically revolved around who was actually actively doing work on delivering the product. Not all developers report to the Product Owner; those that do not continue to report to their functional lead. This ‘double’ reporting can cause issues because ultimately we want everyone within the Scrum Team to focus on delivering the Product Goal rather than doing what a functional manager expects of them. But, by making those conflicts transparent in Sprint Planning these early issues were resolved.
The idea of an Increment is a fundamental idea within Scrum. Does this idea apply to Biotech research programs?
When the team at CRISPR and Dyno Therapeutics first started using Scrum it was before the inclusion of the Product Goal. Product Goal was added to the Scrum Guide in November 2020. Prior to the Product Goal, the idea of an increment was always a bit fuzzy. The Scrum Team was making incremental progress towards their mission, but the nature of the Increment was confusing as it changed shape each Sprint as experiments were kicked off, research gathered, and results found. With the addition of the Product Goal and a clear description of its relationship with the Product Backlog and Increment, it is much clearer. Incremental progress to the Product Goal. We measure progress through the delivery of knowledge through research and experimentation. Each Sprint needs to move towards that Goal or prove it is wrong.
One interesting byproduct of being goal-focused is it allows us to “branch” the solutions. For example, one team may start out assuming that to deliver on a particular goal they would use this technology or approach only to find that the strategy was flawed. This allowed the team to rethink their approach, incrementally. It also allowed both organizations to challenge the very goal itself when an experiment highlighted another avenue to explore.
Maybe many of these things would have happened without using Scrum, but the benefit of a whole team approach coupled with transparency that creates made sure they did happen and on a regular timeframe.
Ultimately both organizations feel that the adoption of Scrum has led to their teams becoming more fulfilled, which then results in better performance and better outcomes. Scrum and even transparency is not the goal for either organization, but delivering more value, solving more problems, and building stronger and more “agile” teams. Scrum provides a mechanism to do this.
Planning is always an interesting topic in Scrum requiring a collaborative highly engaged planning approach. How is planning done when you are working with research teams?
The whole Scrum Team has started to think about their work in two-week chunks or increments. This is called the Sprint. This change has led to everyone breaking work down. It also encourages everyone to be adding items to the Product Backlog in that form. Both organizations do backlog refinement prior to Sprint Planning. This preparation makes for a productive meeting. Of course, items sometimes need to be refined in that session, but the majority of the time is spent getting everyone on the same page. Ensuring that the whole Scrum Team builds a shared understanding of the focus for the Sprint. This is also the opportunity for team members to highlight things that are not in the Product Backlog and talk about capacity. Prior to Sprint Planning, the Product Owner has gathered their thoughts as to what the priority should be, but that priority may change when the other members of the Scrum Team introduce other information. Neither organization used any formal techniques for estimation instead relying on a ‘right sizing’ or ‘what fits in the Sprint’ approach.
When Product Backlog Items are added they do include the how instead of focusing on the outcomes or the why. Then, they are refined into items that can be applied to a Sprint. The objective is to keep everything as simple and usable as possible. By keeping things simple rather than having complex hierarchies, tags, or even templates it is easy to get the Scrum Team to buy into the process.
Like any use of Scrum, building a great Sprint Plan comes from practice. Initially, Scrum Teams put too much in the Sprint not leaving any “wiggle room” for the unexpected, and then put too little in the Sprint which meant they had to go back to the Product Backlog to grab more work during the Sprint. Over time the Scrum Team learned what a good Sprint Plan will look like.
During the Sprint there were a few questions on the Daily Scrum and how does the actual work happen?
The team at CRISPR does not run the Daily Scrum daily because of other commitments and the experience that things do not change enough to require a team meeting each day. By not running the Daily Scrum each day when the Scrum Team does meet it is very focused on inspecting and adapting the plan based on new information. It is all about problem-solving and provides the space for the Scrum Team to restructure the work and help out as necessary. The best Daily Scrum is when someone on the team says ‘ I fear this is about to happen…’ this provides an opportunity for the whole team to jump in and help. Alternatively, teams at Dyno Therapeutics conduct Daily Scrums each day and even have a Product Owner Daily at the end of each day. Meeting daily is imperative in an organization with 10+ scrum teams who collaborate to develop our “products”.
Unlike more traditional product development Done might be a little difficult to define, as is the increment. Do you have an Increment and the Definition of Done?
As mentioned above at CRISPR the idea of an increment evolved over time with the addition of the Product Goal it became easier to define and understand. The Definition of Done (DoD) is similar. Because the increment changes with each Sprint this could mean a different DoD for each Sprint. However, as a professional research organization, CRISPR does have a series of standards. For example, the updating of a scientist’s logbook or how we document our findings or who we communicate to, etc. These things can reside in a DoD, which allows a consistent quality of the work which is delivered. This means that a DoD is not all the steps necessary to deliver an Increment, but instead a baseline of steps that must be added to each Sprint.
At Dyno Therapeutics, each team and each PBI may have different quality criteria that serve as the DoD. Large PBIs may directly translate to one of the Sprint Goals. This has removed the need to have a DoD, however, the question of what is done is an important one that is used to provide transparency.
Do you have technical debt in the same way that Software Development does?
Biotech’s technical debt takes many forms, one of the most critical is documentation. Any experiment, and any benchwork at all, frankly, is expected to be written up in sufficient detail that another scientist in a similar field may duplicate the experiment and match the result. Then another scientist, typically randomly chosen, needs to read through and countersign the experiment. This use of an (often electronic) lab notebook is intended to be contemporaneous, but in reality, the finalization and countersigning can pile up.
Since this debt is mostly “hidden,” there are not a lot of mechanisms in place typically to explicitly make time to either catch up or optimally, keep from falling behind.
To keep from falling behind, one can emphasize completion of the documentation as part of the Definition of Done. Additionally, catching up on other forms of technical debt can be captured as their own tasks in the backlog, which helps the team transparently carve out time and resources.
This type of technical debt is similar to Dyno. Currently, Dyno is experimenting with a single day each Sprint which is meeting free across the organization as a way for teams and individuals to focus and commit to clearing technical debt.