Rework is Inevitable

A common concern for many development teams when they are planning a project is avoiding rework. There is the idea that if they can think through every scenario at the beginning of each stage of the project, they can avoid having to redo designs, documentation, or code in the future. On the surface this is understandable, as having to redo tasks unnecessarily can definitely be wasteful. However, anyone who has worked on a project, especially an Agile project, knows that once a design or feature has been released to end users, there will always be unexpected feedback that will necessitate rework. 

False Sense of Efficiency 

One of the biggest issues with traditional project management (waterfall) is how long it takes to get feedback as a project moves between the different phases of development (requirements gathering, design, coding, etc). The theory is that if, for example, a team gathers all the requirements up front, time will be saved and the designers will know exactly what they need to create. When designers finally start looking at the requirements, they will usually discover things that weren't accounted for when the requirements were gathered. This means the requirements team will have to look at these new requirements and get approvals or sign-offs again. This will typically repeat in each of the handoffs from department to department and instead of being efficient, it ends up leading to delays, higher costs, and a general lack of satisfaction for everyone involved. The iterative nature of agile development helps to mitigate this, but the fear of rework can still lead to excessive planning sessions and a fear of moving forward without having everything nailed down.

How Much Planning to Do

In order to prevent rework, teams can spend way too much time trying to think of every little scenario so that they won't have to worry about something in the future. With that being said, they still need to meet the primary goals of their project and ensure they don't deliver something that is poor quality or terrible to use. The idea is NOT to be sloppy, but to accept the reality that rework will be needed and show progress quickly so that the overall amount can be reduced. By working in short iterations a team can learn quickly and they will not have done so much that the amount of rework is overwhelming.

The idea is NOT to be sloppy, but to accept the reality that rework will be needed and show progress quickly so that the overall amount can be   reduced.

So the big question is: how much research and planning should teams do? The first thing the team needs to do is determine which outcomes are the most important or what are the biggest questions that need to be answered early on. The team can then set a time box for breaking these outcomes/questions into smaller pieces (Scrum ceremonies are a good example of how these time boxes can be incorporated into a project) and brainstorming the things they want to address. Having these smaller pieces gives the team an idea of some of the bigger issues they should keep in mind, but still provides the flexibility for the team to prioritize in a way that will allow them to work effectively and not try to solve for everything at the same time (my recent post around prioritization might be helpful in determining the priority on these items). They can then move forward, get feedback and do whatever rework is necessary. This not only ensures that the amount of overall rework is reduced, but that it is user-driven and adds real value. 

Keep Options Open

When a team is first starting to build something out, there are usually many unknowns. This uncertainty is what often leads to trying to account for too many scenarios, and there is some pressure to have an answer to every question right away. The truth, however, is that the team doesn't really need to have all the answers to move forward. Many times those answers are based on false assumptions and then end up being wrong. If the team had spent time planning and completing any work it would now just have been wasted effort anyway. A more helpful method is to avoid committing to a solution as long as possible and build in a flexible and future proof way. This can include tactics such as building in a modular fashion with components that can be reused and reorganized without too much effort or building a few simple prototype/MVP solutions that can be reduced and fleshed out as more is uncovered throughout the project. 

Final Thoughts

While I think it is good to have some foresight when developing a new program or feature, I think it's more important to prevent fear of rework from slowing your teams down and making your feedback loops longer. This will allow them to learn quickly, continuously adapt, and ultimately deliver the most value to the audience they are trying to build for. 

How do your teams manage this balance between building something efficiently, but not trying to account for every possible scenario?