Why Hyper Performing Teams are so Rare?

I have seen this pattern in multiple companies.   The decision is made to improve the agile process, hire agile coaches, increase the throughput of the teams.

If the desire to improve and change is not positioned at the right level of authority in the organization, this is an exercise in futility.  There can be some gains at the team level, but without an aligned concerted effort along with a process to escalate impediments, the needle will not move forward for the organization as a whole.

Transparency and alignment of vision is the most important thing to establish at the team level.   I have however encountered layers in organizations where information can stagnate and is only shared with lower levels in the organization on a need to know basis.

This is interesting, because we know that sharing vision and driving decisions to the lowest possible level in the organization speeds everything up.  However there is often the layer of "people who know things" that have a vested interest in maintaining the position of power and authority.

I recently heard world-renowned business educator and coach, Dr. Marshall Goldsmith speak about how to motivate someone who has no interest to change.  In the interview Dr. Goldsmith says he "learned from Peter Drucker that every decision in the world is made by the person who has the power to make the decision, make peace with that."

This is extremely relevant if we consider that in the above description, the layer of "people who know things" also have the power to make the decisions, it becomes very clear why hyper-performing teams are so rare.

Something is amiss in our cross team communications.

Our teams use an invitation vs. imposition approach to process.  Meaning teams can decide what process works well for them within the guardrails of the Agile Principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.

We recently had a high priority cross team initiative bubble its way to the top of the backlog for three different teams.  We decided to experiment with a Project Inception where we invited representatives from the three teams to a 1 hour meeting to hear from the PO why this is an important initiative for the business to deliver by X date, the architect reviewed the overall design and the teams asked questions and discussed which teams were doing which pieces.  The teams were asked "should we have a Scrum of Scrums for these three teams"  They answered no, lets communicate by email.

So what happened?   As the first important milestone (checkpoint meeting to validate the approach will work in the time frames needed) approached, it was not clear what the inputs would be and how the decision would be made.  So an email thread was started and ended with a functional manager taking all the inputs and creating a spreadsheet of milestones and target dates.

Teams did not pay a lot of attention to the milestone dates or to the content of the milestones.  Totally makes sense for engineers to focus on the work captured in JIRA and in the current sprint.  Teams started to express concerns for what the other teams are committed to.   Why wouldn't they as there was no insight into how other teams were progressing.

With the best of intentions the servant leaders in the organization were actually enabling the teams to NOT communicate the appropriate level of detail around the work at hand.  Teams focused on the work in their backlogs and sprints and left the cross team dependencies to be tracked and worried about by architects, managers, and scrum masters.

This is not a great model to scale, and it causes inefficient and extra communication.  A scrum of scrums allows for a light weight way to have the right conversations with the right people and removes the layer of  abstraction added when we start talking milestones that comprise multiple JIRA stories.  The devil is in the details here, and the people doing the work are best suited to discuss these details.

We will start a scrum of scrums next week.