Football & Business

I had the good fortune to attend the Mass Technology Leadership Council (masstlc.org) Annual Meeting in Boston this week where Robert Kraft was the featured speaker. Mr Kraft turned out to be a great storyteller.  In addition to owning the New England Patriots Kraft is the CEO of The Kraft Group, which is an international paper business. He has years of pure business experience so his stories were full of interesting business-relevant anecdotes. But even when he was talking about running the New England Patriots the lessons were business-oriented and you could see that he has a strong sense of purpose and passion that he has instilled in all of his organizations.

Early into his Q&A session Mr. Kraft stated "Life is about execution, not just dreaming." 

This is true in both sports and business.  If you don't execute in sports, you lose the game. Don't execute in the playoffs? Your season is over. If you don't execute in business, you lose the deal.  Continue to not execute, you will eventually go out of business.

Though I could have listened to Kraft talk for days about the New England Patriots (his Vladimir Putin/Superbowl ring story was incredible), the business-oriented nuggets in Kraft's speech were even more interesting.  If you get a chance to hear Kraft talk, do it. He was interesting, often funny and very inspiring. 

"Life is about execution, not just dreaming" 

- Robert Kraft

Owner, New England Patriots

CEO, The Kraft Group

Scaling Scrum: The Chief Product Owner

We’ve begun our next phase of Agile transformation - scaling Scrum from single team efforts to larger multi-team projects within our organization.   As part of this phase, we’ll be building and delivering multi-product enterprise-ready offerings, requiring the coordination of many Scrum teams across many time-zones.  

Not unexpectedly, as we’ve delivered the first few product iterations from these larger efforts we’re faced with new challenges.  Among the biggest are coordinating backlogs between teams and resolving dependencies and integration issues.  Both issues are requiring a lot of additional time and effort, over and above the team-level Product Owner and Scrum Master efforts.   

In his book about scaling Scrum, titled The Enterprise and Scrum, Ken Schwaber states “The higher the level is, the harder the Product Owner’s and Scrum Master’s job is.”  This is an important point to recognize and deal with: as you expand the size and scope of a product, as you “scale up”, more work is required for those holding the key roles in Scrum. Though this is a huge challenge, there are common patterns that can be used to help.  One is the Scrum of Scrums, where one or more representatives from each Scrum team meet daily to coordinate Sprint work and Sprint dependencies.  Another pattern, one that I consider extremely important when scaling, is a Chief Product Owner.  

The Chief Product Owner is a new unofficial (to Scrum) “role” that can greatly help with scaling Scrum.  In Scrum-speak, this role is the Product Owner of the whole product.  The Chief Product Owner is a person who is the single point of accountability for the success or failure of the complete project. This person owns the overall single product-level Backlog,  and provides guidance to the group of product owners on the Scrum teams that comprise the complete effort.  The chief Product Owner uses this backlog to coordinate the work, likely in the form of sub-backlogs, between the sub-teams, through each individual team’s Product Owner.

It is important to note that this role is filled by an individual, not a committee.  Without a designated person ultimately responsible for the success or failure of the effort, there is a high risk of “death by committee”.  By identifying a Chief Product Owner you can avoid this and have one final arbiter to order work and accepting results, as Scrum dictates for individual teams.


The Product Owner role is a key role on individual Scrum Teams.  When scaling Scrum, this role takes on even more importance - the success of the entire product relies on deep understanding of the overall product backlog and careful and coordinated roll out of work to individual Scrum teams.   Like the Product Owner role on an individual Scrum team, the Chief Product Owner is a full time role, one that requires a full time focus and commitment in order to be successful.

Scrum: It’s a full-time job.

“An adequate ScrumMaster can handle two or three teams at a time...A great ScrumMaster can handle one team at a time.”

-Michael James

One of the lessons we learned early in our Scrum roll-out was that the Product Owner and Scrum Master roles required much more involvement than originally thought.  Coming from a Waterfall development environment, where releases were long in duration and milestones spread out, people in the organization were used to having key roles on multiple projects, context switching as needed.   Juggling responsibilities in a Waterfall environment seemed to work well, or at least acceptable.  Our Product Managers, for example, could own several product lines, including associated customer meetings and field interactions, and easily satisfy occasional project touch-points such as requirements definition (at the beginning of the release) and Beta and FCS duties (at the end of the release).  These project touch-points required their full-time involvement periodically, a few times a year, making it relatively easy to context-switch periodically and satisfy the needs of each effort.



With Scrum, however, things turned out a bit different.  Though we “took the training” and “read the literature” which repeatedly said the roles of Scrum Master and Product Owner were full time jobs, we weren’t true believers.  Our “muscle memory” way of working had everyone juggling multiple roles and responsibilities, it was the way we were used to working. During the course of our Agile Pilot projects, however, we got convinced pretty quickly that Scrum roles could not be part-time.

Scrum is more intensive than waterfall development.   

With frequent “potentially shippable product increments” created every 2-4 weeks,  there’s essentially a full product release at least once a month if not twice.   During our Agile pilots, our Product Managers, filling the role of Product Owners, soon realized that creating and maintaining a Product Backlog required a significant amount of time.  Every few weeks a new set of fully-defined “product requirements” need to be ready for the team for the next Sprint. Product Owners found it challenging to satisfying their Scrum PO role and concurrently complete other project work.  Our Scrum Masters, too, found themselves booked full-time, facilitating team interactions, producing Sprint Burn Down charts, working impediments, and delivering frequent product releases at regular Sprint Review.  Team members, often with other-project responsibilities, found themselves spending more time delivering on Sprint Goals, often at the expense of their other responsibilities.  

As we scale Scrum within the organization, we’ve (obviously!) needed to identify new Scrum Masters and Product Owners.  We’ve held fast to the one project per Scrum Master recommendation. Identifying new dedicated Scrum Masters has been fairly easy - our Pilot teams was that the efforts produced several Scrum Master candidates, a nice side-benefit!   Finding full-time Product Owners for each team was more challenging.  Because we’re applying Scrum to large multi-team projects, our mapping of Product Manager positions to Product Owners simply didn’t scale.    Our solution was to look to our lead engineers. Most of our new teams have technical Product Owners, usually Software Architects, and they are dedicated full-time to the team.  Product Managers are involved at either a co-Product Owner (in an outward facing role) or at a higher level in the project effort, via a Product Council-type role that involves them as stakeholders.  

I expect our organization to fine tune (via inspect and adapt) these non-Scrum roles as we mature in our Agility.  But regardless of the organizational “noise” around the Scrum Teams, I believe that participation at the Scrum Team-level will continue to require full-time effort from all members in order to be successful.

Velocity and Release Planning

“An iterative, story-driven process makes it easy to fix a date but difficult to fix what will be included by a given date.”

-Mike Cohn, User Stories Applied

Predicting a release date is often a big challenge in software development, particularly Waterfall-type development projects.  Actually, making the prediction is the easy part - predicting accurately is the challenge.  

Assuming a team is in place, determining when a software project will be released is a function of time, features, and quality.  Further, by fixing any one of those variables, you can can expect to, perhaps greatly,  impact the other two.   

As my organization transitions from Waterfall to Agile, we’re challenged with how to accurately perform Agile product release planning and reflect that back to the wider (non-development) organization.   With the “old way of doing things” there is a general comfort with holding a written plan, a project schedule, even if everyone knows that plan has a high probability of being wrong.

Waterfall Release Planning

In today’s hyper-competitive business world, a product release date is often defined by company management.  This is true in both Agile and Waterfall development environments.  In my experience, it’s been true for most, if not all, of the large waterfall development project that I have been a part of the past 25 years.

Once a release date has been set and communicated to the field, the development team heroically tries to meet that date.  If you are a lucky engineer, your management team gives you some time to flesh out requirements, create a architecture and design documents, define tasks and a schedule, and ultimately allow your data to influence the release schedule.  Even with that luxury, challenges abound to meet this “defined up front” schedule: as you implement more, you learn more, the work remaining becomes more defined, ultimately impacting the project release date - often it is later than originally predicted, rarely is it earlier.   

When faced with more work remaining than time allowed, a hard delivery date often forces you to cut features to meet the schedule.  The problem is that features may be partially implemented (waste) and often most of the remaining work is quality assurance testing.  In those situations, the choice becomes tougher: slip the schedule or reduce testing (and thus quality).  It turns into a Kobayashi Maru (“no win”, for those who aren’t Star Trek fans) situation.  We’ve all been there, and we all bear the battle scars.

Release planning is different with Scrum

With a Scrum Team producing potentially shippable code with every Sprint iteration, we’ve essentially fixed one of the release planning variables: quality.  In order for a product to be potentially shippable, it must have a level of customer-expected quality.  This leaves the organization two remaining adjustable dials: time and features.  


The amount of completed work (user stories “done”) a Scrum team can deliver in a given iteration is identified as the team’s Velocity.  Velocity is a key metric for release planning - it quantifies the capacity of the team for a Sprint.  Knowing a team’s velocity, coupled with a sized Product Backlog, the Product Owner can get an approximate idea of what features will be delivered by a specific time.   [You can reference numerous books and blogs for further details about story sizing and velocity, with Mike Cohn’s User Stories Applied, and  Agile Estimating and Planning being two of the more highly regarded references.]

Time-based Release Planning

If you’re organization is going to mandate a release date, you must readily accept that you won’t initially know the full feature set that will be delivered on that date.  But, by using the Scrum Team’s velocity, you can get an approximate idea of the feature set.  

Knowing a team’s velocity, how much work a team can get “done” in a Sprint, will help predict how much of product backlog can be implemented by the time the mandated product release date arrives.   By using the team’s velocity, the number of sprints that can be completed before the release date can be computed (remember, Sprints are of fixed time).  Applying that to the backlog can give you a very good idea of what features will make the release and what are on the “bubble”.  Usually this is better than good enough.   Features that are on the delivery bubble, those that may or may not make the release, are much lower in priority than those that will be fully “done” prior to the release date.  These backlog items shouldn’t be make or break features, and can be saved for a subsequent release.

When the surrounding corporate environment is not Agile and you need to publish a future product feature list to a wider audience, the majority of the the features on the Backlog that comfortably fit into the velocity capacity can be communicated outward, setting expectations and enabling the coordination of public release-type activities such as PR, marketing, etc.

Feature-based Release Planning

If you product must complete a specific set of features before you can release, then using team Velocity can help you predict your release date.  By using the team’s velocity, and mapping it to the product backlog, you can predict many sprints it will take to complete the required backlog items.   Release burndown charts are great at visualizing how much work is remaining in a release and identifying how many sprints are likely required before you can ship the product.

Because the team velocity can vary from sprint to sprint a firmed up average, team velocity usually isn’t firmed up until the team achieves a regular Sprint cadence - usually 3 or so sprints.  To determine a release date early on, you will need to consider velocity variability.  Mapping out a release date window can be computed by using the predicted best velocity and predicted worse velocity, which will give you a release window as your target release date.  As more sprints are delivered, this release window can be refined.  

Product Backlog Considerations

The Product Backlog is a living entity.  As you learn more about your customer needs, and hopefully get customer feedback on early sprints, you likely will add and remove items as well as re-prioritize items, all of which can effect your release date.  Additionally, the team velocity likely will fluctuate - but with short (2-4 week) sprints, you will have your finger on the pulse, having up-to-date velocity measures as well as average and historical values.  Using this data, you can frequently map out how many sprints will be required to deliver true product value to the market.


Continuous Planning

Release planning within Scrum doesn’t happen just once, at the beginning of the release, as it does with waterfall development.  The release plan is evaluated and possibly adjusted at the end of every iteration, as more is known and team velocity is refined.  Realize that it may not be the project release date that is adjusted, rather it could be the work that will be delivered.  As more potentially shippable product increments are delivered by the team, the organization has  the opportunity to gather customer feedback, and use that feedback to influence (to add or remove items from) the product backlog.  Doing so may change your release date, or the features ultimately delivered.  Further, performing this activity regularly, doing frequent customer validation and backlog/release grooming, gives the organization the opportunity to deliver a product that better matches market needs.

For my organization, Scrum has given us a higher level of confidence with our release planning.  This year we’re part of a new corporate initiative requires that requires product by the end of 2011.  After the recent success of our Scrum pilots, we have a new found confidence in our planning such that we believe we’ll be able to deliver working shippable product by that deadline by using Scrum.  We can’t currently say what the complete functionality set will be with absolute certainty, however, but that’s okay.  We know we’ll deliver shippable product by the end of the year.

Ship it! - Scrum’s “Potentially Shippable” Product Increment

One of the problems many teams struggle with when beginning to adopt Scrum is delivering potentially shippable increments of product at the end of every Sprint.  Delivering a potentially shippable increment of code is one of the fundamental concepts of Scrum - a requirement that is specifically called out in the Scrum Guide:

“Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable...the increment must be a complete slice of the product. It must be “done.” Each increment should be additive to all prior increments and thoroughly tested, ensuring that all increments work together.”

Scrum Guide: http://www.scrum.org/scrumguideenglish/

Producing a potentially shippable product in 2 or 4 weeks involves a semi-radical mindset change to those used to building software in a traditional Waterfall-like manner.  Making this mindset shift enables an organization to experience numerous benefits and efficiencies, from the ability to deliver software to customers at more frequent intervals, to being able to strategically pivot product direction while minimizing waste.

At first, most teams new to Scrum struggle with delivering software in this manner - our Agile Pilot teams were no different.  The first challenge was integrating cross-functional team members, development, doc, QA, into a new team.  Agreeing on the definition of “Done” helped with this.  Another hurdle involved Product Backlog user stories - often user stories were too large, or difficult to break down into small single feature product slices.  Backlog grooming quickly rose in importance for most teams.  Team member specialization also presented challenges. Tensions around creating a shippable product often developes when team members such as QA and documentation have to complete there work the last day or two during the Sprint.  At present this is our biggest challenge - the teams are still learning and adapting, as is the organization as a whole.

Over the course of a handful of sprints the Pilot teams put in a valiant effort, overcoming many of these challenges.  Teams adjusted the way they worked, via Sprint Retrospectives, to address some of these concerns, and ended up producing high quality software and documentation.  One of the Pilot teams even released the results of one of their early Sprints to customers via a Technical Preview (TP) pre-release program.

Last week I was fortunate enough to attend an executive briefing scheduled with one of our customers who has been participating in this Technical Preview program.  As part of this TP, we supplied a documented script that the customers should follow; this script defined the usage pattern we used as a final test before releasing the product to this program.  The customer, being a self-proclaimed power user, told us that he followed the script, but really wanted to see what else the product offered.  He strayed off script and began investigating how the tool’s functionality could help his applications.  I think a few jaws dropped in the meeting, as some were expecting the worse - straying off the prescribed path was an “all bets are off” scenario for pre-released software in our Waterfall development environment.  Surprisingly to most, the unexpected happened:  The customer told us that the software had all the functionality he expected and had very few bugs.  Further, he stated that he was able to use the product to map how he would make use of it in his enterprise. He did mentioned, in a proud tone, that he found 2 or 3 bugs that he wanted to demonstrate to us. Sure enough, he brought up the software and proceeded to demonstrate how he used the software, along the way, attempting to show two issues he found.  His subsequent focus on the issues, one minor (a browser-related issue), the other an issue he was unable to reproduce (but did note there was an easy work-around), didn’t minimized his earlier claim, now stuck in my mind:  “the product had all the functionality [he] needed”!

It’s always great to see a Customer demo your software to you. Our Product Owner had an opportunity to gather real-world product feedback from a power-user customer, one who personally demonstrated how he would use our pre-pre-Alpha, but potentially shippable, version of our product.   This customer’s feedback subsequently influenced our product backlog for an upcoming sprint - agility in action!

During this whole “customer demonstrating our product to us” segment of the meeting, I was smiling proudly: this was software that we, in comparison to a Waterfall-type release, had essentially “tossed out there”: no code freezes, no bug triage, no end-game QA bug fix cycle.  It was product that was the Sprint 4 output from our new Pilot Scrum Team, software that the Team had deemed “potentially shippable”.  And it was just that: potentially shippable.  

Agile Pilot Teams - A Retrospective

Early in our journey from Waterfall development to Agile, we identify 4 pilot projects, each from different product lines, to test the Agile waters via “Pilot Projects”.   Even though there were several Agile champions (myself included) in the organization, we decided to take a “let’s try it before we buy it” approach to Agile.  Each of the pilot teams consisted of cross-functional team members. Our strategy was to formally train members of the 4 pilot teams as Certified ScrumMasters, Certified Product Owners or Certified Scrum Developers.  

As the overseeing Unified Development Process (UDP) Committee, we identified our in-house Agile champions as coaches for each team, but ultimately each team had to self-organize, inspect and adapt, and deliver on their commitments following the Scrum framework.  

Once trained, we sent the teams off to build software for a minimum of three two-week long sprints.

When it was all over...
When all Pilot teams completed their the minimum 3 Sprints we conducted a multi-team retrospective.  Those of us that were coaching the pilot teams had already observed many of the positives and negatives identified during this retrospective, some of which are recounted in this blog.  However, it was very heartening to hear similar sentiments expressed nearly unanimously by all Pilot teams.

What Worked Well?
The teams enthusiastically offered up a long list of “what worked”, but the first two items mentioned are worth noting here.  Improved communication was unanimously agreed upon by all teams as the top benefit they experienced during the pilot.  [Ironically, this conversation occurred mere hours after I had written my “Hyper-Communication: Scrum’s Secret Sauce” blog!  I was mentally smiling as they spoke.]  The teams stated that the Scrum framework fostered communication, mentioning that the cross-functional teams, specifically the inclusion of QA engineers, was extremely beneficial.  Also singled out was the Product Backlog Grooming - it was a key team communication activity valued by all.

It’s interesting to note that the Waterfall process used in our Product Group does not prohibited nor dissuade people from communicating with others when developing software.  I believe it is simply that often there is no immediacy to engage in these types of discussions in a Waterfall environment.  The Waterfall process does not foster this type of regular extended team communication. For example, there is often a buffer, perhaps a project leader or supervisor between Product Management and the developers writing the software.  Further, with Waterfall, the “are we writing the correct software” check-point is often distant, in terms of time, from the requirements definition, occurring at Beta perhaps, where as Scrum’s are much more frequent, occurring at the end of every Sprint.

The second notable benefit brought up was the feeling of empowerment experienced by the participants in the pilot.   This one is interesting and caught me a bit by surprise as it is hard to visually identify.  The teams actually appreciated the complete ownership, not only for the delivery of working product, but for user story refinement, quality, documentation, etc. Success (or failure) was almost completely within their, the Team’s, control, and they found this to be extremely valued.

In Waterfall software development, most teams are used to be being led.  Often a project leader or project manager is identified as the chief point of contact.  That person manages the schedule, works dependencies, reports status for the team, and often runs interference, allowing the team members work on their individual tasks with minimal interruption.  Teams are typically not cross-functional and often the onus of communication is often on the individuals themselves.

Scrum’s emphasis on “The Team” was appreciated by all of our pilot teams.  The team members valued the empowerment and responsibility - essentially the  confidence the organization put in them.  As management, of which I am a part, it seems we really did succeed in stepping back and letting the Pilot teams operate without traditional management meddling.

What Didn’t Work Well?
The Pilot teams also brought up a healthy list of things that didn’t work.  Being a new process that most had just learned, coupled with introducing Agile in a Waterfall environment, a long list of issues was not unexpected.

The number one issue the teams noted was that most Product Owners did not spend enough time with the team.   For our Pilots, we identified Product Managers as Product Owners for each team.  Because our Product Managers were few in numbers and had many other responsibilities most ended up being only part-time members of the teams.  The teams felt this strongly that the Product Owners needed to participate more as a full-time team member, attending the daily Scrum as well as spending more time creating and refining the Product Backlog and working with the Team on backlog grooming.  

This issue was a direct result of mapping a Waterfall role into a Scrum role.  In Waterfall, a Product Manager can manage many projects, defining the requirements up front, then moving on to the next project’s requirements.  Not so with Scrum, where the Product Owner is a full-time job, a fact that became obvious very quickly for most Pilot teams.  It’s clear going forward that our organization needs to re-examine our staffing and role needs, as well as acknowledge that some existing roles won’t readily map into new roles within Agile.

One other notable “didn’t work well” issue was the handling of customer escalations.  With a large customer base, an escalation can come in and derail the team’s Sprint commitment.  This situation can and does occur during our Waterfall-run projects as well.  It’s an issue that likely will need an organizational solution, as it introduces tension between specialized engineers developing new software in time-boxed sprints and the need to support a significant and demanding and customer base.

We thought it was all over, but it wasn’t...
Much to my delight, all four of our Pilot Teams decided on their own to continue with Scrum beyond their initial 3-sprint Pilot.  One Team is now on Sprint 7, and has successfully released the output of an earlier Sprint to customers in a Technology Preview program.

Beyond the team enthusiasm and product successes, the biggest outcome of our Pilot effort was that we created new Agile champions.  Each Pilot Team has several members who have been positively promoting their Pilot Team experience.  As we roll out Agile to more teams, we’ll leveraging these new Agile advocates as mentors and champions to assist with our organization Agile Transformation.  To me, that was the biggest “what worked well?” of all.

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”