This is a guest post by Yaroslav Lazor, CEO at Railsware, who will be one of the speakers at Tash.io Talks #4 in Berlin on Tuesday, June 10. Before founding Railsware in 2006, Yaroslav co-founded Chobots and has extensive experience as a CTO and as a Java and C++ developer in several companies.
His talk is entitled ‘Building up the product: who you need and when’, and you can find more info here and reserve your free ticket here.
Starting to develop a new product is almost always exciting for a software team: a client comes in, the team reviews requirements and provides an estimate. Once the quote is approved, developers jump into the project and get started on sketches, designs, implementing features and so on.
Coincidentally, this is the point where problems begin. The issues are pretty well known to everyone: the scope is not clear, features are added/removed/postponed, the team spends excessive hours on development, the budget grows…
The result is a broken development process that is painful for both the team and the client.
Sound familiar? It is a ‘no surprise’ story that a lot of software teams and clients often find themselves in. This is undoubtedly a reason why we have so many lame apps on the market that do not ‘fly’.
There are a lot of conversations around building a product in the right way, but not so many are about scoping for effective development. Both engineers and product owners tend to get heads down into the idea realisation phase instead of sitting together and analysing what users actually need and then translating that into features and workflows that should be in the product.
As a software consultancy, we spend quite a lot of time finding the best way to dump structured info from our clients so that it can then be used to build an app that is valuable to its users. Along the way, we figured out that task-driven development doesn’t really work. Instead we switched to the benefit-driven approach and started interviewing our clients about the benefits their app should provide.
Surprisingly, in the end, we have a scenario that is much more different from the scope that we seemed to have initially.
For example, imagine your friend is asking you for a glass of water from your pond. You’re surprised, but hey, he probably knows what he’s doing, right? You might even assume that he needs this water for technical purposes. But eventually he drinks the whole glass and most likely experiences some stomach problems afterwards.
Now imagine the situation differently: you ask your friend why he wants water from the pond and discover that he is thirsty. You now understand that you can provide him with a much better solution: a glass of clear water from the tap, or even sone of that mango juice you have in your fridge. This would be a more healthy and valuable solution.
So why didn’t your friend ask about this in the first place? The answer is because he simply wasn’t aware this was an option at all.
Client behaviour is very similar. What they’re asking for is usually based on what they have already seen and experienced, but in most cases you as a professional can suggest much better ways to build the same app if you know the primary need for which it has been created.
In other words, we have to keep in mind that the real value of any software is to solve issues, bring benefits or mitigate risks – for specific people, roles, and real users. And these are the details that should be figured out before any coding is done.
The very idea of Inception is based on this. We view software as a means of solving issues.
As we define it, Inception is a powerful and extremely efficient way to clarify and shape product solution, get all the project stakeholders on the same page and inspire the team.
The stages which make up the Inception process are as follows:
Inception starts with all participants introducing themselves around the table, explaining their role and responsibilities. Using the RASCI model is our recommended approach in this case.
After the introduction, the client shows a demo of what he currently has and shares his thoughts on the product. This might be any kind of information related to the product idea: screens, diagrams, data flow charts, wireframes, etc.
Discussion of the yet-to-be-built application starts with the perspective of the consumer – who they are, what kind of issues they have and the benefits they want to receive – and then moves on to the client’s domain knowledge. Since the client is deeply involved in the topic, they have maintained the product/idea for quite a while and hold all the data related to it, so we have to get all this knowledge from them and really make sure that we understand everything correctly.
Delving deeper into context, the team then starts interviewing the client for goals (business related, etc.) and helps the client put these goals down on paper in a way that is consistent for our comprehension.
Then we move to talk through all the roles, making sure they are consistent and prioritised. The crucial ones are identified and the rest are pushed onto the next development stages. Eventually, workflows are defined for each role and screens of the most critical workflow parts are drafted.
The next Inception stage is organising everything using the MoSCoW prioritization method. It helps to arrange the client’s domain knowledge in a technical roadmap that can guide you through all the client’s requirements during the actual development process.
Finally, the set goals are put on the board and the risks are written down on paper cards (related to business, process, integration, data, technical aspects, etc.). Each card is then discussed along with the possible solutions of how these risks can be mitigated.
There are plenty of other specifics regarding the Inception process, but in the interests of brevity, I’ll just mention one of the most important.
When it comes to comprehending large amounts of details and aspects (when discussing the scope), it is quite difficult to work with text documents, even if you have a large monitor screen. It becomes much easier to understand when information is visualised and structured. This is why we use physical paper cards during Inception. Then there is the colour coding, their location on the white board and the fact that you have written the text on these cards yourself to make the information easier to remember and comprehend.
To summarise, the idea is very simple: spend some time on the scope planning before you start the actual coding and designing. These two or three days will pay off in full. Even if you decide to scope in your own way, make sure you cover issues, benefits, risks, goals and solutions while scoping. This will already make a big difference.