Hyper-Communication: Scrum’s Secret Sauce

Com com communicate

Communicate communicate

Communicate communicate

Via satellite and solid state

Never never hesitate

Communicate communicate

Communicate communicate

Never never hesitate

-Pete Townshend, Communication, from the album All The Best Cowboys Have Chinese Eyes

Effective and continuous communication is the cornerstone of any high-performance team. It may be obvious, but we need good communication to do our job well.  But good communication doesn’t come for free: you have to continuously work at it.   Further, when developing software, your choice of development process can hamper or promote high levels of communication.

During our Waterfall to Agile Pilot project effort, I’ve observed that Scrum has “forced” us to dramatically communicate more, and at more more regular intervals, than we have done in the past.  Scrum forced our teams to develop a communication habit - one where where I would estimate that we communicate twice as much, if not more, than we did with our current Waterfall process.  

Why is this so?  It’s because Scrum prescribes a set of frequently repeating ceremonies (meetings) that require effective team-wide communication.  Teams that adhere to Scrum develop a work cadence, a habit of working, that fosters regular, focused communication on the work at hand.  Scrum promotes this team habit through a the following ceremonies:

• Release Planning Meeting - held at the start of a project.
• Sprint Planning Meeting - held prior to the start of a Sprint.
• Daily Scrum (stand-up) - held every day of the Sprint.
• Sprint Review - held at the end of every Sprint to demonstrate working software to the stakeholders.
• Sprint Retrospective - held after every Sprint to inspect and adapt.

Several additional conversations generally occur regularly as part of developing software guided by Scrum.  One, the subject of an earlier blog, surrounds the team agreement on what “Done” means.  Another equally important conversation occurs with the Product Owner about the Product Backlog. Called Backlog Grooming, the team works closely with the Product Owner to focus on, understand, refine, and size top priority user stories over the course of every Sprint, a “just in time” process that helps feed the next Sprint Planning Meeting.  The Scrum framework doesn’t require these conversations, but my observation is that they are regular ceremonies for most Scrum teams, and they were with our Scrum Pilot teams.

Contrasted Communication with Waterfall

Compared to Scrum, Waterfall-based software development seems lazy with regards to communication.  A majority of team communication happen up front, when the least is known about the project.  Up-front requirements, analysis, and design discussions help formulate a project plan and project schedule, then the team goes off and develops according to that plan.  Regular project status meetings, usually weekly, are held to track the project and resolve dependencies. Sometimes, in fact sometimes quite frequently in my experience, status meetings are cancelled because everyone is “heads down” working, an ironic often-used phrase - If someone is head’s down, an image comes to mind of a someone cloistered, cranking out code, only coming up for air, for a bathroom break.

During past Waterfall development efforts, I have observed situations where an engineer, working “heads down” delivering according to his own schedule, is suddenly informed that a feature he previously completed needs to be re-implemented in a substantially different way, thereby putting him unexpectedly behind schedule.   As a Project Leader I recall feeling surprised that this happened, after so much time being spent up-front identifying dependencies and coordinating task schedules.  Something slipped through the cracks, causing the delivered functionality to based on stale, incorrect information.  We simply didn’t find out that we went down the wrong path until much later in the release, a point in the project where it was more costly to fix the issue. These were situations that could have been easily avoided with just a little bit more communication with the appropriate parties, a situation much less common with Scrum.

Continuous Communication with Scrum

During two week Sprints, the Scrum Team is meeting and communicating at least once daily, with a 10% of the Sprint spent on planning, demonstrating product, and adapting and improving their process.  Further, there are daily Scrums, discussions with subject-matter expert, and design discussions and activities between team members.  In other words, plenty of opportunities where team members are  in essence, forced to communicate.

One benefit I observed during our Pilot Scrum Team effort was the impact that the Daily Scrum had on team communication.  The daily Scrum meeting frequently spawned ad hoc discussions immediately following the 15 minute stand-up.  Team members responding to the daily Scrum “3 questions” fostered additional, unplanned, clarifying discussions, just by team members actively listening to teammates.  Project questions and issues were often resolved immediately, or “just in time” rather than laying dormant until some point in the future when they would surprisingly be discovered.

To those used to Waterfall, the communication required by Scrum may seem like hyper-communication, perhaps overkill.  But ultimately it works well.  Teams quickly develop a  communication rhythm, involving Stakeholders (via Sprint Reviews), Product Owners (via the Product Backlog Grooming) and fellow team members (via the Daily Scrum).  With the Team focused on the same goal, delivering on Sprint commitments, continuous communication is the secret sauce that allows the Team to succeed.  It’s the catalyst to turning a team into a high performance team.  

Pete Townshend said it best:

“Communicate communicate, Never never hesitate”