What are delivery plans?

Completed

As development organizations grow, they need to reorganize into smaller teams that can efficiently manage portioned units of work. These teams usually have their work schedules, boards, and other processes that meet their unique needs within the context of the organization’s larger goals. Over time, organizations might find that they enjoy network benefits by consolidating their processes around a consistent framework.

A delivery plan is a visualization of one or more work schedules. It's intended to provide teams and management an overall view of what each team is planning to produce and when. It allows decisions to be made that optimize the investments across the organization.

Teams must regularly review their delivery plans to ensure that their work schedule aligns with other teams' schedules. These reviews should address questions like:

  • Are we sure we can deliver what we've committed to on our current schedule?
  • Are we confident that the teams we depend on will deliver what we need on their current schedule?
  • Are there lulls in our schedule that we could fill with work?
  • Are there issues with dependencies within a team or across teams?

Delivery plans add value at any point in a project's lifecycle. Because they're dynamically generated based on team backlogs, they're always up-to-date and offer the latest insights.

Let's join the Tailspin web team in their discussion.

Andy: I just had a great meeting with engineering management. I demoed the work we're doing with Azure Boards, and they're excited about the prospect of getting other teams on board.

Mara: Awesome! When will they get started?

Andy: That's the best part. They already have! Last night the game engine project lead created a team with some sprints and began adding work items. I took a quick look this morning, and it's shaping up nicely. Let me show you what they're up to.

Andy navigates to the game engine's current sprint board. He and Mara review the work items with great interest.

Andy: Hmm...I just noticed that they're not planning to deploy their beta by the end of this sprint. Aren't we expecting to integrate our leaderboard with the beta database during our next sprint? We can't do that if they don't ship the beta first.

Mara: That's a good point. We have a dependency on that team to produce that deliverable so that we can produce one of our own.

Andy: This could have really hurt our productivity next sprint. I'm going to give them a call to find out what's going on.

Unfortunately, more sophisticated team structures can result in gaps or lags in communication. When one team is blocked, they might not be able to produce something another team is dependent on. This might not be a major issue for a small group of teams that have daily meetings for all concerned. However, as teams scale in size and location, it can become untenable for everyone to know everything going on everywhere. It's at this point that organizations need to transition from a pure "push" model (like in-person or email announcements) to a "pull" model (where teams can review and track each other's schedules).

Andy: Okay, I just spoke with the dev lead. She told me their team is blocked from shipping the beta until the art team returns from Cliffchella.

Mara: The mountaintop music festival?

Andy: Yeah, apparently, it's a huge deal in the design community, and their entire team just drops off the grid for a whole week to attend. The game engine team is pretty upset because it slipped their schedule by three weeks. Had they known it was coming, they would've made sure to get the artifacts they needed ahead of time. They also apologized for not letting us know sooner. They didn't realize we would be waiting on their beta to ship our part.

Mara: Well, at least we can be glad that the game engine team is publishing their sprint plans. It helped us find this dependency issue early enough to adjust our schedule.

Andy: I just wish there was a way to see these potential risks coming more easily. Our teams have so many dependencies across the company that there's no way we can attend every meeting and subscribe to every distribution group.

Mara: We should create a delivery plan so that we can see our team sprints side-by-side. This will help both teams more easily identify how our schedules affect each other.

Recommendations for managing multiple Agile teams

An Agile approach, along with Azure DevOps can substantially improve project transparency and predictability. However, projects might still run into traditional challenges, often related to personnel or miscommunication. Here are a few things to consider as you scale your Agile efforts.

Build trust in your people and processes

Early detractors of Agile implementations are often skeptical about their ability to improve team performance. It's important for thought leaders within the organization to build trust by illustrating how the tools and processes produce results. Sometimes these results are improvements in productivity, which are easy to quantify. However, don't forget to highlight the team wins that occur by circumventing potential problems, such as avoidable schedule slips or quality issues. As people begin to associate the benefits with the process that achieved them, you'll get more enthusiasm.

Elevate the organization above the team (and individual)

Some teams and individuals get territorial when new processes or policies are proposed. Rather than framing new policies as negatively exposing the performance of specific teams or individuals, highlight how the new transparency across the organization informs everyone of expectations. Having a single place where anyone can trace how their work relates to the organization meeting its goals will drive home the importance of their commitment to the process.

Foster a culture of transparency

Unfortunately, the term "transparency" gets a bad rap. Nobody asks for more transparency when everything is going great. Instead, transparency (or lack thereof) is often blamed when teams are struggling. Even with all of the opportunities for transparency afforded for Agile teams, it's still subject to the honesty of individuals and teams. Emphasize that one of the reasons for transparency is to be able to identify and address potential issues before it's too late. Everyone understands that people sometimes run into circumstances that prevent them from meeting schedule deadlines. But if they don't feel safe in reporting disappointing news until the last possible moment, it can have a much more destructive impact. Building a comfort level with transparency can start with thanking people for reporting expected delays as early as possible.