The day when the product changes hands from the developers to the clients is seldom an easy day.
That is the day that a random integration issue comes up, the servers start misbehaving and what otherwise worked yesterday suddenly doesn’t work today! The developers don’t particularly help the situation. The standard response is usually.
It works in my machine
The client is no better, sensing that they may have traded in their hard earned dollars for a barely functional app, emotions are guaranteed to run raw as trust goes down the drain.
In this entry, we are going to be looking at this phenomena and coming up with ways of mitigating and maybe even making this day a good day.
To start off, it’s important to understand the difference between a product that has been built right and the right product. By far the biggest risk to any development process is building the right product. If you miss out on this then the client will be disappointed no matter how efficient your process.
So how do you make sure you are building the right product? It boils down to ensuring you are building a product that solves a user problem. That is you validate the product. This lies mostly in the domain of UXers. Still, we will mention some of the basics.
How do we make sure we are building the product right? This is a matter of process. Thankfully Scrum takes care of it. In this entry, we will talk about the meetings in scrum and how they facilitate the verification of the product
Sometimes old really is gold. User surveys still remain one of the most effective and affordable ways of getting user feedback.
In your survey you want to find out the following:
- What is the problem the users are facing?
- Do they like the feature proposed to solve the problem?
- Would they be OK if the feature did not exist in the product?
The first question helps you understand if there is a valid problem you are solving. The second one helps assess the desirability of the feature. You don’t want to unnecessarily bloat your application and waste valuable developer time. The third question helps you assess if the feature is a pleaser or a must have. For example, if the results suggest that the users don’t particularly desire the feature but would be severely displeased if the feature was not there, then you have a must have. If however they really desire the feature but don’t care much if it’s not there then it is a pleaser. A lot of insight is gained this way.
User stories are a way of expressing requirements from the point of the user. See Invest in user stories By expressing the requirements in this format. It is easier for the developers who will be building out the requirement to have clarity on the purpose of it and to make the right tradeoffs.
For example a requirement expressed as “include option to send password reset link via email”” vs “As a user I want to be able to reset my password so that I can recover my account” means that the developer working on the story can be able to say provide fingerprint password reset for capable devices. An option that would not be considered in the first case but that maybe more valuable.
Also by clarifying the need, the team is forced to elucidate on why the requirement even exists in the first place.
We rarely consider the layer of abstraction that words create. Words gain meaning from cultural context. In today’s global economy, it is likely the development team and the client have different backgrounds. So when the client says build me a house she may mean she wants this
The developer’s mental model of a house maybe this
Both, of course, are right. They are all houses!
To get over this limitation, let the client sketch out what they want the app to look like. No artistic skill required. Even a rough sketch can convey an idea better than the most eloquent prose.
Clients are generally not techies. It would be easy to assume that they would not add much value to planning sessions. This assumption is wrong. While the client may not know the tasks that go into getting their stories built out, they do know the value of the stories. They thus are in charge of prioritizing them.
As the discussion on how the stories will be broken down into tasks and the effort required to build the story becomes more apparent. The client’s estimation of the stories worth may vary going either up or in some cases going down to the point where a decision is made not to build it all.
Also, the work of breaking down the story reveals the developers understanding of the story, having the client there provides an avenue for them to confirm if what they want was communicated.
Development usually happens in a natural flow, eg you first build a registration platform before a user statistics platform. This order may not be clear for developers who are not part of the domain that the client works in. By having the client in your iteration planning meeting, you get this feedback immediately.
It is tempting to want to only show the client a finished and polished product. Doing this will, however, put you in a position where any feedback that was given is expensive to incorporate back to the product.
Instead, consider “demoing” incomplete versions of the application. As long as you manage expectations, you can get very valuable feedback quite early in the process.
Despite being the most effective and easiest to implement, the daily standup faces the most resistance to adoption. A regular and frequent sync session ensure that the developers are aware of what others are working on and thus adapt accordingly.
This session also provides an avenue for integration issues to be discussed and ironed out while they are still fresh in the developer’s minds.
There we go. By implementing the practices above, I have been able to experience better demo days than was previously possible.
How do you know if you built the right product? Talk to me on my twitter @jchex or in the comment section below.