Is Scrum Hurting Your Agility?

By Chris Lukassen & Sjoerd Kranendonk, originally published on Scrum.org

By now, most organizations are using Scrum, however, many of them feel like the agility of their organization has degraded, and they might be right! Often, using Scrum starts out as a way to improve development efforts coordinated within an IT division or department, but that is not the most effective organization structure to potentially get maximum benefit from Scrum. Inclusive Scrum is about looking at the full value chain and organizing your Product development effort around that. Whereas low agility Scrum might actually hurt your agility.

Three symptoms that indicate low-agility Scrum

Most of the time this means your Scrum Teams are exclusively made up of members of the IT department.

1. Your Scrum Teams have a Definition of Ready that demands a full ‘design’ before an item can be planned in the Sprint.
2. After your Scrum Teams deliver a backlog item as ‘Done’ it has to wait for business implementation before actually being of added value
3. Your Sprints are two weeks, but your actual time from idea to validation is over two months

Sound familiar? As a result many in “the business” just shrug when you mention Scrum, to them little has changed. Apart from teams making more noise and a ludicrous of wall decoration in the shape of self adhesive colorful square pieces paper, little has changed.

Three reasons why you should look at the full value chain (business agility)

1. RESPONSIVENESS — The ability to create real cross-functional teams minimizes handovers, queues and wait times. Your Time to Learn will potentially shrink to less than your Sprint length, increasing agility and reducing risk.
2. QUALITY OF FEEDBACK — These teams can take true ownership of the problem-solution fit as they can talk to and validate against actual users and customers. The quality & fidelity of feedback goes up because distance is minimized. Time wise: less time between each step in the process and thus less time between decision and validation (feedback). Distance wise: Less distance between decider/builder/consumer; less handovers, less knowledge lost in translation. Both reduced time and reduced distance increase the quality of feedback and potentially the amount of knowledge. Solving customer problems is about feeling empathy and seeing the pain of the customer — the difference between first hand feedback and reading about a user’s actions in a Jira ticket is mind boggling. Additional benefits are highly motivated teams as they now experience the impact of their work instead of just get reports about it.
3. VALUE STEERING — Only when the full value chain is taken into account can short and long term decisions be made about investments and potential returns. Only when the full cost of an investment (spending time on a Backlog Item) per time unit can be known, can we truly make the best possible decisions on what to invest in next. Where to place our educated bets.

Case Study: UX in Scrum

Many teams we’ve worked with have struggled with the role and place of UX (User Experience) in Scrum. When should UX work take place? Where should the UX specialist be involved? In Sprint? As part of Product Backlog Refinement? Should the UX-specialist be part of the ‘design sub-team’ working a sprint ahead to make sure the Backlog is continually refined (together with the business analyst and a shared architect)? This ‘seperate team’ pattern results in the ‘delivery sub-team’ being reduced to axe-grinding, code-wielding backlog lumberjacks (programmers & testers), do we want this? Or could the UX specialist be part of a self-organizing Scrum Team, as part of the Development Team, working closely with their development co-teamies, a Product Owner (if present) and Stakeholders?

As with any other part of the product development process, we should try to apply the UX tools of the trade just-in-time and with just-enough detail depending on the situation. Some research work will be part of Product Backlog Refinement, while more detailed Ux-development will be conducted in close concert with actual technical development and i.e. A/B validation can take place during the in-Sprint testing phase (or as soon after Sprint end as possible).

Let’s look at 3 approaches to research UX requirements

1. Research outside of the Scrum Team
2. Research as part of Backlog Refinement (before items are planned)
3. In Sprint Research

1. Research outside of the Scrum Team

A common scenario is where UX research is done outside of the Scrum Team, or at least outside of the Development Team. UX experts engage with (potential) customers to discover why they should be using the product. What “job” is the product hired to do? These engagements often reveal interesting insights in the world of the user, recurring patterns, filters, assumptions and biases. This type of research is done by talking to the customers or even better; observing customers to build empathy and really engage in their perspective.

By separating the UX research from the implementation, most of this “warm”, experiential information gets lost in translation during the handover. By compressing several days of interaction and observation into a Backlog Refinement or capturing it in written documentation, this loss is inevitable. Even worse, when this information sits in the Backlog for a longer period of time until it is acted upon, the data has turned stale and possibly is no longer the most accurate description of the customer’s needs. Through these handovers and longer time between research and implementation, this approach has a very low ability to adapt or profit from emerging insights.

The Sprint Review has UX as a stakeholder to provide feedback to the Scrum Team on how they interpreted their findings and analysis of customer needs. Based on the Product Increment shown, the UX specialist can design and conduct further research that feeds back in the Product Backlog for at least one Sprint later. The distance between initial research and (UX) feedback is about 3–4 Sprints at a minimum hence fidelity & quality are low. The focus is mostly on how much the current Product Increment is different from what the user actually wants/needs.

2. Research as part of Backlog Refinement

Much of the waste of handovers can be reduced if research done by members of Scrum Team. The fewer the handovers, the closer to actual development in both time and communication distance. Still, the separation of development and research leads to small handovers and wait times for instance with extra questions and emerging insights.

Sprint Review is with real users providing feedback on slightly adapted versions of test designs and recent interpretations of their previous responses. Distance between initial research and user feedback is at least one Sprint, mostly two or more. Fidelity is ok. Focus is mostly on refining the Product Backlog to increase usability and value based on the working product.

3. In-Sprint Research

As we say in Dutch, ‘zit dicht op de bal’ (keep the ball close). This means that not only can the actual development team be involved in the research, potentially the research is part of actual development, so the subjects (stakeholders) partaking in the research are on-hand in the Sprint and emerging insights can immediately be retested or collaborated on as they pop up. No handovers and little to no wait time when adapting from emerging insights.

Sprint Review is with real users working on innovations and improvements in unrealized value, since the features delivered have already (partially) been proven to fit customer needs and adjusted during development. Distance between research and user feedback is between a day and a few Sprints. Mostly within one Sprint. Fidelity is high as adjustments to better fit user needs were mostly already made within the Sprint. Focus is almost exclusively on next steps.

Conclusion: optimize the whole with Inclusive Scrum

Scrum doesn’t solve your problem, or as Ken Schwaber once explained: “Scrum is like your mother in-law; very good in pointing out your mistakes.” Many organizations feel like Scrum slowed them down, because it exposes problems that have long been hidden. By applying an “Inclusive Scrum” mindset, the whole of the system — including UX — is optimized for complex work, not just the development.

How is your team doing? Where can you start the discussion around better collaboration and improving flow & quality? Do you need help? Let us know in the comments!

Want to know more?

This article is a collaboration effort. It was conspired, developed and written by Chris Lukassen & Sjoerd Kranendonk, two Professional Scrum Trainers with a love for great products and the people developing them. In our work we often encounter organizations and teams that struggle with Scrum as a value maximization framework. Mostly this boils down to Scrum Teams being sub-optimally aligned with the actual Product and parts of the process still being done in a waterfall mindset. If this sounds familiar, please feel free to comment below or contact us and we will be glad to help.

References

Originally published at sjoerdly.com.