Agile as a Communication Framework

As software development teams are taught and onboarded into an Agile environment (and for the purpose of this discussion, Scrum), the educational materials and trainings tend to focus primarily on the ceremonies and the output/agenda of those ceremonies. Yet, for many teams, their burndown chart continues to plateau (or worse, 📈) and the team struggles sprint after sprint to meet their goals and commitments. Estimates were wrong, fires needed to be extinguished, a team member took a sick day, or there were just too many meetings. The likely culprit? The process simply must not be working.

Right?

At the heart of this problem is the foundational assumption that our processes are how we build software. If our software is not being built effectively, then the process must be to blame.

We need to reframe the narrative. Our software development processes should be a model for communication. Instead of focusing on the output of the ceremonies, Grooming, Sprint Planning, Stand-ups, Demos, and Retrospectives, we should teach and demonstrate the types of conversations that could be happening in them. If we shift the focus away from allowing or assuming that the process will manage our work, we can foster better communication within the team. This allows the team to re-adhere to Agile's base philosophy of "People over Process."

Grooming

A key tenet of Agile is continually “grooming” the backlog. The cross-functional members of the team (designers, engineers, testers, product managers, or others), dedicate this meeting time to break down their upcoming work into small, meaningful, hopefully releasable chunks of work. The specific mechanics for breaking down the work is unique to different teams and organizations. The core of this meeting is an opportunity to communicate within the team about what success looks like for every piece of work that could be scheduled in an upcoming sprint. Each team member is expected to contribute their perspectives on what needs to be done.

The grooming meeting offers team members an opportunity to learn about each other: their roles, their approaches, and their personalities. Each groomable item will likely require the specialized skill-sets of multiple members of the team, and the Grooming meeting is the forum to break the work down into individually actionable pieces across the team. Through this discussion and debate, the Acceptance Criteria is defined (and refined), and the team will start to build their collective intelligence about what “done” means. These discussions are crucial. Individuals on the team will begin to learn about the working styles of each team member and how these styles can complement each other. The members of the team can challenge each other’s approaches and assumptions, and the different functions of the team will learn to trust and advocate for each other.

Sprint Planning

At the beginning of a sprint, the team members have an opportunity to discuss what they are going to commit to finishing over a fixed period of time. That fixed period of time can be defined differently from organization to organization, but generally speaking, it comes down to finding the balance between frequency and length. The sprints should be long enough so the team is able to accomplish something meaningful (however the organization chooses to define this), balanced by the sprints being short enough for the team to conceptualize and strategize all of the intra-team dependencies and coordination required to complete their work. The sprint transitions should be infrequent enough where these planning exercises do not introduce a disproportionate amount of overhead to the team, but frequent enough that the team is able to have meaningful retrospectives and regular checkpoints to evaluate product and team direction. Many teams choose two weeks as the length of the sprint that works best for them, but this is up to the discretion of the team and organization.

As the team is planning their sprint, the discussion should center around what gets brought into the sprint (from the previously groomed work) and how the team can best execute against that. This is the first opportunity for the team to discuss tactics together: who is going to work on what pieces and when? A good place to start is by referencing the team’s velocity: a running average of how much work the team has completed over the course of the past sprints (the sum of all groomed and sized tasks). This will serve as a good guidepost for how much work the team should discuss, but it falls short of being able to accurately predict what and how much work can actually get done.

To figure out exactly what work they should commit to finishing, team members should discuss their particular contributions to the tasks and how that work moves through the team. For example: a designer may have a day of work ahead of them to deliver a spec to the engineer who may have three days of work before planning to hand off to the tester. The team should go through this exercise for everything they identify to accomplish during the sprint.

Serialization introduces risk.

In the previous example, for simplicity’s sake, each individual’s work is explained very serially: design must be done before engineering which must be done before it gets tested. However, this type of serialization introduces risk, as anyone who has ever put together a gantt chart will know: one slip of a deadline upstream will have cascading effects on everything downstream of it. While serialization and dependencies are a necessity in software development (you can’t fully test something that isn’t built, after all), they can and should be minimized through conversation, debate, and deliberate planning. Through a combination of Grooming and Sprint Planning, the team can identify the parts of the work that can be done concurrently and enable its members to optimize efficiency and remain unblocked over the duration of the sprint. Going back to the previous example, the engineer may be able to identify some parts to build that are not dependent on what the designer comes up with, and the tester may be able to plan their test cases and automation prior to the code being written.

One exercise the team members can do during Sprint Planning to find these opportunities is to diagnose how “lumpy” the sprint is. This is a person-by-person assessment of how busy they are going to be over the duration of the sprint. Does it look like anyone will be overloaded or underloaded at any time? If so, what can be shifted around, what other work can be pulled in, how can the team optimize for a more evenly-distributed workload, and what can be done to prevent the downtime waiting for another team member?

Stand-Ups

A properly-run sprint planning session will result in a shared understanding of how (ideally) the sprint is going to run and will establish commitments between people. It will establish a system of accountability: the team members should be holding each other accountable to their commitments on a daily basis. With the team optimizing for maximum efficiency for the duration of the sprint, it is crucial that team members are proactively communicating with each other about their progress. Stand-ups are a great opportunity for this, but this communication can (and should) take place anytime during the sprint.

“The best laid plans of mice and men often go awry” - John Steinbeck

While Sprint Planning gives the team a detailed plan of how the sprint could go, it is naive at best, to assume that the team will be able to execute on that plan without experiencing outside intervention, distraction, or surprises. This is why the daily stand-ups are a great opportunity for the team to meet, discuss, and re-strategize based on new information. Whether the team has discovered something is wildly simpler or more complicated than they anticipated, a team member is unexpectedly absent, or business priorities have changed, the team members have an opportunity to engage the collective problem-solving capabilities of the group. How can the team adapt to these changes to stay on track with the commitments made when they planned the sprint? Is it possible for tasks to be taken on in a different order? Perhaps members of the team can pitch in to help each other with work (such as design or testing)? Stand-ups are an ongoing opportunity to try to help the team stay on track.

Day-to-day, it is imperative that the team structures their updates in stand-ups in a way that instills a sense of accountability. Rather than following the all-too-familiar format of “I am working on {project/task},” or the “yesterday, today, tomorrow” formula, the individuals should deliver their updates using this format:

I am working on {project/task} and I will deliver it to {person/team/user} on {date/time}

This method of communication establishes a commitment between team members. It also provides the team with a great deal of data that they can use to monitor progress and track changes to the schedule.

External Communication

While not a ceremony, communicating beyond the team is a critical ongoing responsibility of the team. Sprints give teams two or three predictable times when stakeholders and dependent teams can expect updates. The first is Sprint Planning: the team should communicate what the team expects to accomplish in the sprint as soon as the team commits to it. This sets the stage with stakeholders and other teams about what/when things will be delivered or needed. Another prime opportunity for communication is when the sprint ends (or the demo); the team can close the loop with stakeholders about what was delivered and the commitments that were met. Mid-sprint updates are also valuable, as they can help keep those outside the team in the loop.

The team must acknowledge that changes happen on a daily basis and should be prepared to react and adapt to them, rather than bemoan their effects on the planned work. Team members are faced with decisions constantly, and despite their attempts to adjust to maintain their commitments, the team may need to reset expectations with their stakeholders. By waiting for the next scheduled check-in (such as mid-sprint or end-of-sprint), the teams are missing a valuable opportunity to engage their stakeholders in the problem-solving process. Perhaps there is another option that an additional perspective can unearth, or perhaps there are unforeseen consequences due to the proposed decision? The team should communicate changes beyond their teams as proactively and timely as possible.

Demo and Retrospective

The demo serves many purposes: a celebration of what was accomplished, an opportunity to discuss the work in the context of the larger team’s goals, a mechanism for sharing progress with outside stakeholders, and a chance to think about what’s next. The demo lends itself incredibly well to this central thesis around communication, as this is a great chance to connect the promise of work with the actual deliverable. An effective demo can serve both as a status report and a catalyst for creativity and ideation within and outside of the team.

What follows the demo is potentially the most important opportunity to communicate: the retrospective. The team should focus this conversation on two things: outcomes and efficiency.

At the end of each sprint, the scrum teams should revisit and discuss their long-term goals and how they are defining and monitoring success. The team should identify and openly discuss what Key Performance Indicators (KPIs) are important to the team and the projects they are undertaking. Regularly revisiting these KPIs articulates the imperative for the team to be prioritizing their energy on work that helps the team “move the needle,” and sets the context for how the next sprint will be planned -- specifically what work should be tackled next. It is important for the team to talk about how their most recent work will affect these KPIs, but it is also an opportunity to discuss how previous changes continue to make an impact.

Many teams focus their retrospectives on discussing why certain items didn’t get completed. Framing the conversation this way lends itself to simple rationalization unless time-consuming practices like “5 Whys” are employed. Instead, the team should focus their attention back to their original goal: maximum efficiency. The team is at peak efficiency when the right people are working on the right things at the right time with no one overloaded or underloaded at any point. This is an ideal anchor for the retrospective conversation. The team was empowered and expected to make game-time decisions throughout the sprint that would reshuffle and reoptimize their workload based on changing information. As the team revisits all of those decisions through the clarity of hindsight, could different decisions have made the team be more efficient? The answer: almost certainly yes. The team can discuss, debate, and feed those lessons back into their decision-making framework for the next sprint planning and grooming sessions.

Mechanics

I intentionally omitted the more mechanical aspects of the scrum team management from this discussion. Things like how the team sizes their work, how they can visualize the work in progress on a board, the Definition of “Done,” or whether or not the demo should include non-customer-facing work, are parts of the sprint process that are necessary conversations to have, but these do not replace or negate any of the important conversations that need to happen within the teams. Ultimately, if the team can master these communication principles, the team will be able to migrate to any number of other software development methodologies; these communication best-practices are absolutely transferable beyond Scrum.

---

The root cause of the frustrations that many teams experience adopting Agile or Scrum is that they embrace the ceremonies, rather than the communication framework that it offers. If teams focus first on the types of conversations available to them, they will more effectively (and efficiently) be able to operate as a team, execute on a shared plan, hold each other accountable on a daily basis, and feed the lessons back into the system.