Last week, a CEO asked me a great question. His tech team told him they would be missing their delivery date, which was the very next day. He was obviously frustrated. He wanted to know how this sort of last-minute “oh, by the way, we’re going to miss tomorrow’s deadline” scenario could be avoided.
“Avoided?” I thought. “If a tech team is doing that, they should be fired! That’s not just irresponsible, it’s almost criminal!” I stopped myself from saying that out loud. Instead, I told him this:
If this is happening to you, it means the technology team is hiding problems from you. When something went wrong early on, they didn't say anything. And now, there is no time to fix, to pivot, or to call in more troops.
Here are practical things I recommend doing on a project to prevent last-minute missed-deadline surprises from happening:
Start with a realistic plan
Ideate the road ahead. At Stride, we have Inception meetings. They require all stakeholders and the technology team to collaborate and clarify assumptions, state business vision, and define the initial scope of work. We break down that work into stories and tasks, estimate that work systematically, prioritize everything in a master list, and come up with an initial project plan that shows how we predict we’ll burn down our backlog.
Realize that everyone truly is on one team
Whether you partner with a software consultancy like Stride or do all the work in-house, it’s critical to realize that everyone is on the same team, rowing in the same direction toward a shared goal. That requires a massive investment of everyone’s energy, but we think it’s worth it. The team must identify and fill roles, including the domain expert, product owner, and source of the product vision. These roles can be filled by one or multiple individuals.
The team should ideally have a daily stand-up detailing progress, weekly demos of the software, as well as lots of ad hoc discussions about how the product should behave and what’s next. Everyone should be along for the entire journey. Developers and everyone on the front lines should be involved from day one. Nothing should come as a surprise to anyone.
Revisit the plan again and again
Every week, review the plan that the team defined at the start. Did any new scope get revealed? Was a technological problem bigger than expected? How good were our estimates from the start? Do they need to be updated based on new information? Any risk to our plan needs to be reflected in an update.
Focus on prioritization
Features should come as an ordered list, so that if we are cut short for any reason, we have worked on the most important thing all along. And this enables the team to truly embrace change. If a stakeholder or external market shift demands we add additional scope, we can easily and quickly identify where the new scope fits in. Be disciplined about having weekly priority and planning meetings so that the team stays on top of deadlines.
Admit roadblocks, work the problem, and do everything possible to fix issues
Problems happen. But sugar-coating or ignoring them will come back to bite you, in the end. Be radically transparent. Admit when a problem is happening, so that the team can start solving it immediately. Develop a trust relationship with as many people as possible, so that individual political agendas do not block team efficiency.
Reduce risk
Tackle risky things first. Look at your roadmap and ask, “What are the things that, if we can’t figure them out, will cause the entire project to fail?” Then, solve for those things first. And then, only build features that have been proved to have business need. Brutally cut scope. Prioritize work seriously, and work on only the highest priority every single sprint. To ensure that you build a safety net around your code so that it’s malleable as you scale, practice test-driven development. And wait until the “last responsible moment” to make architecture decisions, to prevent excess work.
The biggest mistake teams make is fooling themselves into thinking they have everything figured out at the beginning of a project. Instead of fearing change, it’s wise to assume that requirements and assumptions will change over the course of the project. The beauty of agile software development is that, when executed well, it enables teams to respond gracefully to change. Start with a plan, and know that the plan needs to be revisited hundreds of times, as the team is delivering working software.
Keep these tips in mind, and you’ll be well on your way to a successful experience.
Want to learn more about improving team performance? In order to launch your team for success, improving communication between team members is an important first step. Our free eBook takes you through five easy steps to restore effective communication within your team.
Madelyn Freed
