The "Real" Work
The "Real" Work
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
When can we finish with all these meetings and get some real work done?!
I can certainly sympathize with that feeling... it seems like teams are meeting constantly:
- Daily Standups
- Sprint Planning Parts 1 & 2
- Sprint Review
- Backlog Refinement
- Design Workshops
- Release Planning
Those are typical meetings that occur in the single-team, single-backlog version of Scrum. If you are working in a scaled environment with multiple teams, you likely need to add:
- Joint Backlog Refinement
- Joint Retrospective
- Scrum of Scrums for team coordination
That's a lot of meeting, and a lot of time not doing real work. Or is it?
Ron Jeffries had an e-mail signature line that I saw years ago that really struck me:
We accomplish what we understand. If we are to accomplish something together, we need to understand it together.
In other words, it's the shared understanding of the work to be performed that is critical to the success of that work. Every requirements process in existence, from binders full of the system shall's to a business person sitting beside a developer giving instructions, seeks to achieve the same goal - a shared understanding of the work to be done.
As this video shows, a shared understanding is critical to success:
While the video is intended to be humorous, how many examples of misinterpreted requirements can you remember from previous projects? The words may have been clearly written in a document, but what the author of the requirement meant was "see if he's still alive" while the development team interpreted the requirement to mean "please ensure he's dead". Even when the requirement is stated face-to-face with a representative from the team, that person may take his misinterpretation back to the team.
In most organizations in which I've coached, the transition to an Agile process meant that all team members were now involved in the meetings mentioned above, rather than a select few. There are some exceptions, such as the joint meetings held in the scaled model of Scrum, but the general rule is to be much more inclusive about who attends meetings rather than limiting attendance to more senior people for example.
On the face of it, this inclusive nature seems rather wasteful. Where you once had a weekly team meeting for an hour or two, you now have daily meetings that can take 15 minutes each plus follow-on discussions. Where you once had perhaps two team members attending requirements meetings of a few hours, you may now have an entire team. So, yes, the amount of time spent per person in meetings does increase.
The benefit of that increase is that everyone is hearing the same message, contributing to the same discussions, and moving closer to a shared understanding of the work - shared not only within the development team, but with the business for whom the work is being done. By doing so, the risk of misinterpretation drops significantly and the probability of getting the work right the first time increases. These prevent costly rework when a mistake is discovered, and even avoid unnecessary work altogether when the discussion leading to the shared understanding uncovers simpler ways to accomplish the business goal.
In other words, those meetings are real work.
Published at DZone with permission of Dave Rooney , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.