More and more companies and organizations are enthusiastically adopting Agile, defining roles for each project, learning the practices, and entering the world of backlogs and burn-down charts.
However, the theoretical simplicity of Scrum is often difficult to apply in real projects. Several organizational factors (assimilation of the methodology, resistance to change, organizational culture) can turn the trip into a nightmare. Luckily, there are ways to mitigate this problem.
Business value and the product owner
A technical team that doesn't know Scrum can easily be trained, producing work that becomes more and more refined over time. On the other hand, the ScrumMaster must be someone who knows the methodology from the start, who can become the mainstay of the process.
What happens to the product owner? The choice and performance of a PO who is new to Agile can be an intricate issue in any organization. Once trained, this person can understand the methodology and its needs. But there are often practical issues that set off alarms about how he or she is handling the job.
Let's look at some common situations:
Scenario #1: The project begins, but the PO prioritized requirements wrongly, due to a misreading of business value. The team, which relies on the prioritization made by the PO, including the acceptance criteria of the stories selected, agrees to them in Sprint 1. In the sprint review, the PO gets what was asked for. However, the rest of the stakeholders (including the sponsor) don't accept what has been done, since those weren't priority requirements, and they begin to think that the whole sprint was a waste of time.
- Example: In the first sprint, the PO chooses to implement the functionality of the system login, instead of other features that have greater value for stakeholders.
Scenario #2: The PO suggests, and the team agrees to develop, requirements that are valid during the sprint. But it's likely that, due to various factors, they will need to be modified very soon after.
- Example: Getting a bank loan approved currently requires that the applicant meet criteria A, B, and C. It's generally known that, within a month, those criteria will be D, E, and F. However, the PO asks for a user story based on criteria A, B, and C — thus generating future costs of modifying the functionality, costs that could have been avoided by waiting another month. In short, it happens that there are key requirements for which the expected date of completion (and thus the time of obtaining business value) generates extra development costs.
What was the common denominator in both instances? The PO prioritized incorrectly. Often when a PO is new, prioritizing business value is difficult, and his or her decisions don't achieve the short-term business value expected.
Business value and the team
To counter such situations, one can consider alternatives:
- PO training: The PO can be trained to improve decision making. The risk here is that the team can "spend" several sprints before the PO truly begins to understand how to make effective decisions.
- An external PO: The organization can bring in a PO from outside, one who has experience in similar projects. The risk here is that the PO won't have knowledge of the issues specific to this project.
- The ideal: Promote, as much as possible and as far as possible, a greater involvement of the entire Scrum team on aspects of the business.
If a team knows the key business processes and understands the expectations of stakeholders for each of these processes, it can do much more to help the PO during the sprint planning session, specifying user stories and visualizing and understanding the technical implications behind each requirement.
While the PO's decision making will improve with the passage of the sprints, having the team involved in the problem domain from the very start speeds the delivery of value. The team can work during the sprint planning sessions as a generator of counter-questions, probing each requirement and encouraging the PO to detail the requirements — or to delete, integrate, or reprioritize them.
A team that's wholly involved in the business does more than accelerate the delivery of business value. Such a team is more productive, knowing the full workings of the business in which its developments are implemented. In Scenario #2, for example, it's much more valuable to have a team that knows the levels of complexity that revolve around the loan approval process than to have a team that ignores this information or discovers it over the course of several sprints.
For projects implemented in organizations with a rookie PO, the possibility of having a team with expertise in the problem domain increases the likelihood of getting real business value from the earlier sprints. In mature Agile organizations, teams that know the business will encourage a synergy with the PO, and everyone will understand more quickly the acceptance criteria of each user story, as well as any hidden risks.
At the start of the project, we can engage the Scrum team in the business by working through two stages:
- Select for the team those who have worked with or know well the business aspects that will be implemented in software.
- Use knowledge-transfer sessions for all the various stakeholders, explaining the main problems to be solved, the agreed-upon success criteria, the priorities of the stakeholders, and so forth. The development team should be part of these sessions. The sprint planning session is the most appropriate time for this knowledge transfer, including an analysis of the upcoming user stories.
In short, developing an ever-growing knowledge of the domain across the entire Scrum team enables and encourages it to become a truly business-oriented team.<