Intrigued by the extensive benefits of working in an agile world, far too many executives think that agile development allows unlimited changes in scope while maintaining delivery dates. After all, you can always add more developers. I suspect these are the same people that believed clapping saved Tinker Bell.
In fairness, sometimes adding people to an agile development project can preserve a targeted timeline while expanding scope. But that involves a complicated calculation by the Scrum Master and development team, in collaboration with the client and product owner. How much time do new team members need to onboard and to get up to speed? Will new team members opt to take a different approach, which could slow things down? Will the existing developers need to spend extra time onboarding new team members, which will impact commitments on their current deliverables? Has someone reduced the amount of code a manager can deliver, given that additional people now need to be overseen by that manager?
Agile means extensive flexibility, not infinite flexibility. At the beginning of a project, the scrum team will work on a product roadmap based on the existing requirements. As features are added or changed, that roadmap changes as the scrum team makes detailed calculations of talent deliverables, project timetables and needed feature sets.
Not all changes are equal
IT executives and project managers should know that all project changes are not created equal. Some changes that appear easy can actually change the overall design and impact the code of the entire project. And some changes that execs fear are big deals can, in fact, be easy and quick to execute. Clients need to ask the team about specific changes and wait for the answer before making any budgetary or planning decisions. The changes also depend on where the project is timing-wise. As developers often say, “It’s like we’re building you a house. You are about to move in and you decide you need an extra bedroom. We can do that now but we’ll have to tear some stuff down and rebuild it to make it work.” Working with your scrum team closely as a partner allows you to add features and capabilities intelligently. Letting them ask you questions about your future ideas helps them plan ahead to make everything as scalable as possible.
Communication is key
A related problem that we often see involves the frequency of lost communication between client teams. The leader of the client team will say that a deadline—say, perhaps, to coincide with a product introduction—is sacrosanct. No matter what happens, the team leader will stress, something must get delivered on that date.
Then, a week or two later, another prominent team member asks for a scope change by seeking several additional capabilities. In an effort to please the client, the scrum team enthusiastically starts working on the exciting new changes assuming that all team members understood that the delivery date would change. But unless the impact is broadcasted to the entire client team immediately, things can get ugly.
Documenting even the smallest changes is very critical and broad communication must accompany any changes to scope. An appropriate email response would be something like, “We have evaluated David’s new deliverables and have modified the product roadmap accordingly. If these are must-haves for MVP, then we will need approximately “X” extra sprints. Otherwise, these new deliverables or other existing deliverables need to be shifted to post MVP. We have evaluated the timeline impact on the project based on your requested scope changes. Beyond the impact on the budget, it will make it almost impossible to keep to the original schedule, setting us back at least five weeks. We need explicit authorization from all that we can make that change to the schedule. If not, these changes would need to await Version 2.0.”
More ≠ faster
This gets us back to the mythical magic of adding people/resources/hours to a scrum team to accelerate a project. It works sometimes, but not always. That’s why clients need to work with their Scrum Master and jointly agree on the best path forward. Additional resources may simply burn more budget while not getting the client what they really want, nor what they expect.
A lot of times, it just doesn’t make sense. Is it the right time to add a person? Is that going to help the timeline or actually pull it back?
Developers matter
The client seeking those additional capabilities will ask, “Why can’t someone just jump in?” This is predicated on the notion that developers are all interchangeable. They are not. These are creative professionals. If you take 20 experienced developers and show them the same problem, you’re likely to get 20 different ways to solve it.
The new developers need to be fully onboarded, their environments need to be set up, the new team member needs to conduct research and might just see a different path for the project. That path might be a better path and the Scrum Master needs to evaluate that. This all takes time.
Ultimately, timely project delivery comes down to: A. Better communication and education – and – B. More or better resources. The education component is on both sides. A scrum team needs to understand the business goals, objectives and strategies so that they can make the best recommendations and design decisions. The client team needs to understand the design, development and delivery process as clearly as possible. That way, they’ll never be surprised when they hear that the project roadmap might be impacted.
Working together, client teams and scrum teams can track status aggressively and can flag issues instantly if things start to shift. That is what agile development is all about.
