Applying Little’s Law to Improve Predictability & Flow in Agile Teams
By: Bret Patton
While the industry is changing at a rapid pace, so are our consumers’ wants and needs. We recognized quite quickly that in order to keep up with the demand, we needed to pivot and change the way we operate internally. In other words, we needed to become more agile in order to produce more. As the saying goes, “Change is good.” For us at FOX Tech, that couldn’t be more true. Our change was accompanied by more autonomy, more ownership and more professional development opportunities for each and every employee all while continuing to love what we do and how we do it. So, how did we do it? We took our Agile mindset to the next level.
Previously our team used the Scrum Framework at the delivery team level. The delivery team is an individual team who develops, tests, and delivers the work. Scrum is designed to help teams bring value to their customers by often inspecting complex work through time-boxed iterations. Scrum has worked well for this organization across numerous teams, but at an enterprise level, FOX Tech knew to effectively handle dependencies, continue to deliver value, and maintain growth, they needed an efficient way to scale. In the Fall of 2021, we adopted the Scaled Agile Framework (SAFe).
SAFe has been around since 2011 and has proven to scale, be configurable, and promote business agility at all levels and sizes of an organization. The FOX Tech organization has just under 50 development teams and are dependent on work within each other. With SAFe, teams can check in with Scrum Masters and Release Train Engineers (RTE’s) often to showcase potential blockers and dependencies. SAFe is based on ten Lean-Agile principles. While all the principles add value, Principle #6 is one of the most valuable. Let me tell you why.
SAFe: Principle #6 — Visualize and Limit WIP, Reduce Batch Sizes & Manage Queue Lengths
The primary reason this principle is so important is because it helps the team focus on delivering value to the customers. Customer satisfaction is the truest measure of success. When team members can focus on delivering in small increments and batch size, they limit context switching. Context Switching is a software developer’s worst enemy. It is when they switch from one unrelated task to another. The reason this is so detrimental is because it takes over 23 minutes to refocus on the original task, according to mindtools.com. If somebody switches from a task 3 times a day, they’ve wasted an hour simply to just refocus. While there isn’t a perfect solution for all teams, some of the best ways to prevent team members from being distracted include:
- Hold regular scheduled meetings at the same times, instead of having them be sporadic throughout the day/week.
- Only invite members to “one off” meetings who truly need to be there.
- Have defined agendas for all meetings.
- Allow development team members to set calendar blocks for focus time. And don’t interrupt except with agreed upon rules such as a serious production outage.
- Communicate efficiently and ensure the delivery team is being honest about impediments, interruptions, or anything preventing them from completing their work towards the sprint goals.
While the contents of this principle are not specific or limited to the Scaled Agile Framework, SAFe does a great job explaining it in this write up here.
Why Principle #6 works: Little’s Law
The short answer to why this works is because of Little’s Law. Little’s Law can be complicated to understand, but fundamentally “the more things that you work on at any given time (on average) the longer it is going to take for each of those things to finish (on average).” So instead of trying to do too many things at once, teams should limit Work in Progress (WIP) to improve and maintain flow. It helps the team visualize the work, improve collaboration, and focus on the sprint goals. For an entire write up, read the scrum article here.
WIP is an agreed upon limit of stories the development team sets in their Scrum Board. Teams can customize the boards however they like, but a common board would have columns such as, “To Do”, “In-Progress”, and “Done”. If a team chooses to have a limit of three stories “In- Progress”, then they shouldn’t be pulling in new stories until they mark something “Done” from the “In-Progress” column. Teams usually have an agreed upon Definition of Done (DoD). We won’t get into details, but this is the teams’ agreed upon requirements for a story to be completed and accepted. The DoD would need to be met to move a story to the “Done” column in the Scrum Board.
Here is a generic illustration of the example provided above. The team has a WIP limit of three, so they wouldn’t pull anything from “To Do” until something is marked “Done” from “In-Progress”. Figure 3 shows three stories “In Progress”, but only one story done. Once we move another story “Done”, another story can be moved to “In Progress” as Figure 4 shows.
Principle #6 will also call to reduce the batch size and manage queue lengths. To put it simply, smaller batches will go through the system quicker. This is a common Agile practice and essentially stories should be sliced to the minimum amount of work that delivers value to the end user. Managing queue lengths goes back to Little’s Law, where teams should focus on less items committed at a time, so the wait time of completion happens sooner. This can get very complicated, and you can read more about it in the original SAFe article linked above.
What is Flow?
Nobody explains this better than Henrik Kniberg in the video, “The Resource Utilization Trap”. This short video demonstrates misconceptions from a leadership viewpoint that team members need to be 100% busy at all points to deliver value. In fact, it displays the opposite. Flow time is the amount of time it takes to deliver one piece of value to completion. When resource utilization is maxed out, the flow time is less, because members are spread too thin. Therefore a “Pull” system works more effectively over a “Push” system. The team pulls in new work when they are ready. The amount of work delivered in the time box is the throughput. The Lean approach is to focus on flow over resource utilization.
How to Measure & Analyze Flow?
In the book Mastering Professional Scrum, Stephanie Ockerman says, “The key to improving a team’s process is to create transparency into what is actually happening in the process. Objective data can help identify potential patterns that may be missed, and these techniques can help bring transparency to flow within a team’s process.” The metrics below are not intended to track a team’s performance. They are simply intended to help a team be transparent, locate bottlenecks, and see trends to help a team measure ways for continuous improvement. Metrics are not a requirement, and a team may choose which ones work for them.
- Cycle Time: The time from when a story is started to when it’s marked as done. When stories are in progress for a long period of time, teams can also look for bottlenecks that are preventing them from completing work. A bottleneck may not be a blocker from outside the team, but could be something needed for upskilling, pair programming, leave of absence as well.
- Sprint Burndown: For teams to know when stories are getting completed.
- Track WIP: Stories that have started but not finished and are displayed as stories that don’t add value yet. Only completed work will add value.
- Track Blockers: Stories that are blocked when they cannot move forward due to unforeseen circumstances. Teams should track the amount of time it takes for blockers to be removed.
The point of capturing all this data is to locate trends that can help the team improve their processes.
Summary
No team is created equally, so one team will work differently than another team. For a team to get more work done, there are few things they need to keep in mind. Focus on:
- Doing fewer things at the same time
- Priority overall and swarm if possible
- Transparency into how the team is working and how to improve it
- Understand their throughput and WIP limits
- Remind leadership that adding manpower isn’t a solution to speed things up, as stated in Brook’s Law
At the end of the day, with the help of SAFe and using Agile, Lean, and Scrum principles, all teams can be successful and manage dependencies. Is your team up for the challenge?
About FOX Tech
Make Your Mark Here.
At FOX, we pride ourselves in shaking things up and making things happen. We’re a community of builders, operators and innovators and each and every day we experiment, collaborate, and co-create to develop the next world of news, sports & entertainment streaming technology.
While being one of the most well-known brands in the world, we provide our employees with the culture of a start-up — fast paced, non-hierarchical, full of smart ideas & innovation and most importantly, the knowledge that each member of the team is making a difference in defining what’s next for FOX Tech. Simply put, we love to do great work, with great people.
Learn more and join our team: https://tech.fox.com
