Skip to content
Home » How to Avoid the Organisational Big Ball of Mud

How to Avoid the Organisational Big Ball of Mud

You’ve started working on a new project. Your job is to lead your team through the challenges that you find. You must improve the reliability, speed and quality of software delivery.

The project comes with a lot of pressure to deliver a system on a quick turnaround to interface and work with a client’s system. The client is powerful and highly valued.

Your development team is mainly external, and while the devs are not the most experienced, they are diligent and competent. While the system is reasonably mature, the development teams struggle to keep up with the demand for new features. The new features are being specified in an ad-hoc manner based on input from the partner – and the devs you’re working with don’t have enough business understanding and experience to confidently design the system in such a way that can adequately anticipate or push back on changes.

Additionally, there seems to be little attention being paid to any form of formal or informal software development lifecycle. Requirements are often simply specifications and too detailed at that.

Functional testing appears to be mainly manual and breaking changes often occur because of inadequate testing during the rush to roll out new features. Code coverage is low. Toil is high.

How would you approach this project? What would be the first thing you change to make an impact?

One approach you can take is to build up a list of things to do that you believe will start to address these challenges:

  1. Firstly, make it clear to the Business Analysts that their job is to capture requirements and not write detailed specifications. This could be hard for them because perhaps they are not very used to working with the systems. They must lift their heads to see the bigger picture and then hand this knowledge to the developers through well-written stories.
  2. Ensure that the developers understand the stories that they are implementing from a business perspective and that they need to think along with refinement and design. Furthermore, ensure that they test features adequately from the functional viewpoint and not just see them as technical components. Functional fit is paramount; they must feel the pain of manual testing and get it automated.
  3. Ensure that everyone agrees on how to work in the team and who is in charge of what parts of the process. If, for example, you’re working in a team with many “POs” and multiple Developers, the responsibility for writing and signing off stories is unclear. It’s not clear if they are doing Scrum or Kanban. It’s unclear who is in the lead when something goes wrong with a feature, a deployment etc.
  4. Encourage everyone to take an interest in the architecture of the component that you work on. If you feel like a component team, then perhaps that in itself is a potential smell. Can you adequately express business needs (and use cases) through your current architecture?
  5. Encourage a blame-free culture. Encourage trust. Ensure that everyone takes responsibility for failure and success and that they are all there to help when there are inevitable challenges.
  6. Pick one SDLC methodology and try to stick to it. If you’re doing Scrum, then do Scrum but do Scrum your way. Just agree your way of working with everyone. Yes architecture is important, but a way of working – a Software Development Lifecycle – trumps architecture every time. Without a working method, even the best architecture can fall apart quickly.

In addition to addressing the challenges you have as a team, think about what you can do to improve your knowledge and posture within the organisation to gain authority.

Such as:

  1. Learn the architecture and data flows.
  2. Lead by example by providing clear stories with requirements and ensuring that other POs understand why you are doing things a certain way.
  3. Encourage freedom of expression and courage in owning and defending decisions.
  4. Show trust in those around you.
  5. Challenge the behaviours of those not working in the project’s best interests.
  6. Help to improve quality through testing and automation.

What others behaviours would you define as being important to the success of a software project?