One of the most common reasons why software projects fail today are due to misunderstood or poorly clarified requirements. Either because the business are not aware of the business goals they are trying to achieve or they fail to communicate them clearly so everyone on the team understands.
The business stakeholders and the developers also each have their own professional terms and they need to get aligned to avoid misunderstandings and create a common language.
Communication problems are not just a source of annoyance, it can damage a project greatly leading to functionality that does not work as intended or worse - not work at all.
To make software projects succeed we need to solve the communication problem.
Build the Right Thing
It’s not that complicated to build something that works. It’s much harder to build something that works as intended and that delivers the desired outcome for the business.
To ensure we meet the right business goals we need to understand the business domain and what the desired outcome is rather than what features to build. Only when everyone on the team know what impact the business are trying to make, we can all pull in the right direction.
In Reload we like to use Impact Mapping to keep eye on the target, focusing on meeting business goals instead of just delivering features. It helps us navigate in the situation where a customer gets an idea about a new feature in the middle of the project that affects the scope. Does it fit with the business goal? Then we welcome it on the map and consider it. If not, then we discard it - at least for now. This way we can prevent feature creep and protect our resources to only build what matters the most.
Impact Mapping is a great way to support communication, having discussions about business goals instead of features. Deciding whether a feature is important or not is difficult without understanding how it supports the business and what goals it achieves.
Break it down
Software projects often have a complexity that makes it hard or risky to deal with everything at once. Therefore an agile approach is advantageous because we don’t try to figure it all out up front, but prioritize one task at a time driving out the complexity of the project.
We break tasks down into smaller more trivial ones, starting with the simplest and most important one. As we go we can use our newly gained knowledge from the first task to make better decisions about the next. Knowledge increases over time so the longer we can put off a decision the better.
It takes time to get to know the business domain well. By limiting the up front analysis and instead collaborate close with the customer we lower the risk of taking decisions on a thin basis. Breaking tasks down into simpler ones strengthen our ability to talk about them, making them manageable and concrete instead of abstract. But we should only break down one task at a time to limit the complexity.
The Three Amigos
It takes two to tango and at least three to cover all possible angles of a software problem. The term “Three Amigos” refers to a team of three consisting of a business representative, a developer and a tester. Each having their own angle to the problem.
The business person have insight into whether or not a solution returns business value. The developer can give advice on the implementation details and the tester can foresee where the problems might arise making it possible to prevent them before they happen.
The conversation and collaboration between the three are invaluable. It makes sure we have considered the problem from all possible angles before development and by having a conversation instead of handing over documents from one person to another we have reduced the risk of misunderstandings. Written specifications leave room for interpretation. Having a conversation leave room for questions and clarification.
There will always be misunderstandings, but the longer the three work together the fewer there will be. As time passes they become accustomed to each other’s language. Ambiguity will be ruled out and a common language will be created.
Get into the Feedback Loop
If we are going to fail, we better fail fast. The earlier we get feedback on our work, the earlier we can learn from it, correct the mistake and move on.
A good way to get early feedback is through continuous delivery. By building, measuring and learning in small incremental steps. Every time a new feature is finish, it gets released and the customer can give instant feedback. Since we only make small changes between every release the risk is small.
Another good way to get fast feedback is to prototype the solution before developing. Giving visual examples to the customer before developing can clarify different assumptions and rule out misunderstandings fast.
Examples are an extremely powerful tool for communication. Examples describe how we want the system to behave in a certain situation with a specific set of data. Examples can both be used for specifications, documentation and as test data for evaluating if the system works as intended.
The Devil is in The Details
Specifications are best written by the three amigos in collaboration in a face to face meeting. To make the specifications clear and understandable they should include real life examples.
Examples can be used as great conversation starters exploring both the ordinary behaviour and the edge cases leading to new questions, rules and examples fleshing out gaps, inconsistencies and every little detail of the functionality.
A good way to leverage the use of examples is to use them both as specifications, tests and documentation. This approach is called BDD (Behavior Driven Development) and it helps you ensure that was what intended from the beginning when you wrote the specifications, also is what gets delivered in the end. If the test passes with the given examples the implementation fulfills the specification.
The Heart and Soul
To prevent software project failures good communication is at the heart. Always aim for delivering software that matters by meeting the business goal. Use impact maps to navigate safely through the project staying on course. Reduce complexity by attacking one issue at a time, breaking it down into smaller ones making it tangible to investigate. Collaborate across the different roles in the team and involve the business representative as much as possible. Implement a short feedback cyklus making it possible to fail fast and learn from it without risking too much and lastly use real life examples as much as possible. Examples beats a list of instructions every single time.