Successful bespoke software development depends on a number of factors. It is a complex process that often involves at least three interested parties: the client, the developers and the project manager.
Even though the common goal is to deliver a valuable product, I often observe how misunderstandings and individual goals can put software projects at risk. The good news is that with a few good practices you can avoid most of the risks and deliver a great bespoke software product.
Let me list 10 best practices my team finds the most valuable (in random order) when it comes to bespoke software development.
1. Focus on business goals
Simon Sinek gave a famous TEDx speech Start with why – how great leaders inspire action. Your business goals are the whys for your product. None of the clients I’ve ever worked with made their application for fun. There was always a goal behind it, be it to prepare the MVP to show it at a certain trade fair, cut down on production waste or visualise project progress. Only when the client shares their expectations, problems and visions, the development team is able to design solutions that answer the need and set priorities in the right order.
Among all possible solutions, technologies and architectures, we need to choose one that best supports the goal. Plus, among all possible features, the client needs to pick a short list of absolute must-haves.
2. Deliver product, not features
It might seem obvious but software development is not about writing code – it’s about delivering the whole application. As much as developers work on one feature at a time, this feature is always a part of a bigger picture.
Focus on current task is a risk for the entire system – developers choose short-term solutions, project managers and clients accept them and then it turns out the solution doesn’t match the rest of the application.
To see this picture, the entire team needs to be aware of client’s (and product’s) goals and priorities. Also, they need to constantly check if what they produce is coherent and useful.
3. Deliver less and more frequently
Even when the product itself is a huge e-commerce system with tens of integrated services, you need to divide it into the smallest possible chunks. Why? It will be easier for you to define clear requirements for a smaller set of features. You’ll be more precise. You’ll get more done because the focus of the team will be not on filling in the gaps but on releasing a working part of your app and testing it with users. The same goes for tasks. We have a rule that a single task should not take longer than 6.5 hours of development. If it takes longer, it’s too big and needs to be divided.
4. Speak about the problem, not the solution
Teams that build bespoke software are used to brainstorm and search for optimal solutions. They know everything about the system they build. Also, they know where they can take shortcuts or save time, and where it makes no sense to do it. When you come to the team with a ready solution you strip them of their biggest advantage – taking the ownership of the product and caring for choosing the best possible solution. After all, you chose to work with them because you trust them, right?
5. Have a single source of truth
I would lie if I said that project requirements don’t change. They always have and always will. What you can do is to make sure everyone is aware of the change. It means:
- Whenever there’s a change, evaluations are updated and accepted by the client.
- User stories and tasks are prioritised properly and updated with the latest information.
- Project budget and timeline reflect the change.
With these three rules in place, you’ll see that even when the scope is very dynamic, everyone’s on the same page.
6. Communicate frequently
There’s a lot to say about communication as a key success factor for every project, not only in IT. Of course, it concerns not only the client but also the entire team. Both daily standups or weekly (biweekly) demo meetings ensure that the feedback loop is alive and kicking. No matter how many applications and project tools we use, a face-to-face conversation beats them all. Standups are the fastest way to observe the progress (or ask why we’re lacking it) and demo meetings help to evaluate whether clients actually get what they want.
7. Describe the requirements in details
The root of all (or almost all) evil in software projects are the incomplete requirements and last-minute attachments. It’s a tedious and hard job to put together detailed descriptions of every piece of the application but there’s no other way to do it right.
A well-defined requirement should contain:
- Description of a user story/task.
- Business goal – why it’s so important to develop this feature.
- Acceptance criteria – a checklist that shows when a feature is ready.
8. Use style guides
If you read point 1 you know that I don’t see bespoke software development as writing code. Still, since there’s a development team involved, it’s valuable to have a set of rules that help them write a code everyone understands and is able to maintain. A side effect is that in code reviews developers focus on the value of the code, not on style convention. We use:
- Pre-defined environments for each framework.
- One name convention across projects.
- One coherent code style (using tabs, brackets, spaces etc.)
9. Track the progress and budget on a weekly basis
It may seem a no-brainer but it’s not. In software projects, things tend to change fast, especially when we deal with time and material projects. Teams evaluate new features even on a weekly basis. But there’s one thing that holds the entire project in place – the budget. For obvious reasons, the budget is important for the client. But there are other benefits from updating the progress and budget on weekly basis.
- Clients see they’re in control. When the expenditures are transparent, they are more willing to give change requests a second thought. It brings stability to the project.
- Developers can see that the project is moving forward. Visible progress is one of the biggest motivators. If you see that every week you’re 12% closer to the end, you know your hard work paid off.
- Project managers know when they can expect to bill the client when the morale of the team is high or low and they’re able to discuss facts at every review with the client.
10. Speak the same language
There’s a concept in Domain Driven Design (DDD) called ubiquitous language. It’s a situation when everyone involved in the project names and understands the same elements in the exact same way. This way fees are always fees, not taxes, costs or expenses. Using the same name conventions by clients, developers, designers, project and account managers make it easy to discuss, report and make references without the risk that we would be talking about different things.
The same refers to the process. Making sure that we all understand estimates, phases, deploys and releases the same way saves both sides time and stress.
Successful software development is a product of a fruitful collaboration between clients, project managers, designers and developers. The list I presented comes from my experience in managing telecom projects, business intelligence implementations and running a software studio. After many years in the industry, I realised that bespoke software development is not that different from collaborative board games. As long as the entire team works together on the common goal instead of pushing towards achieving individual ones, you can be sure the project will be a success.