Keeping complex topics, simple
Hello everyone, I hope this finds you well.
I work as a Scrum Master with two teams developing a software product that is unsurprisingly, complex. The technologies in use are fairly young and our development team has undergone a large learning effort to get their understanding up to speed. In doing so, I've noticed something of a paradox.
We encourage the teams to own the way they work, so they tend to demand at least some technical specifications (made by themselves or our architect who is far and away the most proficient in these newer technologies) and exhaustive Acceptance Criteria. This leads to features with immense amounts of detail that often decompose into many PBIs that serve to represent logical parts of a whole, and can fit into our 1 week Sprints.
Despite the carefully decomposed PBIs, we tend to realize we missed the mark on "big picture" architectural concepts after a while. We start to forget how the pieces come together or why we opted for this approach instead of another. It seems the more detail we add to features/PBIs, the "why are we building it this way?" can still escape the teams. It's never apparent from the start and I can never quite gauge the comprehension levels that our members are at.
I think we could benefit from more simplicity. I am wondering if this sounds like something you've encountered and hoped for some shared experiences.
Thank you,
Mike
they tend to demand at least some technical specifications (made by themselves or our architect who is far and away the most proficient in these newer technologies) and exhaustive Acceptance Criteria. This leads to features with immense amounts of detail
Do they demand the right to explore and experiment before assuming detail? With the bigger picture in mind, how keen are they to engage in validated learning?
@Ian Mitchell
I don't often see a strong demand to explore and experiment, or engage in validated learning. I think the teams feel that would be nice, but the pressures of stakeholder and Product Owner expectations automatically means there is no time to do so. As such, there is no ask and it is hard to gauge when that could be a benefit. Refinement has become sort of a compromise of "use this time to gain enough understanding".
We have begun a positive pattern of framing efforts into experiments though, and have begun a community of practice as well. Neither have really driven extreme change though.
The experience you are seeing is from waterfall projects and is one of the reasons that agile practices were introduced. The best way to address it is by building parts of the product and letting the architecture/design emerge as you do so. Will the be some re-work? Most likely yes but it is done because it is needed to deliver the value and not because you didn't think of everything up front.
Agility is the ability to adjust to conditions. A teams ability to be agile is dependent on their desire to do work, get feedback and adjust. Your organization seems to be against that based on your comments about the stakeholder and Product Owner pressure. As a Scrum Master it is your responsibility to help them understand how their behavior is counterproductive to the gains you can have by incrementally building and delivering value.
Your orignal post says
We encourage the teams to own the way they work,
Then your follow up says
but the pressures of stakeholder and Product Owner expectations automatically means there is no time to do so
Those are counter to each other and are an opportunity to you as the Scrum Master to help everyone appreciate the Scrum Framework.
@Daniel Wilhite
Thanks for your perspective, there is a fair amount there that could be applied, particularly the mindset of accepting that re-work is part of delivering value.
I see how those parts of my last two posts seem to contradict one another but I want to clarify. I think the teams feel like the pressures of stakeholder/PO expectations prevent them from experiments/validated learning in the name of progress. It's not necessarily truly representative of what's going on.
It sometimes seems that that mindset is used to avoid or defer taking on bodies of work that could be a significant effort or result in challenges. Like willfully snapping into an attitude of "I just want to keep my head down and grind out another day".
You put it well when describing a team's ability to do well. The desire to do work is definitely there, but getting feedback and adjusting is something I want to help the team embrace more.