Product development is tough. You have an endless number of features of different value, bug reports, performance issues, code debt and other important things that you have to take care. I’d like to talk about basic things that will make your development process smoother.
Minimum Viable Feature
MVP is a term everyone is familiar with these days and it’s typically is understood as a minimally acceptable version of your product that your clients will pay for. Minimum Viable Feature is an equivalent of it but on a smaller scale. Typical feature spans weeks or even months until it’s fully implemented, which makes it tough to estimate, plan and test.
We’ve discovered Hamburger method of slicing user stories (or features as we call it within our team) a few years ago. That's a method described by Gojko Adzic in his blog. The key point is that you need to select different pieces of a feature that span all slices of a hamburger, or tasks within a feature and implement them within a sprint. For example, when implementing something like comments elsewhere in your app you usually have basic functionality — a user should be able to leave a comment. This functionality spans at least frontend layer and the API layer. But if you start to add more details to the feature more things are added — mentions, being able to reply to a comment, threads, notifications, and many other things. It’s easy to get carried away and write a feature description that will easily span a few features.
But a feature like that is tough to work with for anyone in the team. It’s important to split it into multiple phases on a scoping level so that something meaningful is completed within each iteration.
You’ll always be changing your plans
One of the common issues inexperienced teams run into is ever changing plans. Plans are always subject to change, but it doesn’t mean that we shouldn’t make them. A roadmap is a strategic plan that helps you to make the right decisions, but it changes after every iteration as you learn more about your application. It’s essential to continually update the roadmap and adjust estimates every week, as the outdated roadmap is just useless.
Same applies to the work planned for a sprint. Be prepared that something unexpected will be discovered by a developer that will affect the estimate dramatically. In that case, you might want to review the feature and skip specific tasks or completely abandon it. It’s essential to have clear communication between product and development team decisions need time to be made.
Investing in feature analysis really pays off
Business analysis and scoping is typically something that is omitted in Agile teams and is considered to be part of the waterfall curse. In practice, there’s nothing more important than proper analysis done before actual implementation. Having the analyst on the team who writes down requirements for a feature is as important as working with a designer to create pleasant UX. A good analyst can uncover contradictory requirements and ask proper questions way before implementation starts, reducing the cost of change. With a written scope all that developers need to do is actual implementation. Of course, scope is always subject to change, but analyst reduces friction of changing or clarifying requirements tremendously.
Nine women can’t bear a baby in one month
Every project has deadlines, and sometimes managers try to address slipping deadlines by adding more developers to the team. Unfortunately, this often has the opposite effect. Every member added to a team has to be onboarded, that means that someone who’s already busy working on features should guide them through. Also, every developer in a team adds entropy and noise by being involved in communication, architecture design choices and code reviews.
But that’s just the beginning. Worst things happen if two developers work on the same feature. Sometimes you can’t avoid this. For example, if you have two specialized developers doing their parts, such as backend and frontend. Even in this case, there’s a lot of communication — sometimes backend forgot to do something, sometimes frontend sends unexpected data, sometimes they can’t agree on the message format. All this is fine but takes some time.
Worst case is when two or more developers are literally working on the same code it becomes a serious problem. Not only different people have different opinions on how things should be done, code is ever changing so when one developer merges his part he is supposed to resolve conflicts. Resolving conflicts takes time, leads to bugs and typically reduces developer happiness.
There always will be bugs
The number of bugs reported by the users is often thought of as a metric of code quality. But good teams are those who do a lot of QA under different circumstances and react to incidents quickly, not those who don’t make bugs. It’s important to understand that there are different levels of quality assurance — on a developer machine, on a staging server, on production. You can’t expect developers to test everything locally and make sure everything works. Make sure you have a process of testing on a staging server and fixing errors that pop up after code merge and deploy. It’s also important to deploy to production often, preferably to a small subset of users. Generally, the less often you deploy and less time you spend doing QA, the more bugs you will have.
