Nothing beats the feeling of presenting a brand new, beautiful and functional user interface for the first time – except for the realization that there is no plan to actually make it available for real users.
Tech companies adopted Scrum as a way to deliver on the Agile promise of fast, incremental value. There is a clear product goal that everyone in the team strives to accomplish during the designated sprint time. When working software is delivered frequently, everyone is happy. The sprint review is a success story, progress is praised, people engage in self-congratulating behavior that keeps morale high. It feels like being in a cozy room with padded walls covered in golden glitter – we did it folks, it works!
But who is paying for the golden walls? The first sentence of the Agile manifesto contains the answer – our highest priority is to satisfy the customer. However, on many occasions, our beautiful working software is not actually available to those who can take advantage of it for purposes other than self-gratification, for multiple reasons:
- It’s shielded by a complex provisioning layer that requires the intervention of professional services teams
- It lacks discoverability, meaning that although users have access to it, they will never find it (unless someone guides them)
- It replaces another existing product or feature and there is no migration plan
- It’s not scalable to the point that you can actually roll it out to a user base that is large enough to provide relevant feedback
- More generally, it lacks 3 out of the 4 marketing Ps – the product works, but there is no price (how does it fit our pricing strategy?), no promotion (how is it going to be communicated?) and no place (how is going to be distributed among consumers – or users)
For some reason, this is rarely a cause of concern for scrum team members – and I am not just referring to product owners (or product managers, considered a broader function), although that sort of attitude is even harder to process when coming from folks in those roles.
Is it because we think this is always someone else’s responsibility? Are we afraid to break the glass into the outside world, where people (aka customers) are not always super nice and friendly? Do we actually enjoy building products in a vacuum? So many questions, so little time.
Then there comes a time when the golden, padded walls start to crumble. Everyone starts to realize that there is no actual adoption, developers complain to their managers about the lack of transparency and usage data.
When management decides to shield teams from the brutality of early stage feedback and adoption numbers, they are only buying motivation for the short term. Eventually people will start questioning why the hell are they committing to deliver something within two or three weeks if real users will only be able to get their hands on the prize in half a year or more (assuming things won’t be ditched before they even get to that stage, due to strategy shifts). So let’s be honest, as this is the only way to build trust. And let’s work together to bridge the gap.