t September's Scrum User Group meeting, we split into six workgroups of about six people each. Our goal: discuss issues outside our immediate sphere of control — the kinds of problems that don’t usually make it into a retrospective because they’re considered “out of scope.”That said, I’ve seen most of these issues pop up in my own team retrospectives over the years.
Identifying the Problems
The first half of the session was devoted to surfacing pain points. Each group wrote their issues on cards, which were then displayed for everyone to read.
Here’s what struck me: the problems were remarkably similar. In fact, when it came time to choose a card to work on in a second group, I couldn’t even tell which one came from my original team. I picked one at random and joined a new group to brainstorm solutions.
The top issues we explored were:
1. Constantly Changing Requirements
Most people wanted to freeze requirements or at least funnel and manage communications more tightly.
Interestingly, the Aconex Project Manager in the room strongly opposed freezing the backlog mid-sprint. I tend to agree — I wouldn’t freeze the backlog entirely, but if sprint items changed radically, I’d consider restarting the sprint. Teams need some stability to deliver well.
My own approach is to increase stakeholder communication — not limit it — but make those conversations more concrete. That means design mockups, paper prototypes, mocked-up screens with fake data, and partially functional prototypes to align expectations early.
2. Changing Direction and Losing Focus
There’s always a tension between staying focused and staying adaptable. Personally, I’d rather lose a bit of sunk cost than deliver something nobody will use.
If stakeholders can’t provide a clear, consistent vision, I’m not afraid to roll back into the discovery phase. The biggest trap is starting to code too soon. In early inception, I prefer whiteboards, flip charts, and pen-and-paper sketches — even resisting the temptation to jump into Illustrator or Photoshop. Hand-drawn designs make it easier to build consensus without locking into premature details.
While Scrum advises against interfering with the sprint backlog mid-sprint, in practice, backlog items often evolve. The card that moves from “To Do” to “Done” may represent a slightly different task by the end of the sprint than it did at the start.
3. Interruptions
One solution that is often proposed is placing a gatekeeper between the development team and the stakeholders. Statistics and studies are often cited that show the high cost of context switching and the frequency of interruptions in the modern workplace. However the gatekeeper usually becomes a bottleneck. Communication suffers and is distorted as gatekeeper re-interprets and re-phases the information according to her understanding and experience which is often different from both the development team's and the stakeholder's. Most teams suffer problems because of lack of communication and a gatekeeper's job is to reduce communication.
Often the cost of changes and interruptions fall unevenly on the team overloading your knowledge keepers, your specialists. Shifting your highest performers to coaching and training the other members of the team will mean loss of inefficiency, productivity and poorer quality in the short to medium term. Yet failing to do so, can lead to them being overloaded, becoming bottlenecks, and risking knowledge loss when they leave.
Other Issues We Discussed
Unsurprisingly the Convenor / Moderator / Event Organiser Craig Brown picked up on the similarities in topics workgroups focused on, as well. There was a discussion at the end where the themes of the night were elaborated and possible solutions shared.Related Posts
- Lessons from Project Indigo: A Slow-Motion Train Wreck
- Making Work Actually... Flow
- No Talk, No Topic and No Notice
- Melbourne User Groups
No comments:
Post a Comment