What do you do when your agile software development project is hard up against a deadline, stakeholders are complaining about their value proposition, and you are constantly trying to justify the project's ROI to date?

Maybe the answer is a project reset. Maybe the answer is adding more time, cost or people. Maybe the answer is a folder full of change requests.

But then maybe, the answer is we had it wrong from the start.

There is a never-ending list of reasons projects fall behind; Delays in dependency architecture, Vendor supply issues, tech support problems, change in direction from stakeholders based on market conditions causing rework. Sound familiar?

My name is Matthew, and I want to talk to you about some of the common challenges that new Agile projects face, based on the experience that I have in the industry. I’ve done almost every role in an Agile team, from Product Owner to Team Member, to Scrum Master, and most recently as a Release Train Engineer (for those of you who do SAFE).

This will be a short 3-part series that describes what I think are 3 common roadblocks that I see in a lot of projects, and I’ll also throw in one suggestion on how to manage each of them. So stay tuned over the next couple of weeks while we talk about each of them in turn.

One of the most common issues I see in modern software development starts at the top - Management of the project. My opinion is that the common problems we see in modern agile projects tend to stem from only applying part of the methodology, or only having part of the team invested. Taking out parts that look like they double up with existing processes or omitting key roles within the project because they don’t seem that important. Ultimately, I think it comes from a mindset to mix traditional project methodologies with agile – which is not necessarily a bad thing, if you have a foundational understanding and experience with the method first.

So what are some easy ways to identify whether our organisations are walking into this pitfall? I have 3 questions that I ask on any engagement that I move onto, and this is not by any means an exhaustive list, but they identify the big red flags for me:

1. Have we set a solid deadline that we plan to “Go-Live” on. Nothing is released to production before that date for users to interact with?
2. Have we set the expectation that stakeholders can change their requirements after the team have delivered a piece of work?
3. Are the developers commenting that they don’t understand functionality or need more information when they start on a piece of work?

If the answer to any of the questions above is yes, then I know that the project has a risk that will likely cause a delay without being addressed. Each of these questions targets a fundamental problem that I see quite commonly in organisations just starting their agile journey. So lets work through them and see how we might address each of them.

Solid Deadlines.

The Problem:

There is nothing wrong with deadlines, in fact sometimes they are important, especially for legal and regulatory requirements. What you want to avoid however is the notion that nothing should be released until X date, and on that date we will have a significant wind down, people will move onto other projects, and from now on it will be only small fixes.

This causes a loss of solution specific knowledge, which can make changes at a later date difficult. It also means that your business users don’t get any value from the solution till right at the end. This is not even to mention the amount of overhead involved by managers, legal, and contract writers in order to adjust course if something does change, It’s a nightmare!

One of my previous clients was a nation-wide logistics and storage company. One of the key challenges we faced here was a hard deadline, mixed with unclear requirements and a revolving door of project managers and staff. I will talk about the issue of changing requirements next week, but the hard deadline, fast approaching looked less and less likely to be met. One feature after another the timelines blew out due to scope creep and differing opinions in the client team when the functionality was shown at demo, and that deadline? It came and went…

And then again…

And then again…

2 years later The MVP was ready to be launched, and everyone lived. But the value provided by the solution during that time was a big zero.

The Solution:

Consider moving the project from fixed resourcing with a concrete scope of work, to backlog based approach. If you use a service provider for your software development capabilities, consider putting them on an ongoing retainer agreement. Why? Because this way if there is a change in direction or priority of features, you can simplify rearrange the work and bump it up to the top of the backlog to have them work on that next. It also allows the scope of work to be flexible, if there are delays, then everyone is clear on what the least important item is that can fall off as “non-critical” and be delivered later.

Using the backlog also allows for forecasting based on actual performance. If you know the teams average throughput, then you know if you need more people to make things happen by a specific date and can adjust accordingly. This way we are not using an estimate made by a manager that may or may not have the actual experience and skill set to do the work directly. The estimations are done by the people on the ground that live and breathe the work every day, and is based on actual historical throughput, not some estimation of hours on a spreadsheet.

Lastly, if you are ever dissatisfied with a vendors value delivery, then you can end the retainer agreement instead of being locked in for the next 1 – 3 years. You still retain the value already developed without needing to “start again” with a new vendor.

Stay tuned for my next post where we will talk about “Changing Goalposts”.