Missing an amigo?
Anti-patterns in BDD
Working with BDD can be a great way to increase collaboration and conversation between team members. It can help teams with their shared understanding and keep teams on track with their delivery. However, there can be challenges in BDD and to succeed with BDD requires patience, teamwork and feedback — both on what works and what doesn’t work for your team.
Working as a team can be fraught with anti-patterns, whether they’re caused by biases, losing sight of common goals, or relying too heavily on tooling. In this series, we are looking at some of these anti-patterns, uncovering what they look like, how they are formed, and how they can be avoided.
In today’s article we’ll dig deeper into the anti-pattern of teams lacking direction in their collaborative sessions.
Missing an amigo?
Imagine you have a team of developers and testers working hard on your product. They have decided to adopt BDD and are trying to collaborate on user stories before development. However, they’re struggling because they are missing an additional person in the conversation, the product owner.
The team can’t agree on what should be delivered, conversations are missed, delivery is suffering from scope creep and, when it comes to demo time, the product owner isn’t satisfied with what is being delivered. Does “That’s not what I wanted” sound familiar?
Issues like these consume time, negatively impact team morale and, after a while, the team will give up on BDD and fall back into old patterns of not collaborating or sharing information with one another.
Why is it an anti-pattern when the product owner is missing?
Whilst development and testing contribute valuable insights into why and how are we going to deliver something, someone needs to be responsible for:
- sharing the vision
- setting a direction
- deciding on what is or isn’t required
This is typically the role of the product owner, and if a product owner is not available for collaborative sessions, then teams will struggle with the lack of direction from the product owner. Without the product owner in the session, the other members of the agile team are unable to fulfil important activities such as:
- share what they’re looking for
- steer the conversations
- have a final say on decisions and questions
What’s the solution?
There are multiple reasons for a product owner’s reduced involvement in the collaborative process, such as:
- a lack of willingness to join a team discussions
- a lack of time or availability
- a lack of confidence in engaging a technical team
If there is a general lack of interest in getting involved with collaborative sessions, one solution is to have a conversation with the product owner around the difficulties they face with their team’s delivery does not meeting their expectations. Explaining to the product owner the value of having a semi-formal conversation around their requirements, can help the team deliver more of what they want the first time around.
If the issue is availability, then there a multiple things that can be done. Whilst three amigo sessions are a great, informal way to have a discussion around a user story, if time is in very short supply then consider different ways to schedule conversations. Taking advantage of planning or refinement sessions as a time to discuss stories and share examples might work well, since they tend to be booked in advance and are a regular occurrence in agile teams.
You can also save time during these sessions by focusing solely on the conversation. You can defer the capturing of the conversation into Gherkin examples to after the session, and share them later with everyone to review. Alternatively, attempting to capture some examples before the discussion starts, can save time and be a good way to start the conversation.
A product owner investing time up front will reap rewards at the time of delivery, as the amount of rework will be drastically reduced. This is because a team with a clear direction and shared understanding of what is required of them, will be able to deliver what is required much faster.
Finally, some product owners are reluctant to engage with their teams because they are put off by the technical nature of the Gherkin syntax. Add to the mix the technical conversations that are usually held among technical members of an agile team, and it’s easy for a product owner to develop imposter syndrome while also trying to be an authority on what the user wants and needs.
A product owner should receive training and coaching in BDD techniques, to give them confidence and control during a discussion. When a product owner understands that Gherkin is simply an artifact of the examples captured during a conversation, and that discussions should be focused on behaviours of the product rather than on technical details, they will be much more likely to get involved.
Originally published at www.hindsightsoftware.com.
