I will try in the following to explain my preferred way of developing software. I hope you will find it interesting and useful.
Trust
The most important part is getting a capital of trust from the customer right from the beginning, for the sake of all people involved in the project. If there’s no trust, it’s better to run away because the team and the product will get hurt.
Once I get the initial trust, it’s my top priority to maintain it. I look for any sign of misunderstanding and discuss the root issues as soon as possible. I ask for feedback from time to time: How do you think we’re doing? What would you change? Is there something you don’t like about how we do things?
The discussions often move from business requirements to process and functional requirements. It helps any developer to understand at least a few things:
- Which is the value proposition of the product?
- What are the revenue streams?
- How will the product enter the market?
- What’s the highest value functionality in the product?
Once I know all this, it’s easy to understand the product as a whole, from business to functionalities. The development process should always change and try to be the best fit for this exact context.
Community Around The Product
I prefer to have a community around the product from day 1 of development. The community can be formed of people that are interested in the application for various reasons or they can be friends with the product people or they can be random samples from the target market. In this way, you’ll learn pretty soon if you’re building something useless and the product is steered by potential customers.
Sometimes, it’s hard to convince the product people to agree with that. The typical argument is that “the users will not understand what the product does because it misses functionality [insert product owner’s favourite functionality here]”. Usually, the real reason is that it’s psychologically hard to validate your mind’s child. I try to insist and convince them to do it as soon as possible.
Roadmap
The first phase of the project is to define a roadmap with the whole team. This has a few purposes:
- Understanding the business
- Understanding the product
- Refining the requirements
- Understanding priorities
- Set achievable goals
From all the parts that I’m describing here, I think this one needs the most improvements. The discussion is usually too long, and the estimation is painful and, while I use the best estimation methods I know, it’s uncertain. However, the roadmap is important as a baseline for the next developments. Ideally, the roadmap should adjust in time, but many times it gets stuck into a business plan and becomes mandatory.
The best method for doing a roadmap that I’ve heard of, but not used yet, is to split the application into chunks of time and scope that seem reasonable, start developing and then during each chunk of time adjust the scope to fit in. This would allow skipping estimation – which is a process prone to many errors.
A more scientific way would be to make estimates for best, worst and expected case and then apply Monte Carlo simulations to predict the most probable end date for the project or for each phase. The trouble is that this requires statistical expertise and a clear mind when interpreting the results.
Some of the techniques that help doing a good roadmap are:
- Storymapping – for an easy overview of the product
- Personas – for understanding why are we building that product
- Splitting functionalities to have roughly the same size
In the end, I think there are many things to improve in this area. If you have an infallible method, please share it.
Frequent Releases
Once you know what you have to do and why, you have a community around the product and the team is strong together, the top priority is to maintain the trust. I like to do this by delivering very frequently, a new fully working feature (or story) every 2-5 days. Of course, this means we usually work on one feature at a time. (This is possible in small teams, in larger teams the Work In Progress needs to be adjusted accordingly. I prefer small teams.)
This cannot be done without some effort, but it brings a lot of value. The team needs to have in place the right infrastructure and tools for doing it. Here are a few things:
- Source Control (it should be like breathing, but I know even today teams that are not using source control)
- Clean Code
- Simple Design
- Collective Code Ownership
- Working Together (pair programming or not)
- Automatic Builds
- Automatic Tests, ideally TDD
- Easy Deployment (ideally automated)
- Database Versioning
- Easy Database Updates
- Discipline
Some of these things are related to development skills, some to using or creating the right tools, some are about removing psychological barriers. Some of them are harder to do, some of them are simpler, but all of them create the premises for sustainable pace and frequent releases.
Thinking simple, automating tests and having discipline are the most difficult obstacles I’ve encountered. This is where I come in, trying to coach people, encouraging them to practice and providing the opportunities they need for that.
Continuous Improvement
Always question how you do things. Here are some questions that I’ve heard in several teams:
- Do you really need to use the mouse?
- Do you really know your editor or IDE?
- Did you try to use Pomodoro?
- Did patterns emerge from the development? Can you use code generation to improve the development speed?
- Do we talk too much? How about writing code instead of discussing principles? What more effective methods of transfering information can we use?
- What do we need to practice?
- Is practice X helpful? Should we try/remove it?
A good time to discuss the process and the practices is during the retrospective meetings, which should be held periodically. In some teams, they happen adhoc, in other teams they are planned. I think both ways accomplish the same thing, as long as someone is always prepared to facilitate them. Actually, the adhoc meetings show that the team communicates a lot, but they may be annoying. The important thing is to timebox any adhoc discussion and try to structure it.
There’s a lot to be said, learned and practiced on how to do effective retrospectives, so I will stop here. The important thing is never stop wondering what you could do better.
In The End
This is my favourite way of working. You may find it weird or perfect. I don’t claim it fits every context, and I don’t claim it’s perfect for all environments and all products. I think that it’s best for new products and for startups, because they need to manage risks very aggressively. I also think it fits very well with the Lean Business and Customer Development models.
I hope you will find at least some interesting and helpful things in this article. Let me know what you think.
More: