Scrum and Innovative product development.
Hi,
As a Scrum Master thus far, my experience is mostly around adding new features to existing products.
I am now a Scrum Master for a small team dedicated to building completely new Innovative products. Our current product has a clear (although expanding) vision. We know, at least minimally, what the product should do.
The question is this. Since the product's UX is changing constantly, insofar as the team produces something 'potentially shippable' (and this for me is an interesting concept as anything potentially shippable would be for external clients and should be perfect) and in Sprint Reviews (or external user testing) the feedback can lead to a massive change in UX design - how much testing should I be coaching the team to do?
It is difficult to test. As we are building mostly happy paths, the testers are uncomfortable with little or no error handling. Sometimes they are told validation will be added later. Should this really be built in from the start? This would make functional slicing of the product extremely difficult. To produce something potentially releasable in a single sprint would probably be impossible.
The engineers question the point of covering everything with tests (or adding validation etc), since the whole thing is likely to change next sprint anyway.
How should I approach this? It seems wrong to build an admittedly ever changing product without tests, but the argument is generally 'until it actually goes out, there is not much point". For me, this will lead to a big testing phase as soon as the stakeholders say "It's great - ship it!".
Any advice gratefully received!
There are different layers to testing. While the UX may indeed change, the underlying logic should remain stable, and it is this layer that you should be developing test coverage around.
Quality should never be negotiable in Scrum. It needs to be built in to every work product from the start. I agree with your testers that a lack of exception processing is a big concern.
Keep in mind that potentially releasable does not mean that it has to be released. In theory, it can be used, but it does not need to be in a final "perfect" state.
It is the front end that I feel most uncomfortable about. The back end is covered by automated tests, which is good.
The problem is on the manual front end testing, and to some degree, the automated tests surrounding the front end. In fact, we no longer have a full time tester on the team, and trying to justify having even some testing resource for a front end that could change next sprint is difficult.
I agree about the 'potentially releasable' definition. In my previous role, we wrote software for the internal business, and anything that isn't strictly customer facing could always be potentially releasable (with the right training, discussions and managed expectation). When your customers are external 'potentially releasable' is not really potentially releasable at all. If it isn't perfect, it isn't potentially releasable. Your brand will be judged by it.
> When your customers are external 'potentially
> releasable' is not really potentially releasable
> at all. If it isn't perfect, it isn't potentially
> releasable. Your brand will be judged by it.
If you defer release until perfection, you will have a large batch of work that remains unvalidated in market conditions. It may not be as perfect as supposed. The product will represent a huge leap of faith. Moreover, the work-in-hand will have been subject to depreciation over that period, and any possible return on investment will have been deferred.
There is an art and a science to crafting a "Minimum Viable Product" which facilitates release early and often, but without putting established assets...such as a brand...at risk. The skill lies in framing an MVP as a hypothesis to be tested before a more substantial commitment is made. For example, prototypes may be evaluated in a sandboxed environment using selected customer cohorts, or very small changes may be tested on randomly selected users.
This is the Lean Startup approach. It is applicable to Scrum at scale, though it requires a Product Owner with an entrepreneurial view for it to work.