Welcome back!

Today we will be talking about the challenge of changing goalposts within a development project.

Now I’ll be upfront… I’ve been here before. At the time the project was in a bad way and it needed to be fixed, and fast. 
I’ve spoken in my last post about a Global logistics client that I have worked with, I even mentioned that changing requirements was another challenge faced in that environment. What we found was that whenever the team would deliver a feature and bring it to demo, we would inevitably end up with rework to be done, and not minor rework, sometimes the whole solution would change.

The challenge we faced was the separation of business teams within the client organisation. Each stakeholder had a different opinion on what should be the way in which a specific feature worked. One wanted shipping charges to be calculated as a total for an entire delivery chain, someone in finance wanted the charges to be broken down into each individual leg of the chain. But we didn’t know this at the time, so when it got to Demo day, the team were disheartened that they had to go back and rework their solution again.

There were a few factors here. One we could have done a better job at managing stakeholder expectations had we known there was misalignment. Two we could have gotten something in written form to note the Acceptance criteria (a separate issue - there was none). And three we could have employed some more of the tools in the agile tool kit to draw the issues out up front. Ultimately the delays that were faced summed up to changing the goalposts at every turn and needing to do a significant amount of rework.

Changing Goalposts

The problem

Changing requirements is also not a bad thing, the ability to change goalposts is what grants an organisation agility in its market. The issue arises when development teams are asked to build something to a set of requirements, they do so, and then the stakeholders challenge the output because things were left out that were never documented.

What we normally see here is that once these issues start arising, the development teams are forced to begin reworking that item two or three times to capture all of the items that were missed, and the cycle repeats for every feature in the project. Its not uncommon for the project timeline to then blow out to 2, 3 or 4 times the expected delivery date as a result.

The next thing that happens is pretty predictable….

“That’s not in scope”

“We didn’t know about this requirement”

“I’m not confident in this solution”

All things you never want to hear as a project lead.

The Solution

Take caution when writing or changing requirements. A good business analyst that is trained in how to write technical specifications or agile user stories is worth their weight in gold. Product Owners are a key part of Agile and should be the one-stop shop for all the requirements related to the feature that the team is working on. And if you don’t have a Product Owner, then there is also a good chance that the goalposts will change even depending on which person in the business team you talk to.

When we see this pattern of changing goalposts, one technique we employ is to begin having the teams focus on Test Driven Development (TDD), where the test scenarios are written first, and development is built to pass the tests provided – and let me be clear there is always push back from the business on this approach, but it is the most effective way to cleanly see what is required for the ultimate outcome, and if things are missed, from a management perspective it allows us to see whether it’s the Dev teams or the Business writers that need more training.

It takes a few weeks to get the ball rolling in this fashion, but as the project continues, then the number of feedback comments reduces, and the quality of the test plans begins to improve. Consider bringing in a consultant for a few weeks to help your Product Owners of Business writers to understand how to write Test Driven Development plans and make sure that each pathway is explored for completeness of the solution.

Stay tuned for my next post where we will talk about “Solution clarity”.