Optimizing Flow of Work Through a Software Development Team
Musings from a Systems Engineering Perspective
--
Co-authored by Ben Edmiston and Robert Wakerly
The perspectives outlined in this article may resonate best with readers who are familiar with the software development lifecycle and who have some experience tracking agile projects. Intended audience may include technical leaders, product managers, Scrum Masters and agile team members.
Factory Line — Introduction
Imagine a factory line, where you have team members with specific roles and functions working in sequence. When there is an even distribution of work, each step of the process is similarly complex, and team members have similar levels of experience and proficiency, work flows smoothly down the factory line.
Great! Now imagine that same factory line, but something has gone awry. For instance, if the “Build” step in the process gets backed up, adjacent team members may pitch in temporarily to work through the backlog until smooth flow is achieved once again. Swarming, anyone?
Factory Line applied to Agile Team Context
Software delivery continues to undergo significant change and advancements as new technology is developed, cloud and DevOps mature, and automation takes root. Even so, we will take a striking industrial revolution perspective (above) and use it to explore, and even optimize modern software development processes!
At Slalom, our Solution Owners (think scrum product owner meets Scrum Master for the consulting workforce) monitor the progress of work continuously. Even when applying agile processes, each piece of work flows through a (mostly) linear cycle.
Pretty clean, right? For those familiar with the development tenets of managing the amount of work in progress, cycle time, and work in each stage, a reasonable distribution of work may look something like this (keeping in mind that your team may not be structured this way, with full time team members in each function):
As anyone who has operated a development team in the wild knows, there are just a few things that can disrupt balance of the system. At the start of the software cycle, teams will identify hypotheses, new scope and new features continually that require careful prioritization, validation, preparation, experience design, and planning that have feedback loops, paths and often in different directions of their own. Active sprint development work may trigger tech debt or new requirements. Acceptance criteria may emerge from reviews. The reality of legacy systems, integrations, programming frameworks or technical barriers can result in design and code iterations and maybe even a revised product experience. In addition, bugs are found and must be triaged, prioritized, and fixed or deferred.
In addition to the aforementioned internal iterations & evolutions (or disruptions from a system perspective), we can’t forget the external factors as well coming from User Acceptance Testing (UAT) or A/B testing from a consumer feedback standpoint, clients, users and other stakeholders requesting new features, iterating on acceptance criteria for new and existing capabilities, and demanding hot fixes or even new urgently needed features — ever heard of a “hot enhancement?”
Disruptions on the system (whoops, I mean, team…) can pile on quickly, bringing the flow of work to a grinding halt as the team experiences blockers, bottlenecks, and distractions from planned goals.
Hopefully your team does not experience all of these at once, but the team development board above reflects a multitude of bottlenecks and issues that can result from disruptions to the team if not addressed.
Knowing how and why such flow problems materialize can take a team to uncover and a diverse set of strategies (drawn from years of experience) to mitigate and resolve. We certainly recognize that many challenges require a combination of people, process and tools. The primary concept we want to explore in this writing is how people can flex to address problems with the flow of work. Secondarily, we’ll consider processes and tools to provide signals about the flow of work before it’s too late!
Flexing
As a team goes about their work, the need to flex may arise to address disruptions, bottlenecks, and issues with flow through the system. Flexing in an agile context is when a team member (or members) temporarily contribute to a role or activity that is not their primary function. Potential benefits of flexing can include:
Potential Benefits:
· Improved team throughput
· Increased team morale with a “we’re all in this together” attitude
· Benefiting achievement of team sprint goal or short-term milestone
Sounds great, right? Well, you likely recognize that flexing can have potential drawbacks, too:
Potential Drawbacks:
· Can persist for too long to the detriment of an individual contributor’s primary function
· Can result in individual burnout if there is a role gap that needs to be filled by addition of a new team member
· Flexing team member may not be best equipped or have the desire to operate in the flex role, which may result in less efficient individual performance and/or low morale
In an agile team context, particular roles may generally be better equipped to flex into certain areas. A sample team may consist of the following profile, where green steps in the process are a particular role’s sweet spot, yellow steps are areas the particular role may feel somewhat equipped to flex into, and red steps are those where the role may be least equipped to flex. When considering flex, you should use caution in having a particular team member flex too far outside their skill area. Of course, this is not a purely formulaic decisioning process. You should always consider an individual’s specific skillset, level of experience, comfort level with ambiguity and new situations, and preference.
How do you know when it’s appropriate to flex? There are a few questions you should answer before making a shift, including:
Questions to Consider:
· Anticipated duration: how long do we expect this flex to last, and when should we have a checkpoint to re-evaluate whether continued flexing is necessary?
· Rationale for flexing: what value can be derived for the team, client, customer, project, program, organization?
· Reoccurrence: do we expect this to be a one-time flex or a repeat need?
· Anticipated breadth: how many team members and roles will be a part of the flex?
· Product outcomes: is the flex directly related to work project/product outcomes? (NOTE: there can be flexing situations that exist outside of immediate work scope, such as internal initiative involvement, special projects, sales pursuits, or professional development and growth opportunities)
Un-Flexing
Throughout this blog post we’ve been considering how to optimize flow of work through a team. We’ve all likely experienced those times when a team has hit that “sweet spot” of producing high-quality output, at a fairly consistent pace, development sprint after sprint. When you hit that “sweet spot,” you might say the team has achieved a state of equilibrium.
Un-flexing is all about moving back to that state of equilibrium. Not only does this balance allow work to flow more smoothly through the team but it can help to sustain higher team morale and minimize burnout.
Consider two examples:
· Team member 1 flexes but is able to return to a balanced workload in a short period of time.
· Team member 2, on the other hand, is over-utilized for an extended duration.
If you find yourself in the second situation, you may need to consider a shift in scope, shift in roles and responsibilities, dropping or potentially reassigning an activity to another team, or adding a new team member to fill the role gap. Regardless of the path taken, the emphasis should be on regaining and then maintaining that state of equilibrium with the team.
Expeditor
Ok, so we’ve thoroughly explored how flexing works. How do you know when to flex and who should identify those needs and make the decision? We’d like to introduce a role to the development team we call the Expeditor. You may have heard of an Expeditor in a manufacturing setting, one who works in restaurant kitchens or in construction. Ultimately, the Expeditor is responsible for synchronizing and facilitating the flow of work to be accomplished in a timely manner, checking status of work for accuracy, and serving as the liaison between the actors on the system.
In a software setting, this role should include monitoring team morale, identifying potential needs to flex and when it’s necessary to do so. Generally, the more complex, the more dependencies, and the more important the work, the more valuable the role of the Expeditor becomes. The Expeditor takes on certain actions including:
Role of the Expeditor:
· Tracking highest priority items continuously
· Looking for opportunities where flexing may be necessary
· Watching for anomalies/bottlenecks in workflow
· Focusing on throughput, allowing rest of team to focus on execution
· Challenging every potential flex opportunity: does the activity align with goals?
The Expeditor is an existing team member on the agile team, often the Solution Owner or Scrum Master. This person could also be a technical lead, developer, or other team member. Larger/scaled teams may have multiple people who act as an Expeditor within their competency such as expediting work within the quality engineering queue or the experience design lead expediting preparedness of designs for the development team.
When the Expeditor tracks flow and opportunities to flex, they need to track indicators from multiple sources. Indicators can come from dashboards and development boards from a software lifecycle management tool (e.g., Jira, Rally, TFS), team members, customer feedback, external parties or departments (compliance, regulatory, security), and more. Some specific indicators to watch for include:
Indicators to watch:
· Swim lanes and completion columns
· Status vs. assignee (i.e. is something “In Dev” inappropriately assigned to Quality Engineering?)
· Planned duration of activity vs. aging of card (could also apply to aging Code Reviews, not just JIRA)
· Burndown on particular work item (not burning down, or taking longer than expected)
· Stale comments, particularly in “blocked” status
· Dashboard that includes some of the above indicators
· Customer feedback (may expose issues with a particular step of the workflow, e.g., quality)
Having an Expeditor (or Expeditors) provides for focused attention on the activities that will influence flow of work through the team, and concurrently frees up mental bandwidth for other team members to focus on their respective areas.
Conclusion
We hope you enjoyed this dive into the minds of a couple Systems Engineers! By proactively leveraging these factory line, flexing, and Expeditor concepts, teams can look for opportunities to address disruptions and workflow blockages before they become an issue. In the end, an adaptive system that dampens noise and disturbances is an effective and beautiful one.
