Welcome back!

If you’re just tuning in now know that this is part 3 of 3 in a series of challenges and potential solutions for new Agile projects. If you haven’t read my previous two posts I would encourage you to do so now here:

Article 1 Solid Deadlines:
https://lynkz.com.au/blog/post/navigating-agile-project-management-common-challenges-and-solutions

Article 2 Changing Goal Posts:
https://lynkz.com.au/blog/post/navigating-agile-project-management-changing-goal-posts 




Today we will be tackling the challenge of Solution clarity and how it can affect the ability to develop high-quality systems.

I once worked with a large international automotive supplier. They had a great product idea, they had a solution planned to improve their operations and sales, and it would have launched them into a further era of prosperity. There was just one problem, the solution they had planned lacked any detail, and the development teams didn’t have a clear objective in mind.

Now this was not the biggest issue to resolve, however, it had been left unchecked for a significant amount of time. The client's plan at the time was to throw more people at the problem which wasn’t working, and it resulted in a cost blowout and very little progress.

So what could we do to help? We brought in some good BA’s and Product Owners, that’s all it took! Once the client had people really looking at how the system was intended to be used and articulating that back to the development team in a way that made logical sense, the project started to take off. Within a year the project to develop a massive sales, logistics and manufacturing management system was ready for release 1 to happen. All it took was a bit of clarity…

Solution Clarity

The Problem

Often the developers in a team might start saying things like “We don’t have enough information” or “What is the use case for this?”. This is a blaring alarm signal that struggle lies ahead.

Lack of understanding in a solution is probably the biggest rework factor in inexperienced teams, or organisations new to working with Agile. It can cause miscommunication, poor quality of deliverables, and blowouts to the project’s timeline. All-in-all it erodes trust between the stakeholders of the solution and the development team.

Often this can be a fairly easy issue to resolve, but if you're not looking it can get away from you. Lack of business process understanding or day-to-day operational factors makes the development team's job harder by ten-fold. It results in rework from changing goalposts (which I’ve spoken about in my last post). It results in dissatisfaction from the business stakeholders making change adoption much more difficult. It drives project managers insane trying to determine why their throughput is so low.

So what can we do about it?

The solution

My normal approach in this situation is to take a pause and bring in a specialist in capturing requirements. To start including the stakeholders in discussions directly with the developers. And to do workshopping to physically draw some of the concepts on poster paper in front of the developers (as a bonus if you use design thinking you can often get these workshops done exceptionally quickly). This improves the understanding across the projects and helps cultivate respect between teams that may have lost trust in each other.

Next up is to write it down. In almost every project I have come in to assist I’ve discovered that the requirements are locked in someone’s mind from discussions that happened months or years prior, and as you may predict, that person has no time to do any work because they spend all of the time answering questions and taking calls.

Finally, you can spend the time to build a robust backlog, with properly defined acceptance criteria and user stories. This is the one that I spend the most time trying to fix after the fact and has the biggest impact on team performance.

Conclusion

That brings us to the end of this 3 part series on common Agile challenges and how to stomp them out.

All of these things represent major risks for organisations dipping their toes into software development and agile, and when put together compound each other. But the good news is with proper monitoring and management, they are easily avoided. I cannot recommend enough the value of having a good Agile Coach in the organisation to guide you. Intercepting these issues before they have a chance to take hold will greatly increase the success rate of software development projects within your organisation.

I hope you have had a great time reading my thoughts on these issues and encourage you to let me know if you agree or disagree. I’m always open to learning new things so if you think you have effective strategies to combat these issues or would like to see more writing like this, let me know!

If you want more information on how to improve Agile in your organisation, or if you are thinking about moving to Agile and want to avoid some of the common pitfalls, feel free to reach out and our sales team can work with you to bring a solution that helps set you up for success!