The Teams, They Are a Changin’

Business people and developers must work together daily throughout the project.—Agile Manifesto

My team has experienced a lot of change in the past few weeks. We were a team of seven, and now we’ve been reduced to two. We’re off-boarding two developers, a content specialist, and the product owner, and we’re onboarding a new content specialist and another developer. This is a lot of change to absorb at once.

It has caused disruption, added friction to our delivery schedule, and caused some frustration amongst team members. Agile practices are designed to optimize for change; however, the focus of agile practice is primarily around external change:

Welcome changing requirements, even late in development.

Agile processes harness change for the customer’s competitive advantage.—Agile Manifesto

To truly harness the power of agile practices, you need a stable team. But people leave under normal circumstances for a variety of reasons: maternity, new jobs, retirement, etc. While recognizing the need for stable teams, there are things our team does and should do to be resilient in the face of change.

The costs and challenges of team changes

Any time a team member leaves or a new one comes on board, there’s a cost associated with redirecting focus to account for that change. This adds friction to projects that is not just technical:

• Off-boarding any existing team members
• Getting new members up to speed on codebase, product vision, issue backlog, and any research
• Integrating the new team member and learning how to work with them

All of these translate into dollar costs, and if your project is running on a tight budget, these costs will affect planning and delivery. Further, having to manage these costs on a frequent basis can lead to fatigue, and lower team morale.

Agile optimizes for change_—_to a point

Being agile means that you inherently optimize for change. Our primary tool for responding to change is agile communication practices. My team does this in a number of ways:

• A design studio to go over user research, and together come up with ideas and priorities going forward
• Bi-weekly meetings to groom our backlog and plan each iteration
• Regular retrospectives to make sure we’re addressing any process issues that come up

All of these activities create a shared understanding of what we’re working on and why, and how we go about it. This keeps the team aligned and makes it much easier to onboard new members.

We want to always ask ourselves “How would I explain what we’re doing to someone who is new?”, and our daily work produces artifacts that communicate the status of the project and the history of our decisions.

• Our user stories represent work that needs to be done, but they can also serve as an easy historical record of our work.
• We use automated tests to ensure that any accepted code modification passes the tests. The tests are integral to our daily work so these documents are always kept up to date.
• We use vignettes as a way to express the use cases driving our work. Anyone can read them and quickly get a sense of what we are trying to accomplish.
• Our story map and project wikis contain summaries of the goals, hypotheses, risks and milestones.

Lastly, we try to stay positive in the face of change. Becoming frustrated unnecessarily takes the focus off of our work, and blocks us from coping with the change itself. Accepting that some change is inevitable helps us stay positive and actively optimize our processes to cope with it, and helps us stay focused on delivery.

In teams without shared understanding and documentation, huge changes can be devastating. But, agile practices mitigate against this risk; and the work my team has done should help the new team members get up to speed much more quickly than they would otherwise.

Get your team ready for change

Agile practices are centered around optimizing for change, because the world changes. Though stable teams are the goal, teams will change, sometimes quite frequently. Your team can take steps to account for the disruption caused by change:

• Better documentation → better tests → more stable code
• Frequent communication → shared understanding → building the right thing
• Staying positive → focus stays on delivery → consistent velocity

Agile techniques can help your team deal with change, but only up to a point. Stable teams, stable code, and delivering the right thing with consistent velocity is the goal. Teams should do what they can to minimize team changes, while also working to minimize the negative impact of change, because team happiness and productivity go hand in hand.This post was originally published on the 18F blog by Michael Torres, 18F team member.