The Scrum Pendulum

In product development advanced tooling and so-called ‘proven’ development methods can sometimes cause more problems than they solve. For instance when they distract the development team from what they should really be focussing on: the end result, the product itself. Although Scrum provides a healthy framework that minimises risk and maximises agility of the development process, I’ve seen Scrum teams completely go astray at the expense of the product. In this blog I will outline a recurring pattern I have noticed in Scrum development teams and I will share some of my ideas on how teams can keep the right focus within Scrum.

When I think about product development and Scrum, I see that the product and the development team often live in separate worlds. The world of the product is ruled by business and user goals, while the world of the development team is ruled by sprint goals. These are not the same kind of goals. For instance, a user goal could be to easily order a coffee-to-go, while a sprint goal could be to implement single sign-on. Like I said: different worlds.

During this whole process the development team is often ‘trapped’ inside their own sprint bubble.

So the development process goes something like this: During a sprint new functionality is added to the product and gets released to the market after it’s considered done. This new functionality triggers some kind of response of the business and/or the users. This response (or the lack of it) might then be translated back into new product requirements that are fed back to the development team. During this whole process the development team is often ‘trapped’ inside their own sprint bubble. They are lulled to sleep by what I call ‘the Scrum Pendulum’; the constant rhythm of the sprints and the hyper-focus on the sprint goals. Most of the time they are unaware of the effect of their work on the actual product, unaware also of the effect the product has on the business or the users. The Scrum Pendulum creates a ‘detached’ development team, that might very well be meeting its sprint goals, but has no idea whether it is moving the product in the right direction.

This means you could also regard the PO as a SPOF: a Single Point Of Failure.

Most of the time the only link between the development team and the product is the product owner (PO). The PO has a pretty crucial role in the development process; she (or he) is responsible for translating business and user goals to product requirements and also for deciding whether new functionality that has been developed is fit te be released to the market. So you can imagine that if the PO fails, the whole process will fail. This means you could also regard the PO as a SPOF: a Single Point Of Failure. And that is something I think you need to avoid in product development.

As a team you should define what ‘success’ means.

So what can a development team do to prevent the Scum Pendulum from happening? I think it is key to take a shared responsibility for the end result, the product. Even if this was not explicitly asked by your PO, manager or client. As a professional engineer, designer or tester I believe you have a responsibility that goes beyond the development team. As a team you should define what ‘success’ means: when do you think your team has delivered a good job? You might not all agree on this, which is even more reason to discuss this with your team members and create a common understanding of ‘success’. For example, for a team ‘success’ might mean a minimum of 4 stars in the App Store rating (if it is an app you are developing). It could also be something like acceptable response times during heavy traffic or a good overall product usability. It doesn’t matter what you as a team define as ‘success’, the point is that you start thinking about product quality beyond the sprint boundaries.

Defining success is a useful exercise in itself, but it becomes even more valuable when the development team measures it’s success using their own defined standard. This doesn’t need to take a lot of time or be very complex. Checking the app store rating and comments will often give a lot of insight. Also, a quick-and-dirty user test is really simple to conduct and doesn’t need a lot of preparation. The results might not be 100% representative, they do give some level of insight. Which is a lot more to go on then when the development team would forever remain inside their sprint bubble. An important last detail is of course to use the insights to learn and improve the work inside the sprints, and everybody will benefit.

Don’t let Scrum (or any other development method or tool) replace common sense.

This team’s definition and constant evaluation of it’s own success creates an ‘outer loop’ around the Scrum process that provides a backup for failing (or even non-existing) product owners. But more importantly, it prevents the team from getting too detached from the product and the world of the business and the users. Don’t let Scrum (or any other method or tool) replace common sense. And don’t hide behind your sprint commitment; product quality and success are a shared responsibility.

Want to learn more about how to avoid the pitfalls of tooling and methods in product development? I’ll be sharing my thoughts on this at the DevCon 2018 (April 12, Ede) and CodeMotion Amsterdam 2018 (May 8, Amsterdam) conferences. Or sign up for the training Product Thinking at the Luminis Academy.

Tweet about this on TwitterShare on LinkedIn

Reacties

Het e-mailadres wordt niet gepubliceerd.

*