Tag Archives: Coaching

A Shallow Dive Into Chaos: Containing Chaos to Improve Agile Story Pointing

In May 1968 the U.S.S. Scorpion (SSN-589), a Skipjack-class nuclear submarine with 99 crewmembers aboard, mysteriously disappeared en route to Norfolk, VA from its North Atlantic patrol. Several months later, the U.S. Navy found its submarine in pieces on the Atlantic seabed floor. Although there are multiple theories as to what caused the crippling damage to the submarine, the U.S. Navy calls the loss of the Scorpion and her 99 crew an “unexplained catastrophic” event [1].

The initial search area stretched across 2,500 NM of Atlantic Ocean from the Scorpion’s last known position off of the Azores to its homeport in Norfolk, Virginia. Recordings from a vast array of underwater microphones reduced the search area down to 300 NM. Although technology played an important role in finding the U.S.S. Scorpion, it was the collective estimate of a group that eventually led to the discovery of the destroyed submarine. The U.S.S. Scorpion was found 400 nautical miles southwest of the Azores at a depth of 9,800 ft., a mere 220 yards from the collective estimate of the group [2].

The group of experts included submarine crew members and specialists, salvage experts, and mathematicians. Instead of having the group of experts consult with one another, Dr. John Craven, Chief Scientist of the U.S. Navy’s Special Projects Office, interviewed each expert separately and put the experts’ answers together. What’s interesting about the collective estimate is that none of the expert’s own estimates coincided with the group’s estimate—in other words, none of the individual experts picked the spot where the U.S.S. Scorpion was found.

A Quick Lesson in Chaos

According to Dave Snowden, Chaos is completely random but if you can contain it, you get innovation. You do this by separating and preventing any connection within a system. And when done properly, you can trust the results. Skunk Works projects and the Wisdom of Crowds approach made popular by James Surowiecki are great examples of how to contain Chaos [3].

Dr. Craven’s approach to finding the U.S.S. Scorpion is a controlled dive into Chaos; preventing any connections within the group, protecting against misplaced biases. Moreover, by bringing in a diverse group of experts, Dr. Craven ensured different expert perspectives were represented in the collective estimate.

To contain Chaos, three conditions must be satisfied [4]:

1. Group members should have tacit knowledge—they should have some level of expertise

2. Group members must NOT know what the other members answered

3. Group Members must NOT have a personal stake

Story Point Estimates: Taking a Shallow Dive into Chaos

Agile software development teams frequently estimate the effort and complexity of user stories found in their product and iteration backlogs. Individual team members “size” a story by assigning a Fibonacci number to a story based on their own experiences and understanding of the user story. A point consensus is not the aim but, unfortunately, is frequently coached and practiced.

To reduce cognitive biases, contain Chaos, and accelerate the story pointing process, AGLX trains and coaches clients’ software development teams to ask the product owner questions using various Red Teaming techniques, to include Liberating Structures. Once all team members are ready to assign points to the story, team members place their selected Fibonacci card or chip face down on the table.

On the “Flip” in “Ready…Flip,” team members turn their cards over and the ScrumMaster rapidly records the individual points. When all points are registered, the ScrumMaster takes the average of the points scored and assigns that number to the story (rounding to the nearest integer, if desired). No need to waste time re-pointing or trying to come to a consensus.

Example. A six-person software development team assigns the following individual points to a story.

Cards

The average is 6.5 (7 if rounding). In this example, none of the individual estimates match the group’s estimate. And, the group’s estimate is not a Fibonacci number.

In some High-Performing Organizations where psychological safety is well established, some development teams will have the team members who pointed the story with a 3 and 13 (using the example above) to present their reasoning using a complex facilitation technique—time-boxed, of course. The point behind this ritual is not to re-point the story but to have team members listen to the story outliers or mavericks for the purpose of identifying possible insights. Caution: This is an advanced technique.

Innovative and Resilient Organizations

Containing Chaos requires expert facilitation and will not happen overnight. However, simplifying your story pointing approach by not allowing consensus or team consultation (Condition 2) when it comes to story pointing is a small step to becoming an innovative and resilient organization—if that is what the organizations desires.

Although the loss of the U.S.S. Scorpion and her 99 crew was a tragedy, by sharing the story of how the collective estimate of a group of diverse experts found the submarine on the seabed floor is a great example of the power of cognitive diversity and containing Chaos.

Brian “Ponch” Rivera is a recovering naval aviator, co-founder of AGLX Consulting, LLC, and co-creator of High-Performance Teaming™ – an evidence-based, human systems solution to rapidly build and develop networks of high-performing teams. Contact Brian at brian@aglx.consulting.

[1] Sontag, Sherry; Drew, Christopher (2000). Blind Man’s Bluff: The Untold Story of American Submarine Espionage. New York:

[2] Surowiecki, James (2005). The Wisdom of Crowds. Anchor Books. pp. xv. ISBN 0-385-72170-6.

[3] Snowden, D.  KM World 2016 Keynote.  http://cognitive-edge.com/resources/slides-and-podcasts/

[4] Ibid

Share This:

Psychological Safety is Just One Piece of the Larger Puzzle – Where Google’s Project Aristotle Missed the Bigger Picture

Google recently released the results of a five-year study, known as Project Aristotle, through which they determined that the common attribute – or what Google termed “key dynamic” – which successful teams exhibited was something known as psychological safety.

Unfortunately, Google’s expensive, five-year foray into teamwork is a great example of what can happen when technologists undertake studies in team and cognitive psychology, human interaction, sociology, and complex adaptive systems (among other disciplines), and base their findings entirely on self-collected metrics and their own statistical analyses of that data. What Google found was that psychological safety is a statistically significant attribute (key dynamic) associated with high-performing teams, but unfortunately this doesn’t tell the full story or help other teams or organizations to understand what they need to do to create those same conditions in their own environments.

I certainly do not want to impugn or belittle the considerable efforts or discipline of the team conducting Google’s study. However, I might have suggested beginning with a review of existing research in some of those disciplines (teamwork, sociology, human behavior, cognitive psychology, etc.) relating to team performance and teamwork. As it turns out, there is quite a lot.

In fact, so much that today there are meta-studies covering these topics. Among other critical areas not studied by Google, team performance is directly tied to the number and quality of social interactions between team members [1], the existence of Shared Mental Models within the team, shared expectations regarding behavioral norms (what we call Known Stable Social Interfaces), as well as organizational issues such as the leadership and management culture.

Which isn’t to imply that psychological safety isn’t important; indeed it is. Amy Edmondson in her book Teaming points out that psychological safety is of critical importance to effective teams:

“An environment of psychological safety is an essential element of organizations that succeed in today’s complex and uncertain world. The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings without fear of being penalized…In corporations, hospitals, and government agencies, my research has found that interpersonal fear frequently gives rise to poor decisions and incomplete execution.” [2]

Psychological safety is important. Yet psychological safety is not a team skill. For example, we can teach a team and individual team members to communicate more effectively using certain techniques and behaviors. Similarly, we can train a team to communicate in more assertive ways. However, we cannot train teams to simply “be psychologically safe.”

As Edmondson states in the quote above, “psychological safety is an essential element of organizations…” (emphasis added) – it isn’t a team skill or behavior.

This critical fact is where so much of the literature, and Google’s study in particular, come up short. Knowing that successful teams operate in an environment of psychological safety does not enable leadership, management, or coaches to build psychologically safe environments any more than looking at a painting enables me to paint a replica of it.

The real challenge is determining how one can mindfully, purposefully build a psychologically safe environment within an organization. To answer this question, we need to first understand what, exactly, psychological safety is. I define the term slightly differently than many textbook definitions:

Psychological safety is the existence of an environment in which individuals proactively exercise assertiveness, state opinions, challenge assumptions, provide feedback to teammates and leadership, while openly sharing mistakes and failures.

Many traditional definitions of psychological safety make use of the term “feel,” as does Edmondson: “The term psychological safety describes a climate in which people feel free to express relevant thoughts and feelings. Although it sounds simple, the ability to seek help and tolerate mistakes while colleagues watch can be unexpectedly difficult.” [3] (Emphasis added.)

However, I purposefully make use of the word “exercise.” Although this may seem a semantic difference at first glance, since we’re concerned with factors such as team performance, quality, and effectiveness, the existence of a psychologically safe environment in which no one actually admits mistakes or states opinions (although they feel free to) is undesirable. We need not only the environment, but also the actual actualization of the skills and behaviors necessary to realize the environment’s benefits.

How to build psychological safety in teams and organizations.

Although I’ve only glossed over the considerable amount of theory and research, I also don’t want to try to provide a Reader’s Digest version of decades of knowledge here. I’d rather get right to the point. What do leaders, managers, coaches, and teams need to do to purposefully build psychological safety in their environment, today?

First, significantly reduce the focus on processes and frameworks. The existence of a specific environment or culture is largely independent of the business process employed in an organization’s daily operations. Some frameworks and methodologies are structured to support the types of psychologically safe environments necessary to enhance team performance and effectiveness, but they do not guarantee it.

As Lyssa Adkins, author of Coaching Agile Teams, stated in her Closing Keynote at the 2016 Global Scrum Gathering in Orlando, Florida:

“I thought we would have transformed the world of work by now. People, we’ve been at this for fifteen years…Transforming the world of work is literally a human development challenge. So we are awesome, we are so good in this community at process and business agility. We’ve got that handled people, and we’ve had that handled for a while. What we’re not so good at, what I want to see us become just as great at, is human systems agility. Because that’s the other piece of it…You know, those organizations – they’re all made of humans, aren’t they? So, human systems agility is a piece of business agility. Not the only one, but an important one; and one that we’re not as good at.” [4]

Business processes and frameworks, including Agile systems such as Scrum and Lean, can only help create a structure capable of supporting the ways in which teams and individuals need to work to reach the highest levels of performance, effectiveness, and innovation. What those teams – from executive to functional – need, is a shared mental model, a Known Stable Social Interface for interacting and working collaboratively together, and which enables them to develop and exercise the interpersonal skills and behaviors necessary for psychological safety.

Leadership and management must initiate the formation of a psychologically safe environment by welcoming opinions (including dissent) on goals and strategies from peers and subordinates. People in management or leadership roles who fear questioning or are more focused on their ideas than on the right ideas need to either learn, adapt, and grow, or move on. They are obstacles, roadblocks, and hindrances to organizational effectiveness, performance, and innovation.

Steps leadership and management can take to start to create psychological safety:

  • Establish and clearly communicate expectations
  • Receive training themselves
  • Provide training for their employees
  • Ensure follow-through with dedicated coaching and regular check-ins

Then, learn about and employ the following behaviors and skills:

  • Frame mistakes and errors as learning and opportunities for improvement.
  • Encourage lessons learned to be shared instead of hidden, focused toward helping others to learn, grow, and avoid similar mistakes.
  • Embrace the value of failure for learning by admitting to mistakes they’ve made themselves.
  • Understand the difference between failures and subversion, sabotage, incompetence, and lack of ability.
  • Learn about the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Situational Awareness, Goal Analysis, and Decision-Making. Those skills include the explicit behaviors necessary to build psychological safety in the organizational environment.

“If I focus on using your mistake as a way to blame and punish you, I’ll never hear about your mistakes until a catastrophe ensues. If I focus on using your mistake as a way for us to learn and improve collectively, then our entire process, system, and business will be better after every mistake.”

Individuals and teams can also help to build and enable psychologically safe environments:

  • Seek training about and learn the interpersonal, social skills which power team effectiveness, including Leadership, Communication, Assertiveness, Goal Analysis, Decision-Making, Situational Awareness, Agility, and Empathy.
  • Advocate for and build a climate in which learning and improvement is possible through open and honest analysis of failures / mistakes.
  • Frame and focus discussions on the plans, strategies, and ideas supporting what is right, not who is right.
  • Assume responsibility for their own psychological safety and proactively help build it as a fundamental attribute of their teams’ work environment.

Psychological safety is a key organizational characteristic which is critical to the growth of high-performing teams. However, it isn’t a holy grail and most organizations, coaches, and consultants do not know how to purposefully create a psychologically safe environment, nor why it makes sense to do so. Yet mindfully organizing to build high-performing teams is not only possible, it is something which many organizations have been doing for decades.

 

Chris Alexander is a former F-14D Flight Officer, the co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, and Scrum Master, and has a passion for working with high-performing teams. Learn more at https://www.aglx.consulting.

References:

  1. Pentland, Alex (2014­01­30). Social Physics: How Good Ideas Spread – ­The Lessons from a New Science (p. 90). Penguin Publishing Group. Kindle Edition.
  2. Edmondson, Amy C. (2012­03­16). Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy (Kindle Locations 1474­-76, 2139-40). Wiley. Kindle Edition.
  3. Ibid, 2141-2144.
  4. https://www.youtube.com/watch?v=LDKYehwuirw

Share This:

High-Performing Teams: Built from the Basic Skills of Human Interaction

I’ve struggled my whole life to connect the dots. I’m the smartest dumb person I know, and I at times amaze even myself with the brilliance of my own insights, which generally occur simultaneously alongside my forgetting to turn off the stove, or turn on the dishwasher (which I’ve just finished loading).

I recall quite vividly sitting in Instrument Ground School, well along my way to becoming an F-14 Tomcat Radar Intercept Officer (RIO), and learning about Crew Resource Management (CRM) for the first time. My overwhelming thought at the time was, “why do they insist on teaching us things we already know?”

Of course, they weren’t. Instead, once again, I was both intelligent enough to recognize the value of CRM for what it meant to my situation immediately, but not smart enough to appreciate, in any sense whatsoever, the importance of its formation and history, nor its incredible potential to help people everywhere to work together, in any environment or on any problem; from operating rooms to oil rigs, from ocean floors to outer space.

High-Performance Teaming™, one of Crew Resource Management’s successors, leverages those same skills which have been proven to help teams perform and succeed in High-Reliability Organizations across cultures and industries to include NASA, surgical teams, nuclear power stations, civil and military aviation, and special forces units, to name just a few.

The simple reason that these tools work across such diverse types of teams is not because they are based in the newest or most proven processes, or the latest in business operating frameworks or methodologies. Rather, these tools work because they focus on building the skills which enable dynamic, positive, and powerful human interaction.

By leveraging our shared human abilities to learn and improve, and targeting the skills specifically connected to the human capability to effectively function as part of a team, we can develop high-performing teams regardless of functional level or the domain of work.

Take, for example, rock climbing.

I know – “whaaaat?” Stick with me. I was recently asking one of the teams I work with what they would like to do to celebrate our successful (and early) completion of a software feature. Typically I would expect the standard answers: go to a team lunch, after-work drinks, trip to the pinball museum, Friday-night pool – the usual things teams choose to do. Yet, as is becoming standard, the team surprised me.

“The weather Thursday is supposed to be beautiful. How about if we do a team rock climbing day?”

Now I’m a climber and so are a couple of other people on the team, and going climbing together is something we’d half-joked about plenty of times, but this was a real suggestion. So I asked around, gave it some thought, and realized we could use the experience to not only have fun and bond further as a team, but to actually train with the skills we’d been talking about at the office in an entirely different context. My hypothesis was that a team of individuals climbing together is still a team, and the same skills which drive human interactions within teams in an office environment, an operating room, or in a cockpit, should be congruent.

So we went rock climbing, and discussed the litmus test. Here’s how I set up the day and the High-Performance Teaming skills we discussed in the context of our day on the rock.

Communication. As it was actually quite windy at the climb site and we were a few hundred feet up the side of a hill beside a busy interstate, the conditions for clear and easy communication were not good. Yet communication is critical to good team performance. Personal tendencies, culture, speech, choice of words and a standard vocabulary, not to mention overcoming environmental challenges (wind, noise, etc.) were all critical to our performance.

Assertiveness. Given the challenges already acknowledged to our communication, combined with the fact that we had a few new climbers who hadn’t done this sort of thing before, we recognized the need for everyone to assume an assertive role in helping the team ensure that we achieved our goals. We needed everyone to speak up when something didn’t look right or make sense, or when they did not understand anything about what they were being asked to do.

Goal (or Mission) Analysis. I asked the team at the parking lot to state what they believed was our goal for the day. “Go climbing,” “have fun,” “enjoy the outdoors,” “bond as a team” were a few of the responses. All noble and understandable goals, to be sure, but I offered another: “come back safely.” Understanding what your primary goal or goals are isn’t always intuitive, obvious, or easy, but getting it wrong can create a cascade of mistakes due to your team being misaligned on the very fundamental issues around why they’re doing what they’re doing.

Situational Awareness. Understanding that we’re going to have to make decisions about which routes to climb, who will be climbing belaying, whether we need to clean routes behind us, and a host of other potential situations (what happens if someone is injured?) requires us all to constantly re-assess and evaluate where we are in our day, what we are doing, and what we are trying to do. We need to ensure that we are fully aware of what is going on around us, and what is supposed to be going on around us.

Decision-Making. Early in the day our ability to decide on which routes to climb and which partners would climb/belay in what order was affected by stress, but as the day wore on and the stress of working together in a new team diminished, fatigue and the potential for complacency set in. Our ability to make the right decisions in important situations such as who climbs next, when to clean the route and move, who leads, where and when to relocate, when to take a break, and when to stop for the day, hinged on our ability to communicate well, maintain our situational awareness, and maintain focus on our primary goal – a safe return.

Agility. Many people talk about being Adaptable, however I prefer the term Agility. Agility, I’ve heard said, is Adaptability in a timebox. We had no sooner hiked around the corner to our climbing site to begin execution of our plan to climb the first two pitches (which were not challenging by design), then we had to adjust our plan due to the fact that both routes were already being worked by the local fire department, also out for a day of cliff rescue training in some gorgeous weather. So we quickly re-planned and moved to an alternate site.

Leadership. In a team of peers, leadership is often a revolving position. In a team with three experienced climbers and three beginners, we needed to rotate leadership responsibilities at different times based on the situation. Yet what most people get totally wrong is what the leader actually does. The leader isn’t there to make decisions and pass out orders, rather to pull the team together, ensure everyone understands what is occurring and what the plan is, solicit feedback and invite constructive dissent, to support assertiveness, and to leverage the collective wisdom of the team in analyzing goals and making collective decisions. Leadership is not about being right, it is about what is right. As each of us moved through moments of assuming leadership, our interactions were all similar: does everyone understand and agree with the plan? Does everyone understand what is being asked of them? Are you ready to move forward? Are we all ready for the next step?

Empathy. The ability to recognize and respond appropriately to the emotional state of others is a fundamentally human skill which powers every other social interaction skill. Looking at my climbing partner who is about to start on the route, I ask “ready?” The novice climber looks back tentatively and responds “ready.” However I see in his stance, face, and eyes that he is struggling with fear, doubt, and uncertainty. I encourage him to begin the route by pulling the rope tight and responding “on belay – I’ve got you.” This gives him some confidence. I don’t want to take his fear and uncertainty away – I want him to work through it on his own, which I know he can. This is empathy in action.

The skills required to enable and power high-performance teamwork are grounded in our fundamental ability to interact with other humans. This statement will continue to be true until the day arrives when we need to team with robots or aliens, at which point it is conceivable that other skills might be required. However for the entirety of human existence, people have needed to work together and have, unsurprisingly, evolved to do just that. The amazing thing in our growing technological age is that some of those natural, instinctual, basic social skills are incredibly difficult to recall and apply. Yet train, learn, and apply them we can, and in doing so we can actually help build and become the incredibly high-performing teams we’ve always envisioned.

 

Chris Alexander is a former F-14D Flight Officer, the co-founder of AGLX Consulting, High-Performance Teaming™ coach, Agile coach, and Scrum Master, and has a passion for working with high-performing teams. Learn more at https://www.aglx.consulting.

Share This:

What the Agile Community Should Learn from Two Little Girls and Their Weather Balloon

As reported by GeekWire, over the weekend two Seattle sisters, Kimberly (8) and Rebecca (10) Yeung, launched a small weather balloon to the edge of space (roughly 78,000 feet). They have the GoPro video from two cameras to prove it.

While this is certainly an impressive, if not amazing, feat for two young girls to have accomplished (despite some parental assistance), what is perhaps most impressive (at least to me) is the debrief (or retrospective) they held after the mission. While I’m not fortunate enough to have been there to witness it personally, I can see from the photo of their debrief sheet (as posted in the GeekWire article) that it was amazingly productive and far surpasses most of the agile retrospectives (debriefs) I’ve witnessed.

14416510384450*Photo copied from the article on GeekWire.

Apart from the lesson about their Project Plan (“We were successful because we followed a Project Plan & Project Binder”), this sheet is astonishingly solid. Even given the fact that I think it is a misconception to attribute success to having had a project plan, for an 8 and 10-year-old, this is awesome work!

My friend and fellow coach Brian Rivera and I have often discussed the dire lack of quality, understanding, and usefulness of most agile retrospectives. I might even go so far as to call the current state of agile retrospectives in general “abhorrid” or “pathetic,” even “disgraceful.” Yes, I might just use one of those adjectives.

For teams using agile methodologies and frameworks focused on continuous improvement (hint: everything in agile is about enabling continuous improvement), the retrospective is the “how” which underlies the “what” of continuous improvement.

Supporting the concrete actions of how to improve within the retrospective are the lessons learned. Drawing out lessons learned during an iteration isn’t magic and it isn’t  circumstantial happenstance – it requires focused thought, discussion, and analysis. Perhaps for high-performing teams who have become expert at this through positive practice, distilling lessons learned and improving their work may occur at an almost unconscious level of understanding, but that’s maybe 1% (5% if I’m optimistic) of all agile teams.

So what does a team need to understand to actually conduct a thorough and detailed analysis during their retrospective? Actually only a few things:

  1. What were they trying to do? (Goals)
  2. How did they plan to do it? (Planning / strategy)
  3. What did they actually do? (Execution – what actually occurred)
  4. What were their outcomes? (Results of their work)
  5. What did they learn, derived from analyzing the results of their efforts measured against the plan they had to achieve their goals? (Lessons learned)

A simple example:

  1. I want to bake peach scones which are light, fluffy, and taste good. (Goal + acceptance criteria)
  2. I plan to wake up early Saturday morning and follow a recipe for peach scones which I’ve found online, is highly rated, and comes from a source I trust. It should take 30 minutes. (Planning – who / what / when / where / how)
  3. I wake up early Saturday morning and follow the recipe, except for the Baking Powder. It can leave a metallic taste behind, so I leave it out. (Execution)
  4. It took almost an hour to make the scones, and they did not rise. They tasted alright, but were far, far too dense and under-cooked internally, partially due to being flat. (Outcomes)
  5. I didn’t allocate enough time based on the fact that it was my first attempt at baking scones and I was trying to modify a known good recipe (reinventing the wheel, root causes: experience). Although I wanted light, fluffy scones, I didn’t get them because I deliberately left out a key ingredient necessary to help the dough rise (good intention – bad judgment, root causes: knowledge / discipline). (Lessons learned)

Perhaps a bit overly simplistic but this is exactly the type of concrete, detailed analysis into which most teams simply never delve. Instead, retrospectives for most agile teams have devolved into a tragic litany of games, complaining sessions, and “I liked this / I didn’t like that” reviews with no real outcomes, takeaways, or practical concepts for how to actually improve anything. Their coaches leave them with simple statements such as “we need to improve.” Great. Thanks.

Taking what we know from Kimberly and Rebecca’s plan to send a weather balloon into outer space, let’s do a little analysis on their retrospective. I can tell you already it is not only solid, but will ensure they’re able to improve not only on the technical design itself, but also improve their team’s “meta” – the ways they work, their collaboration, their teamwork, their research – everything which enables them to actually continually improve and produce powerful results.

  • Bigger balloon – create more lift – ensure faster rate of ascent (Technical / work – related but important. They have learned through iterating.)
  • Remember to weigh payload with extra – more accurate calculations – correct amount of helium (Technical but also process-related, this draws root causes arising from both knowledge and experience, enabling them to adapt both their work itself and their meta – how they work.)
  • Don’t stop trying – you will never know if you don’t ask. Eg GoPro (Almost purely meta, reflecting a great lesson which builds not only a team mindset but also reflects a core value, perseverance!)
  • Washington Geography – Map research on launch locations taught us a lot of geography (This is both technical and meta, addressing their research data and inputs/outputs but also learning about how to learn and the value of research itself!)
  • Always be optimistic – We thought everything went wrong but every thing went right. Eg. SPOT Trace max altitude mislead [sic] our expectations. Eg. We thought weather cloudy but it was sun after launch. Eg. Weight. Thought payload too heavy for high altitude. (Are you kidding me?! Awesome! Lessons about situational awareness and current operational picture, data inconsistencies, planned versus actual events, planning data and metrics, and the importance of outlook/attitude! #goldmine!)
  • Be willing to reconstruct – If you find out there is a problem, do not be afraid to take it apart and start all over again. (Invaluable lesson – learning to embrace failure when it occurs and recover from it, realizing that the most important thing is not to build the product right, but to build the right product!)
  • Have a redundant system – Worry less. (Needs no explanation.)
  • SPOT Trace technology awesome – Very precise (This is a fantastic example of a positive lesson learned – something that is equally important to acknowledge and capture to ensure it gets carried forward and turned into a standard practice / use.)
  • Live FB updates – add to fun + excitement (Yes yes yes!! To quote an old motto, “If you’re not having fun, you’re not doing it right!” This stuff should be fun!!)
  • Speculation – Don’t guess. Rely on data. (Fantastic emphasis on the importance of data-oriented decisions and reflects another potential team core value!)
  • Project Plan – We were sucessful [sic] because we followed a Project Plan + Project Binder. (The only lesson I disagree with. I would advocate a good 5 Whys session on this one. My suspicion is that the project was successful because they as a team worked both hard and well together [high-performing], had fun, and iterated well [based on the lesson about not being afraid to reconstruct / start over]. I have serious doubts that their mission was a success because they had and followed a project plan. Regardless, this is far too small a point to detract from the overall impressiveness of their work!)

Take a few lessons from two girls who have demonstrated concrete learning in ways most adults fail miserably to even conceptually grasp. If you are on a team struggling to get productive results from your retrospectives, stop accepting less than solid, meaningful analysis coupled with clear, actionable results. The power is in your hands (and head).

If you are one of those agile coaches who thinks retrospectives are just for fun and celebration, who plays games instead of enables concrete analysis, and who wonders why their teams just cannot seem to make any marked improvements, get some education and coaching yourself and stop being a part of the problem!

(Written with the sincerest of thanks to Kimberly and Rebecca Yeung, and the Yeung family for their outstanding work, and to GeekWire for publishing it!)

* Chris Alexander is an agile coach, thinker, ScrumMaster, recovering developer, and co-founder of AGLX Consulting, who spends too little time rock climbing.

Share This: