Don't Wait To Communicate
A nice short post this time to ease myself gently back into the business of blog writing in the new year. I hope everyone had a fantastic holiday season filled with as much of your chosen way of celebrating as you could handle without doing yourself lasting damage.
How many times have we seen this situation - it's standup time and the team are gathered around the board sipping their morning coffees. "I need to raise a blocker" says one of the team. "I need some help with the design and I've been stuck since lunchtime yesterday so can anyone help out this morning? I probably only need 10 minutes". The team discusses the problem, tasks are rearranged and the team works out how to get the job done. Sounds great doesn't it? But there's a problem here. Can anyone see it?
The task got stuck at lunchtime yesterday, but the issue is only being raised at standup time. That's a full half day lost. The team member has most probably moved on to another task in the meantime but since they had started that blocked task, it was probably higher priority than anything else on the board. So we have lost half a day on a high priority task. Why? Because we waited for the standup.
The standup is a great place for the team to communicate things like blockers but it shouldn't be the only time the team communicates about things like that. All that team member had to do was wander over and tap someone on the shoulder. Sure, that person may have been working on something else important and couldn't spare the time that day but most of the time a 10 minute interruption to unblock someone else is fine. If it can't be resolved then and there, then yes, by all means, bring it to the next standup. If anyone raises an issue at the standup, they should have tried to resolve it beforehand. At least two people in the team should be aware of the issue before it is raised.
It only takes a few of these half day blockages where people wait for the standup to significantly eat into a team's output. The standup is an enforced communication window. It exists to force teams that have trouble communicating to maintain a minimum level of communication. The standup is a minimum, not a maximum level of communication. If you have something to communicate, communicate it. Straight away. Don't wait for the standup.
It's the same with the other agile ceremonies. Do you have a really great idea to improve the way the team works and save everyone a bunch of time? Don't wait for the retro to raise it, rise it now. Get that improvement happening now rather than next week.
Have you finished a story? Are you waiting for the review to show the product owner? Why? Why not show them now? Get their feedback even sooner. That way you can incorporate it into this sprint and get that story really done instead of having to make a bunch of changes next sprint.
Need to re-prioritise a story in the backlog? Why wait for the backlog refinement session? Do it now.
Need to change what the team is working on because priorities have changed? Don't wait for the sprint planning session, hold a mini planning session at the standup.
The agile ceremonies exist as bare minimum communication points. They were developed so that teams, working in an environment where no-one communicated at all, had the minimum level of communication needed to be effective forced on them. They aren't the only times the team communicates. A good team should be communicating all the time. A good team should be so good at communicating that they can start to dispense with the formal ceremonies.
A lot of teams though treat the ceremonies as though they were carved into stone tablets, handed down from on high by the agile gods - "Thou shalt meet together every day at the same time and answer the three questions." They aren't. There is nothing magic about the ceremonies. They are good practice for teams that are new to agile (and therefore presumably new to communicating) to follow. Don't be constrained by them.
The agile methodologies are guidelines, not constraints. As teams mature, they move beyond those minimum requirements and start operating as a highly functioning team. Use the ceremonies as major checkpoints but much of the communication should happen real time.
Imagine a sporting team that only communicated during its half time meeting. How effective would they be? If you look at a good sporting team they are communicating all the time. They shout, they make hand signals. They don't wait. They can't wait. If they waited, the opportunity (and the game) would be lost. It's the same for agile teams.