Agile Planning & Delivery: Five Common Mistakes and How to Fix Them

Let me start with a story about a company I’ll call Acme (not its real name). Acme is a large public company that has been around for more than 20 years. They have a commanding presence in a unique product space, complex codebase, successful history of revenues and lots of customers. But, in recent years they have tried to execute very large technical deliveries and found themselves blocked for a variety of reasons. What started as a frustration turned into a crisis. Customers were getting cranky, shareholders were growing impatient and leaders could feel the pressure of disruptive competitors. They knew they needed a change and decided to “go agile”.

If you think you know this company, you might be surprised. Because this describes almost all of my large clients over the past five years. Unfortunately, it’s a pattern. It’s usually not unique or a by-product of incompetence or irresponsibility. It could be because of scale, speed, or a thousand little choices made in isolation that ultimately clash when put together.

To help, we embarked on an agile transformation using my playbook. First, we rearranged everyone into small, persistent, cross functional scrum teams. Then everyone was trained in scrum, with a narrative created to focus on solving recognizable issues. Team members seemed bought in and eager to try something new. All projects were converted into prioritized product backlogs. Teams did bottom up planning for the quarter allowing them to understand what was expected, to align and to create their own estimates. With new hope and excitement, these teams started to execute on the plans. All should have been good in agile-land….but it wasn’t.

Once we got into the execution, we realized that their plans were off. In some cases, by a lot. Many of the teams were not going to deliver as planned even though they, the teams, built the plans and felt good about them at the time.

What else was going on?

One of the most difficult parts of practicing scrum is uncovering hidden dysfunctions. Acme had many of them and we had to deal with them in order to create better, more predictable execution.

Here are some of the issues and some practical ways to handle them.

1. Problem — Teams don’t understand their product backlogs

It never fails to surprise me how many product backlogs are a list of single-line phrases in a tool. I get it. Writing requirements is time consuming. Long ago, people wrote very comprehensive documents to describe every requirement, how to build the requirement, every edge case to test and a bunch of things that they thought they may want someday. These documents were intended to cover everything thereby eliminating the need for conversation or negotiation. Fortunately, we now know that these documents create a ton of waste — either we build things that no one wants, build things incorrectly or take too long to get feedback from our customers.

I don’t see these type of documents anymore, which is progress. But it’s not uncommon to see backlogs in a tool (let’s call it JIRA) which list “requirements” that look like this:

Build authorization capability

Allow user to edit and save information

Fix performance issues …and that’s it.

If this all sounds familiar, then we’re going to have to first admit this isn’t a product backlog which supports planning. It’s not easy to estimate, prioritize or execute independently. In some cases, it’s so ambiguous that every team member may assume something completely different.

Also let’s be fair to our teams — this is not engaging or interesting. How are they going to get inspired by who they are helping and why? Do they all have the same understanding of the customer (or user)? What does our customer need? How will we know we’re satisfying that need? Or better yet, what business problem are we trying to address? Why? How do we know we are done?

The Fix — Build a better product backlog

Simple and obvious, build a better product backlog (there are lots of great resources out there — after fifteen years, I still like Mike Cohn’s User Stories Applied). The act of building a product backlog doesn’t need to be arduous or intimidating. It also doesn’t need to be solely built by the product owner. If a team does not have a mature backlog, it’s worth taking the time to build one together. It also doesn’t happen in one sitting. We expect requirements to evolve as we learn more so we start with a higher level backlog that gets decomposed “just-in-time”.

For anyone who is about to say “but that’s a huge waste of team time, it’s the product owner’s job to build the backlog!”, my counter is “how much waste is created by folks who are building the wrong things because they only have a vague idea of what they are supposed to build?” or “how many innovative ideas are missed when the whole team doesn’t understand or empathize with customer problems?”.

When I first learned agile, it was made clear that the backlog was the product owner’s responsibility. While I want them to build and embrace their backlog, as well as ruthlessly prioritize it, a common complaint I hear is that the PO is too busy to spend a ton of time on writing requirements, so they remain ill-defined. Most engaged team members have many great ideas that can be unlocked by collaboration. Since the responsibility of every team member is to help each other, why wouldn’t we leverage their collective minds to help create and groom the backlog?

2. Problem — Teams cannot create longer term estimates

Agile teams have many techniques to estimate. My personal favorite for longer term planning is to use story points with a Fibonacci scale, but I’ve seen teams use different techniques and still be fine. However, there are times when any of the tried and true techniques fail to work…because the team cannot reliably estimate.

Here are some reasons why this may be the case:

- the code or the problem/domain is completely new. Without experience or a point of reference, any estimate is a massive guess.

- the team members are completely new and have no common frame of reference.

- there is too much technical debt or too many hidden surprises.

Remember the company that I introduced at the beginning, Acme? Their code had serious performance and scalability problems (so serious in fact that, painfully, they ultimately chose to rewrite everything rather than fix it). Any estimate would be inaccurate for Acme’s teams. Either they would miss issues that they would later encounter when building new scalable code in a debt ridden codebase or they would include such an extreme buffer on their estimates that they were essentially useless. Yet these teams continued to be asked for estimates (when will this be done? can it be done sooner?) and time after time, miss all commitments. It wasn’t their fault. Estimation was nearly impossible. Leaders asking the question over and over again didn’t make the answers any more reliable.

The fix: Pay down technical debt and spike when needed

If teams do not have enough knowledge to create informed estimates, there are ways to get help. They could choose to spike to learn more. Spikes are a short time box dedicated to gaining the knowledge needed to create an estimate or approach (through research, pseudo code or experimentation).

In the case of significant technical debt, I encourage teams to build a prioritized technical debt backlog (usually priority = severity or exposure to risk) and budget paying it down. If even building the backlog feels impossible for the team to do, then they can start with building test automation to expose issues. Or they can ask a senior technologist do an analysis of the code, looking to identify areas that are most often used and perform poorly as first priorities for refactor.

Most importantly, if a team is facing severe technical debt, they need to be honest about the condition of the code.

In the case of Acme, rather than building a strategy to remediate and prevent future debt, they continued to commit to dates which were made up. Further, since they were a publicly-traded company, they chose to share the dates with Wall Street. Any guesses how this impacted their stock?

3. Problem — Team membership changes too frequently

Remember Tuckman’s stages of group development — forming, storming, norming, performing? Time together and experience as a team makes a big difference in a team’s ability to predict what they can deliver in the future. Over time, if we maintain the team membership and composition, they get better at planning and execution. This is true even when they are faced with new problems and challenges. There is a lot of value in allowing a team to stabilize and not disrupt the membership. I realize with hiring and attrition, nothing is ever perfect. But I’ve seen the productivity difference in companies that value maintaining persistent cross functional teams as opposed to those that constantly tweak and/or launch new project/tiger/swat teams as short term accelerators. They may gain some short term lift but over the long term, most large organizations need to know how to deliver against a portfolio of work that comprises the majority of their teams.

Moreover, once I have a team that is working well together, they usually don’t want to change.

The fix: Stabilize teams

Scrum works well because it allows us to optimize a team rather than an individual. In order to reap the rewards of that optimization, keep the teams persistent. This doesn’t mean that people have to stay on a team for life, but it’s generally prudent to allow teams to work together for at least a quarter, preferably much more. Even if they don’t have every perfect skill, over this time they generally can get creative on how to overcome issues. If they are truly blocked, then this amount of time will allow you to better understand what gaps need to be filled (architecture? a junior doer? someone who knows how to test really well?).

If persisting teams seems impossible because of constant org changes, then be careful to separate management structure from scrum team formation. And stop having org changes. No one likes having six managers in a year.

4. Problem — Priorities shift often

While it may seem obvious that in order to deliver on plans, we expect them to largely stay unchanged, working in agile should create a healthy tension on scope. Agile teams deliver the best results when they consistently inspect and adapt with feedback. This sometimes translates to a team facing feedback after every sprint, which may alter their future direction. However, accepting or addressing feedback can be different from “changing priorities”. Part of the benefit of longer term planning is to understand higher level priorities and keep focused on big picture execution, rather than changing direction sprint to sprint.

The fix — Make priorities clear, measurable and at the right level

Longer term planning allows a team to prioritize a goal or solve a customer problem with simple metrics to keep them focused on the big picture. Some examples of a goal may sound like “improve customers’ ability to complete (specific) workflow from ten minutes to five minutes” or “increase conversion to do X by 5%”. These types of goals are quantifiable and unlikely to shift with feedback.

Naturally when a team plans they have more flushed out ideas on things that they will do to achieve the metrics. Nevertheless, having the prioritized goal is impactful. When they deliver incrementally, they can measure how they are doing against that goal and further update their plan with new ideas. While this may mean that the actual “stuff” built changes, the plan’s priority should not.

I worked with a team that planned a long backlog of unrelated items that they wanted to deliver in sequence. They believed this adhered to the “priority” rule. Yet, after each sprint when they demoed their work, they found that people had suggestions on how to change/improve what they had just built. The problem was, they didn’t know whether they should accept the suggestions or build the other items on their backlogs. Moreover, the team slowed down their execution because they fully believed they would have more “tweaks” to do in the future. Had they started with a prioritized goal and some metrics, they would have had insight on whether they should keep working on what they had just delivered or move onto other items and backlog the new suggestions.

5. Problem — Culture or misunderstood expectations

Culture is almost unfair to list as a problem that contributes to planning but I want to list it because I work with a lot of leaders who absolutely say and want the right things and yet their teams either don’t believe them or ignore it. Here is an example: a belief that long term estimates must be commitments. We know the accuracy of an estimate is related to the time frame we use (eg- estimating for a day is easier than estimating for a year). Yet I have worked with teams that absolutely believed that the guesses that they made in an annual planning offsite needed to be 100% accurately delivered. When I questioned them and the executive team about this, I found that often the execs were reasonable in understanding these were planning projections which needed to be vetted. In Acme’s case, it was the middle level managers who had created these estimates that most believed that they were fixed. When faced with feedback that the estimates were incorrect, they did everything in their power to deliver on them — including taking shortcuts or working in a way that didn’t make them proud — rather than change the estimate.

Another culture factor is the presence of a culture of fear. This one is tough to understand but can be easily seen. It looks something like this: “I have to deliver this plan. If I don’t, then something bad will happen.” No one ever can tell me *exactly* what the bad thing is (someone will yell? a bad performance review? someone gets fired? all of it?). Yet fear of this “bad thing” influences behaviors. The challenge with a culture of fear is that it prevents teams from taking risks, often learning and innovating. I have never seen teams in this environment deliver better than those in cultures without it.

The fix: Create clear expectations, reinforced by practices

Every company needs to understand what signals team members are getting and be comfortable with their intended and unintended consequences. For example, often teams that go the “extra mile” are rewarded by praise, bonuses or other. Without wishing to short change these hard working folks, everyone else is learning that in order to get recognized you must be a hero. And heroics are only needed when there are problems.

Companies should consider what percentage of their plans are truly required and how much flexibility they embrace. For example, at salesforce, we viewed teams that delivered about 80% of their plans as a success. For this culture, 80% meant be aggressive, take some risks but because of a high number of dependencies, don’t plan without thoughtfulness. In exchange, we promised the teams we would not shift priorities nor would we shift teams.

If someone (usually a leader) sets an expectation that “failure is not an option” or “don’t give me bad news, just make it happen” (as we had in Acme), it rarely delivers a healthy result. Teams have a long memory of these phrases even when the phrases and leaders change. I recently worked with one manager who flat-out refused to tell his leadership that his plan was wrong (despite their very nice requests and offers to help) because he didn’t want to disappoint them. While you may expect that he subsequently drove his team to work harder to achieve the unattainable plan, in fact the opposite happened. Since he and the team considered the plan to be unattainable, they worked at a very leisurely pace because they knew it was impossible and didn’t believe it was worth the push.

Final Thoughts

In summary, longer term planning is hard but very achievable in agile. For any team executing in a scaled environment with dependencies, it is crucial. There are lots of strategies to improve the reliability of planning and delivery, depending on the root cause of a team or company’s issues. I’ve tried to list the common ones I’ve seen.

In addition to all that I’ve said above, I also always recommend asking a team what they need in order to remove uncertainty and gain comfort in their plans while they are still planning. It’s a lot easier for teams to build longer term plans when we accept that the plan is simply the best guess that we have, based on what we know today.

Tomorrow, next week and next month, we’ll continue to know more. Hence, we want and expect that plans will need to be recalibrated throughout the delivery cycle. For the most successful teams I’ve worked with, planning is a regular activity rather than a one shot moment. Best of luck.