Category Archives: Agile

Agile systems, frameworks, and methodologies

Risk Management and Error Trapping in Software and Hardware Development, Part 1

The way in which we conceptualize and analyze risk and error management in technology projects has never received quite the same degree of scrutiny which business process frameworks and methodologies such as Scrum, Lean, or Traditional Project Management have. Yet risk is inherent in everything we do, every day, regardless of our industry, sector, work domain, or process.

We actually practice risk management in our everyday lives, often without consciously realizing that what we are doing is designed to manage levels of risk against degrees of potential reward, and either prevent errors from occurring or minimizing their impact when they do.

For example, I recently took a trip to the San Juan islands with my wife and parents. I woke up early, made coffee, roused the troops, and checked the weather. I’d filled up the gas thank the day before, and booked our ferry tickets online. I checked the weather and recommended we each take an extra layer. We departed the house a bit earlier than really necessary, but ended up encountering a detour along the way due to a traffic accident on the Interstate. Nevertheless, we made it to the ferry terminal with about 10 minutes to spare, and just in time to drive onto the ferry and depart for Friday Harbor.

My personal example is relatively simple but, with a little analysis, demonstrates how intuitively we assess and manage risk:

  • Wake up early: mitigates risk of oversleeping and departing late (which could result further in forgetting important things, leaving coffee pot/equipment on, etc.), waiting on others in the bathroom, and not being able to prepare and enjoy some morning coffee (serious risk).
  • Check the weather: understanding the environment we are entering into is critical to mitigating environment-related risks, in this case real environmental concerns such as temperature, weather, wind, and precipitation, enabling us to mitigate potentially negative effects and capitalize on positives. Bad weather may even result in our changing our travel plans entirely – a clear form of risk mitigation in which we determine that our chance for a successful journey is low compared against the value we would derive from undertaking the journey in the first place, and decide the goal is not sufficient to accept present risk levels.
  • Book ferry tickets online: a mitigation against the risk of arriving late and having to wait in line to purchase tickets, which could result in us missing the ferry due to either running out of time or the ferry already being completely booked.
  • Departing earlier than necessary: a mitigation against unforeseen and unknowable specific risk, in this case the generic risk of en route delays, which we did encounter on this occasion.

As you can see, as a story my preparations for our trip seem rather routine and unremarkable, but when viewed through the lens of risk mitigation and error management, each action and decision can be seen as specifically targeted to mitigate one or more specific risks or minimize the potential effects of an error. Unfortunately, our everyday intuitive actions and mental processes seldom translate into our work environments in such direct and meaningful ways.

Risk and Error Management in Software and Hardware Development – Defense-in-Depth and the Swiss Cheese Model

Any risk management system can be seen as a series of layers designed to employ a variety of means to mitigate risk and prevent errors from progressing further through the system. We call this “trapping errors.” Additionally, each of these layers is often just one part of a larger system. A system constructed with these layers  is referred to as having “defense-in-depth.”

Defense-in-depth reflects the simple idea that instead of employing one single, catch-all solution for eliminating risk and trapping errors, a layered approach which employs both latent and active controls in different areas throughout the system will be far more effective in both detecting and preventing errors from escaping.

These layers are often envisioned as slices of Swiss cheese, with each slice representing a different part of the larger system. As a potential risk or error progresses through holes in the system’s layers, it should eventually be trapped in one of the layers.

Risk and errors are then only able to impact the system when all the holes in the system’s Swiss cheese layers “line up.”

Latent and Active Layers

There are two basic types of layers (or traps) in any system: latent and active. In your day to day life, latent traps are things such as the tires on your car or the surface of the road. Active traps are things such as checking the weather, putting on safety gear, wearing a helmet, or deciding not to go out into the weather.

Latent layers in software or hardware development may be things such as the original (legacy) code base, development language(s) used, system architecture & design, hardware (types of disk drives, manufacturer), and so forth. It may even include educational requirements for hiring, hiring practices, and company values.

Active layers in software and hardware development may include release processes, User Story writing and acceptance criteria, and development practices like TDD/ATDD, test automation, code reviews, and pair programming.

Separation of Risk and Error Management Concerns

To better focus on dealing with the most appropriate work at the appropriate time in responding to error detection, triage, and risk mitigation, we can separate our risk and error analysis into the following areas:

During development: focus on trapping errors

  • Prevention – the practices, procedures, and techniques we undertake in engineering disciplines to help ensure we do not release bugs or errors into our code base or hardware products.
  • Detection – the methods available to us as individual engineers, teams, and the organization as a whole to find and respond to errors in our code base or hardware products (which includes reporting and tracking).

Risk mitigation: steps for errors that have escaped into certification or production environments

  • Risk Analysis – the steps required to analyze the severity and impact of an error.
  • Risk Decision-making – the process of ensuring decisions about risk avoidance, acceptance, or mitigation are made at appropriate levels with full transparency.

Continuous Improvement in every case

Improvement – the process of improving workflows and practices through shared knowledge and experience in order to improve engineering practices and further harden our release cycles. This step uses root cause analysis to help close the holes we find in the layers of our Swiss cheese model.

Here is one conceptualization of what a Defense-in-depth Risk Management model might look like. Bear in mind that this is simply one way to conceive of layers at a more macro level, and each layer could easily itself be broken down into a set of layers, or you could conceive of it as one very large model.

swiss_cheese

Given our model and our new ability to conceive of Risk and Error Management in this more meaningful and purposeful way, our next step is to understand error causality and what we can do to apply our causal analysis to strengthening our software and hardware risk management and error trapping system.

Continue reading in part 2 of this 3-part series.

 

Chris Alexander is a former U.S. Naval Officer who was an F-14 Tomcat flight officer and instructor. He is Co-Founder and Executive Team Member of AGLX Consulting, creators of the High-Performance Teaming™ model, a Scrum Trainer, Scrum Master, and Agile Coach.

Share This:

Why Your Next Agile Coach Should be a Fighter Pilot

As technological adoption and innovation accelerate through Mach 3, more business leaders will turn to fighter pilots to help their businesses survive and thrive in today’s VUCA world. For example, the cognitive and social skills naval aviators developed in the cockpit are in high demand in industries where teamwork is essential and team failures costly (e.g. healthcare, oil and gas, mining, energy, and commercial aviation). As more companies adopt a team-based approach to product delivery, and product and companies’ lifecycles shorten, the demand for proven team performance training and coaching will accelerate.

The cognitive and social skills (nontechnical skills) fighter pilots learn are rooted in what is considered to be one of the success stories of modern psychology and cognitive engineering: Crew Resource Management (CRM). CRM training, affectionately known as “Charm School,” covers crucial aspects of resilience including the topics of situational awareness, mission planning, team dynamics, workload management, effective communication, and leadership. CRM was developed in response to the realization that the kinds of errors that cause plane crashes are invariably errors of teamwork and communication (nontechnical skills).

A 50,000 foot view of CRM

  • CRM is the foundation of a human-systems approach, Threat and Error Management (TEM), designed by Human Factors engineers to help us understand and direct human performance within complex operating systems.
  • Human Factors is the applied science of how humans relate effectively and productively with one another in highly technological settings.
  • Crew Resource Management (CRM) is defined as the use of all available resources—information, equipment, and people—to achieve safe and efficient flight operations.

Fighter Pilots as Agile Coaches?

In the 1950s, John Boyd, a fighter pilot and military strategists, developed a decision cycle that changed the “The Art of War.” The decision cycle Boyd developed is known as the OODA Loop and refers to Observe-Orient-Decide-Act. In business, the speed at which the OODA Loop is executed allows the company to get “inside the decision cycle” of its competitors or valued customers. The OODA Loop is an exercise in empathy.

Eric Ries, author of The Lean Startup and entrepreneur, attributes the idea of the Build-Measure-Learn feedback loop to John Boyd’s OODA Loop. At the core of Steve Blank’s Customer Development model and Pivot found in his book, The Four Steps to the Epiphany, is once again OODA. In his new book, Scrum: The Art of Doing Twice the Work in Half the Time, Dr. Jeff Sutherland, a former fighter pilot and the co-creator of Scrum, mentions that the origins of Scrum are Boyd’s OODA and the Toyota Production System.

Scrum is based on my experience flying F-4 Phantoms over North Vietnam… Fighter pilots have John Boyd’s OODA Loop burned into muscle memory. They know what Agility means and can teach it uncompromisingly to others.

-Jeff Sutherland, co-creator of Scrum

What’s missing from today’s Agile Coaching toolkit is the proven human-interaction skills (nontechnical) developed for technical teams who operate in complex environments, CRM. The Agile community is making the same assumptions fighter and commercial pilots made pre-CRM: That effective teams can be built without any formal guidance or instruction. “Leaving it up to the team” is a recipe for failure.

Fighter pilots, unlike some agilists, are horrible marketers. Crew Resource Management is not your DaD’s Scaled Agile Framework (SAFe) nor does it tell you how to do more with LeSS; CRM is a proven approach to building agile at scale. CRM does not replace Scrum but provides the tools an enterprise needs to transition command-and-control managers into servant leaders and build effective and efficient teams. CRM is the “Science of Teamwork.”

9 Cognitive and Social Skills Fighter Pilots Bring to the Agile Fight

1. Adaptability. The ability to alter a course of action based on new information, maintain constructive behavior under pressure and adapt to internal and external environmental changes. The success of a mission depends upon the team’s ability to alter behavior and dynamically manage team resources to meet situational demands.

2. Empathy. Empathy? Fighter pilots and empathy? Yes. John Boyd’s OODA is really about empathy. According to Geoff Colvin, empathy is “discerning what some other person is thinking and feeling, and responding in some appropriate way [1].” OODA is an exercise in empathy. Moreover, according to Geoff Colvin, empathy is the foundation of all other abilities that increasingly make people valuable as technology advances [1].”

3. Assertiveness. One’s willingness to actively participate, state and maintain a position, until convinced by the facts that other options are better.

4. Decision Making. The ability to choose a course of action using logical and sound judgment based on available information.

5. Leadership. The ability to direct and coordinate the activities of other team members or wingman and to encourage the team to work together.

6. Mission Analysis. The ability to develop short-term, long-term and contingency plans and to coordinate, allocate and monitor team resources. Effective planning leads to execution that removes uncertainty and increases mission effectiveness.

7. Situational Awareness. The degree of accuracy by which one’s perception of the current environment mirrors reality. Maintaining a high level of situational awareness will better prepare teams to respond to unexpected situations.

8. Communication. The ability to clearly and accurately send and acknowledge information, instructions, or commands and provide useful feedback. Effective communication is vital to ensuring that all team members understand mission status.

9. Workload Management. The implementation of a strategy to balance the amount of work with the appropriate time and resources available. It includes making sure those people are alert and vigilant (preventing fatigue); figuring out who does what delegation; teaching people how to manage interruptions (and limit interruptions at critical moments; prioritizing tasks and avoiding task oversaturation; and avoiding pitfalls such as continuing a project, flight, or activity even when it’s becoming clearer and clearer that it is dangerous to do so. Workload management in high-reliability industries also means doing all of the above under stress.

While putting this list together I came up with more than 50 examples of why a fighter pilot should be your next Agile Coach. Please feel free to add more or comment on my choices for this article.

Brian “Ponch” Rivera is a recovering naval aviator and co-founder of AGLX, LLC, a Seattle-based Agile consultancy that melds the proven principles of High Reliability Organizations with today’s Agile practices.

[1] Geoff Colvin. Humans are Underrated: What high achievers know that brilliant machines never will. (Portfolio/Penguin, 2015).

Share This:

Leading Agile Organizations: Lessons from the Flight Deck

Have you ever been part of an organization where the product owner, manager, or CEO failed to accept input from a junior or rookie team member and the project or initiative failed? Imagine being part of a team where either failing to share information or not acting on critical information is found to be the root cause behind flying an actual project, an aircraft, into the ground.

In the cockpits of today’s commercial airliners and military aircraft, open communication and the ability to respectfully question authority(perceived or explicit) are essential cognitive and interpersonal skills every crew member must learn so as a team, make that a high-performing team, they can mitigate the unforgiving risks inherent in their complex environment. However, thirty years ago cockpit culture was the poster child for management 1.0 (control) — the very problem impeding agile transformations around the globe.

In the 1970s a rash of commercial airline accidents led NASA and the National Transportation Safety Board (NTSB) to investigate how to fix the complex aviation system. The tipping point in commercial aviation came on December 28, 1978 when United Airlines Flight 173 (UA-173) crashed in a Portland suburb, killing 10 passengers.

UA-173, a DC-8 with 181 passengers on board, circled near the Portland, Oregon airport for an hour as the crew tried to troubleshoot a landing gear problem. The flight engineer, the crew member responsible for monitoring the aircraft systems, unsuccessfully warned the captain (the flying pilot) of the rapidly diminishing fuel supply. The captain—later described by one investigator as “an arrogant S.O.B.” –waited too long to begin his final approach and as a result UA-173 ran out of fuel and crashed.

United-173-e1404804178495

Following the UA-173 investigation, NASA discovered that 60-80% of airline accidents were caused by human error. Digging deeper, and not just settling on human error as a singular cause, NASA identified failures in alignment, leadership, interpersonal communication, and decisiveness as root causes behind several commercial airline disasters including UA-173.

The hierarchical, command and control culture commonly found in the front office (flight decks) of 1970s era commercial airliners including that of UA-173 were no different than those cultures found in many of today’s legacy companies. Following the crash of UA-173, the aviation industry with the help of NASA realized through deep retrospection that the top-down predict-and-control paradigm of managing in complex environments needed to change.

The hierarchical “chain of command” system in place at the time of the accident [UA-173] did not always provide for effective flight crew resource management. Additional training was identified as being needed to ensure the flight crews recognized the value and merits of flight crews breaking down the more formal hierarchical structure. This approach leads to a more participative and collaborative process to ensure that all members of the flight crew feel free to speak up and provide the captain with all relevant information relating to the safety of the aircraft [1].

This change came in the form of Crew Resource Management (CRM), a leadership training system that “encompasses a wide range of knowledge, skills and attitudes including communications, situation awareness, problem solving, decision making, and teamwork,” according to CrewResourceManagement.net. CRM liberated the cockpit environment so every member, regardless of rank, position, skills set, age, time with the company, etc., was empowered to truly collaborate around a shared objective or explicit purpose.

In today’s turbulent markets business leaders are desperately trying to become more “Agile” yet most fail because traditional company cultures—hierarchical, command and control bureaucracies—do not provide knowledge workers the support needed to innovate, adapt, and ultimately delight customers with valued, rapid product releases. Applying aviation lessons learned to Agile transformational challenges is not new; for those of you who have read my posts you are aware that commercial and military aviation have profoundly influenced Agile, Scrum, The Lean Start Up, and elements of design thinking.

Adding leadership patterns from CRM to your Agile toolbox will help transform managers into Agile leaders and coaches–rather than the perceived or actual impediments to organizational agility. In part 2 of this post, I will share more CRM information and provide ideas on how it can help remove the “S.O.B” from your cockpit before a project or your company crashes into the ground.

Warning: You may be the S.O.B.

Brian “Ponch” Rivera is a recovering Naval Aviator and current Enterprise Agile Coach and Executive Consultant based in Seattle, WA.

[1] FAA Website http://lessonslearned.faa.gov/ll_main.cfm?TabID=1&LLID=42&LLTypeID=7

Share This:

500% Productivity Increase in One Day: Lessons from a Stand-down

Last month, seven software development teams (35+ members) stepped away from their sprint for one day and participated in Sprint Stand-down. The problems the teams were trying to solve during the Stand-down were technical—the teams recognized they had a collective knowledge gap and needed to slow down to speed up.

During the Stand-down retrospective, we discovered the teams increased productivity by over 500% in one day—an unexpected and welcomed event outcome. The retrospective provided us an opportunity to examine the how and why behind the hyper-productivity realized in this unfamiliar, one-day training event.

The lessons we learned were not revolutionary; instead, the lessons reinforced the values and practices found in the Agile Manifesto, Scrum, Extreme Programming, CrossLead, Flawless Execution, Crew Resource Management and Threat and Error Management.  In one day, a Sprint Stand-down provided undeniable evidence to developers, product owners, managers, directors, VPs, and the CIO that empowered execution trumps the traditional command-and-control approach to product delivery.

The transferable lessons learned from the Stand-down fall into familiar categories:

  • Shared Purpose/Objective
  • Workload Management/Limit Work in Progress (WIP)
  • Leadership/Teamwork
  • Execution Rhythm or Cadence
  • Communication

Before going deeper into the lessons learned, I want to share a little bit about the origins, concept and our approach to a Sprint Stand-down.


Sprint Stand-down

You will not find a Sprint Stand-down in the Scrum Guide. A Stand-down is not found the Project Management Institute’s (PMI) vernacular nor is it part of any Agile or current trending management methodology. A Stand-down is a training evolution commonly used by elite military units, commercial aviation, and other high-reliability organizations (HRO) to accelerate team performance.

The purpose of any Stand-down is to promote knowledge-based training along with personal discipline and responsibility as essential elements of professionalism. It is designed to empower and inspire a community of professionals to continuously seek knowledge, integrate new information in everyday practice, and share new findings with others within the company and industry.

Stand-down Planning

The event was a self-organized undertaking where a small team of eight people were accountable for event execution. Planning for the event followed a rapid planning processes inspired by Crew Resource Management (CRM) and Threat and Error Management (TEM). The objectives of this Sprint Stand-down were to inform, inspire, educate, and motivate the teams—admittedly weak objectives as they lacked clarity and measurability.

With a shared understanding of the Stand-down objective(s), the planning team used a liberating structure to capture anticipated threats and the resources needed to overcome those threats, and reviewed lessons learned from previous events that were similar to a Stand-down. A Stand-down plan was formed in less than 35 minutes where each planning team member knew who would have to do what by when to ensure flawless Stand-down execution.

Stand-down Execution

The Stand-down included in-house subject matter experts and one external trainer with 35+ team members in one room for 6.5 hours. Team members treated the Stand-down as an offsite, declining all meetings and turning on their Outlook out-of-office replies. Team members were randomly assigned to one of two Stand-down teams as determined by the type of gift card they received when they entered the Stand-down room. Two additional gift cards were given to all participants for the purpose of regifting —team members were encouraged to give away their gift cards to other team members for any reason. Team members were warned that over lunch (provided by the company) they may be called upon to share with everyone to whom they gave a gift card to and why. The CIO provided an impromptu leadership moment which included the distribution of additional gift cards to team members who were nominated by their peers.

500%

An outcome of the event was an increase in productivity by 200% to 700% depending on the metric used (e.g. story points, stories done, stories in progress and stories done, etc.). However, it is likely, based on stories “done” during the Stand-down, 26, versus average stories completed during a normal sprint day, 5, the increase in productivity was 500%. In one day.

For argument’s sake, let’s just say the productivity outcome for this one day event was 20%, a palatable number for those who have not embraced the power of Scrum or empowered execution. What if we could take the lessons learned from this event and apply them to how we work during our normal workdays to get a productivity increase of 5% in the next two weeks?


Sprint Stand-down Lessons Learned

Shared Purpose/Objective

  • A team needs a shared purpose or common objective. Objectives should be clear, measurable, achievable, and aligned to a focus area, strategic line of effort, company vision, etc.
  • A shared purpose builds unity of effort. Teams were observed self-organizing throughout the day and reported a reduction in duplication of work and an increase in cross-team knowledge-sharing.

 Workload Management/  Limit WIP

  • Limit WIP. Individuals reported being happier as they felt part of a team of teams working toward one goal.
  • Context Switching is bad. Most team members reported that they did not check their email during the six hours. Team members reported that the internal Stand-down disruptions (we played music during frequent shout-outs) slowed them down and were absolutely disruptive.
  • Protect the teams from out-of-band work. Team members reported that they had no out-of band work during the day.
  • Empower team members to push back on work that is not aligned to the objective.
  • Pairing works. Teams paired all day. Some mobbed.

Leadership

  • Say “Thank You.” Team members should recognize and acknowledge the importance of others in task performance.
  • Leaders need to be visible but not intrusive. Checking-in to say “thank you” to individuals carries more weight than email.
  • An invisible leader is a visible problem. Team members noticed those leaders who failed to stop by to see how the day was progressing.
  • Unscripted leadership is the best kind. The CIO’s visit was received as genuine.
  • Recognition from leaders is great, but peer recognition of important contributions is even better.

 Execution Rhythm or Cadence

  • Stand-down tempo is not sustainable but the practice is sound when a knowledge gap exists.
  • Stand-downs should not exceed six hours.
  • Schedule Stand-downs as required. No more than once a month.

Communication

  • Face-to-face communication remains the gold standard.
  • Keep work visible. The teams shared one electronic backlog.
  • Co-locate teams to maximize the value of osmotic communication.
  • Cross-team pollination builds trust.

Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.

Share This:

What Agile Teams Can Learn from Flight Crews

Small, cross-functional teams working together with devices, focused on a shared objective, surrounded by complexity and frequently changing conditions. Welcome to the world of software development. And commercial aviation. Think the similarities between software development and aviation end here? Think again.

Aviation continues to have a profound influence on software development, organizational agility, cyber security, and transforming managers into leaders. For example, the complexity-busting framework, Scrum, used by technology companies to build complex software, comes from fighter aviation and Lean manufacturing. The Lean Startup, a popular business-model framework used by today’s hottest Silicon Valley startups, is based on John Boyd’s OODA Loop, an empathy-driven decision cycle that captures how fighter pilots “get inside” their opponent’s decision cycle to gain a competitive advantage.  Similarly, OODA (Observe, Orient, Decide, Act) is used to rapidly design products and in the burgeoning business of cyber security. On the management front, aviation is reported to be the inspiration behind the Holocracy movement, a social system where authority and decision-making are distributed throughout self-organizing teams. But you already knew all of this, right?

Next Time You Fly on a Commercial Carrier…

Commercial aviation flight deck and cabin crews follow the empirical process of plan, communicate, execute, and assess on each leg of their assigned trip (mission). Similarly, software developers around the globe follow the same empirical process found in Scrum—Sprint Planning (plan), Standups (communicate), Sprint Execution (execute), Review and Retrospective (assess). A sprint or iteration is a time-boxed mission (one to four weeks long) where potentially shippable software is delivered. With empowered team members and solid execution, Scrum builds a culture of continuous learning and innovation.

There’s more?

The human interaction skills needed on the flight deck and on software development and business teams are exactly the same; these cognitive and social skills include empathy, collaboration, discipline, communicationleadership, situation awareness and teamwork. Moreover, the silent killer found in the cockpit is also the top threat among software development and business teams.

Slow and insidious, poor Workload Management is the silent killer. However, software developers and Lean experts refer to Workload Management as Work in Progress (WIP). When business and software teams try to do too much (too much WIP), or do not have a shared purpose or objective, rapid value delivery (effective productivity) and quality decreases—detriments to business survival.

Prioritization of work in and out of the cockpit is an imperative but flight deck and cabin crews have a marked advantage over software and business teams: flight crews are trained on the effective use of all available resources needed to complete a safe and efficient flight; software and business teams are not. The non-technical skills training flight crews receive is called Crew Resource Management (CRM) and Threat and Error Management (TEM).

CRM, affectionately known as “Charm” school, teaches the cognitive and social skills individuals need to be part of high-performing teams in complex, rapidly changing environments. TEM is a human-system approach to building habits and skills team members need to manage threats and errors within complex operating environments.

What if technology teams applied the cognitive and social lessons learned from CRM and TEM to the world of software development?

Instead of “Scaling Agile,” what is needed is a Crew Resource Management- and Threat Error Management- influenced Agile Operating System–a system that builds leaders and empowers teams and individuals at every level. This operating system should enhance Scrum through a simple, repeatable, proven, and scalable set of interconnected and interdependent planning, communication, execution, and assessment processes that drive innovation, create leaders, and build a continuous learning culture. Think of this human operating system as the non-technical skills teams need to overcome complexity—those skills that flight crews have burned into muscle memory.

Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.

(c) Can Stock Photo

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:

An Agile Approach to Process Management

Does your business process do what it’s supposed to do?

This is a common question for those involved in business process management, and of course there are many existing methodologies designed to address this. Additionally, process improvement can be carried out at both the macro and micro levels. At the macro level, the business develops processes at the organizational level in order to achieve strategic goals. At the micro level, individual teams, departments, or individuals may develop processes (both formal in informal) to help them accomplish their work.

The issue with existing process development and analysis methodology is that it remains relatively waterfall-ish. Define all of the requirements, develop the process, communicate and implement, then occasionally analyze and change (improve) as needed. The cycle time involved with this approach can be considerable, and especially at the formal, macro level, once initiated the process may be particularly challenging to analyze or change.

An iterative approach to process design and management.

What if we considered process design in an adaptive, iterative way?

In other words, design a narrow process around the first, most important requirement, enabling rapid creation and implementation, feedback, and improvement, while developing toward additional requirements.

This serves two important purposes: first, it enables us to rapidly design and implement a process to satisfy the most important business need, while, second, enabling the process manager to receive fast feedback about the usefulness of the process as implemented thus far.

Once the critical first requirement has been met, the process can be adapted through iteration to satisfy additional requirements, again enabling feedback on the utility of the process overall.

Let’s look at an example of process improvement in new hire onboarding.

CDE Company has a challenging and sub-optimal process in place for onboarding new hires. CDE Company knows this because it is the number one pain point new hires relate about their experience joining the company. Let’s help CDE Co. improve their process through the application of Agile practicies – the same ones their Scrum teams are currently using to develop their products (so everyone is already familiar with and can use them!).

Step 1 – for an existing process, conduct a Process Retrospective

  • Define the goals of the process itself – what is the process supposed to do? “Minimize the amount of time new hires need to get up to speed quickly and become productive.”
  • Analyze the current process plan (how it is supposed to work). “New hire is welcomed and given a desk; requests are sent to create and activate their email account and grant access to the folders, tools, and utilities which they will need to do their job; new hire is added to email lists, meetings, and taken out to lunch; new hire will work alongside another developer to understand the code base and standard practices, and will be given an overview of the main products on which they’ll be working; new hires begin to work.”
  • Gather feedback on the actual current process and how it is executed. “New hire is welcomed and requests are sent; email and access to environments/tools takes anywhere from a couple of days to a week; being added to email lists/meetings requires finding the owners and asking to be added individually; buddying with another developer works ok; lunch is always good.”
  • Identify the lessons from analyzing the current process, the intended plan, and the actual goals. “Onboarding is slower than it should be and we are not achieving the goal of getting new developers up to speed and working quickly; getting email / account / tools / utilities / environments access is too slow and holds developers up; our buddying model works well once the new developer has the access needed; getting the new developer into meetings / email lists is fractured and takes too long.”
  • Transfer those lessons into a plan of action. “We need to re-prioritize and redesign the process to address the issues found in Lessons Learned. Specifically we need to plan to get access for the new hire on Day 1; we need to have email lists / meetings cleared up prior to Day 1; we should maintain the onboarding buddy system.”

Step 2 – hold a Process Improvement Planning Session

  • Set a Timebox for this process improvement / development cycle (1 or 2 weeks should generally be enough time – otherwise you’re taking on too much work).
  • Using the process owner(s) as a sort of Product Owner, determine what the most important requirement(s) of the process is in terms of either the Lessons Transferred from the Retrospective or the needs of the business, team, or individual. “Get the new developer access to email / development tools / environments on Day 1.”
  • It is important to note that the size / number of planned improvements should be something achievable within the agreed timebox. (Just to re-iterate: 1 improvement implemented is better than 5 improvements “in work”.)
  • Plan how to achieve the requirement identified, and name an owner. “Develop a consolidated list of tools / utilities / environments and work with infrastructure & engineering leads to create account permissions according to that list for new hires at Day 1 minus 2; on Day 1 minus 1 Operations places the account in a password reset state; on Day 1 new hire completes password reset process and has access to email and all required tools & utilities.”

Step 3 – implement the Plan 

The next new hire through the door gets to use the new process.

Step 4 – conduct the next Retrospective and Planning Session

Retrospect and then prioritize any new lessons along with the existing work which is still in the backlog and waiting to be done (such as improving new hires getting added to email lists and meetings). Moving forward to the next planning session, plan improvements for the next highest priority item(s) which can be achieved within the timebox.

An iterative approach to process improvement also provides the opportunity to stop working on process improvements once the process has been improved enough to be generating sufficient utility – regardless of whether every conceived improvement has been implemented.

Although certainly feasible, the majority of business value will likely be derived from implementing a portion of the desired improvements to a process, but not necessarily all. If we can determine that the Pareto principle (80% of the value of our process is delivered by 20% of the features/work) is indeed applicable to our process, then eliminating sub-processes or work not required will further contribute to business capacity by eliminating waste.

Whatever process you’re seeking to implement or improve upon, an Agile approach can help you build and deliver faster and with greater effectiveness. Payroll, feature request intakes, customer polling, software bug remediation, hardware certification, inventory management, data analysis and reporting – it is challenging to think of a single process which couldn’t benefit in some way from utilizing an iterative, Agile approach to design and continuous improvement.

Share This:

“Charm School” – The 9th Reason Your Next Agile Coach Should Be a Fighter Pilot

It has been a year since I wrote my first LinkedIn article, 8 Reasons Why Your Next Agile Consultant/Coach Should be Fighter Pilot, and although I still stand behind the original article, I have to admit I overlooked the most the important reason why you should hire a former fighter pilot to lead your agile transformation: “Charm School.”

As I was reading From Command to Team, one of the best chapters in General Stanley McChrystal’s new book, Team of Teams: New Rules of Engagement for a Complex World, I realized the most important leadership practices I learned in tactical aviation—group dynamics, leadership, interpersonal communication, and decision making—were missing from my 2014 list. Fortunately, the special operators who wrote Team of Teams recognized the value aviation “Charm School” has in how small teams should operate in complex environments and, thankfully, included the lessons learned from aviation in how they operated, and still do, as high-performing teams in near chaotic conditions [1].

What is “Charm School?”

CRM aims to foster a climate or culture where the freedom to respectfully question authority is encouraged.

In the most general sense “Charm School” or Crew Resource Management, also known as Cockpit Resource Management (CRM), is a system of simple training procedures focused on the cognitive and interpersonal skills needed to lead in complex environments.  According to Wikipedia, “the primary goal of CRM is enhanced situational awareness, self-awareness, leadership, assertiveness, decision making, flexibility, adaptability, event and mission analysis, and communication. Specifically, CRM aims to foster a climate or culture where the freedom to respectfully question authority is encouraged. It recognizes that a discrepancy between what is happening and what should be happening is often the first indicator that an error is occurring.”

An Example: Applying CRM Lessons to Delivering Digital Products

The other day a project manager (PM) wanted to discuss with me why members of two teams were not aligned on a new approach to delivering a product—an approach which was disseminated 24 hours earlier via email, an email which “everyone should have read.” Putting this command and control approach aside, I mentioned to the PM that just because an email was sent and read, it does not mean it was understood. Using lessons learned from “Charm School” I explained what this fire and forget approach to communication would look like in a cockpit of a commercial airliner.

Imagine you are a passenger on a flight from San Diego to Hawaii and flying your 757 today is Pilot A, a crusty command and control, my-way-or-the-highway manager. If Pilot A is in control of the aircraft (flying the aircraft) and turns to Pilot B and says, “You have control of the aircraft,” and pilot B does not hear or respond to Pilot A’s communication,  who is flying the aircraft?

In the example above, would you want to be a passenger on this flight or any aircraft knowing this is how pilots communicate? (Unfortunately, this is probably how most people in your organization communicate.) The good news is all pilots are required to go through “Charm School” so they can learn how to communicate with internal and external team members in their technical and complex environment. However, even with CRM, human error remains the cause for around 80% of aircraft accidents—are you ready for autonomous flying vehicles now?

Back to your digital product. From the Agile Manifesto, we know “the most efficient and effective method of conveying communication to and within a team is face-to-face conversation.” However, leaving the team to “figure it out,” the organic approach to building self-organized teams, is absolutely absurd given what we know about human behavior. Instead of recreating the wheel, teams can accelerate their agile journey by incorporating leadership practices from aviation “Charm School.” These individual and team practices include how to:

  • Establish Team Goals
  • Monitor the internal and external environments for threats (to include poor teamwork)
  • Cooperate and communicate
  • Establish feedback practices
  • Learn from failure, rather than adopting a failure-avoidance culture
  • Build a shared mental model, organizing knowledge in meaningful patterns (adopt repeatable, self-similar processes in planning, stand-ups, & retrospectives)

Here are a few practical steps to get you started with better CRM today:

  • Communicate face-to-face, following-up with a email only when necessary.
  • Encourage discussion, questioning, and debate – you might learn something yourself.
  • Respect the thoughts and opinions of the other people on your team, even when you disagree – the stronger argument, not the person with the most authority, wins.
  • When in doubt, seek advice – everyone needs a skilled wingman.

Organizations that are adopting an Agile approach to combat complexity will find solutions to their networked teams’ communication, leadership, decision making and situational awareness challenges in aviation’s CRM, a.k.a. “Charm School.” After all, two of the most recognizable approaches or frameworks to becoming Agile have fighter aviation origins.

Your next Agile Coach should be a fighter pilot.

Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.

[1] McChrystal, S. A., Collins, T., Silverman, D., & Fussell, C. (2015). Team of teams: New rules of engagement for a complex world.

[2] Reynolds, R., Blickendderfer, E. (2009) Crew Resource Management and Shared Mental Models: A Proposal.  Journal of Aviation/Aerospace Education & Research, 19(1), 15-24.  Downloaded from http://commons.erau.edu/cgi/viewcontent.cgi?article=1380&context=jaaer

Photo Courtesy of Team Oracle, 2004.

Share This:

Are you a Veteran moving into Tech? Yes? Then forget about the PMP.

Are you a Veteran or transitioning servicemember interested in obtaining your PMP and looking to jump into a tech job with (hopefully) one of the industry greats like Amazon, Apple, Google, Facebook, Microsoft, T-Mobile, AT&T, Capital One, Need I Go On? Not so fast!

PMP (Project Management Professional) certifications are becoming virtually obsolete in the technology industry. In thinking about your transition and employment goals and desires, ensure you’re future-proofing your plan as much as possible. Just as we don’t build tomorrow’s technologies on yesterday’s platforms, if you want to work in tech you need to build your resume for the future and not base it on certifications of the past (at least in this industry).

Alternatively, if you are interested in working for companies and institutions like public utilities, construction, shipbuilding, manufacturing, or in other complicated environments, then the PMP probably is the best answer for you and the right way to go. True, there are many manufacturing (hello Lean!) companies increasingly becoming agile, and many other industries and sectors are experimenting with agile methodologies and applications. However there is more than enough traditional project management work out there if you’re flexible about where you’re going and what you’re managing.

If the traditional project management world is where you want to be, the good news is that everything you’ve learned throughout your military career  has set you on course to fulfill your PMP requirements and obtain your certification. We wish you the best of luck!

If, however, the tech industry is where you want to be, then don’t waste your time on the PMP. Instead, start learning how to leverage your knowledge, skills, and experience operating in the complex environment of technology.

Your first challenge is going to be the reality that many of those very same technology companies do not fully understand what they are seeking in a job candidate. Companies which regularly espouse their “agility” and agile practices still put “PMP” on their hiring sheets in either the “Required” or “Desired” skills section. I guess because it is the way they’ve always done it (terrible!) and it’s like a warm, snuggly blanket of reassurance in the otherwise dark night of human resource uncertainty.

Yet typically once you get to the interview, things fall apart because – it turns out – the people hiring you are not the people who put the proverbial ad in the paper and they ask you questions about obscure, farcical conceptions such as Agile, Scrum, Lean, SDLC, Test Driven Development, iterations, continuous improvement (hey that one at least sounds good), and a host of other words that are relatively alien to a standard PM.

Unfortunately, those words are the core components of their business methodology, and the PMP has absolutely nothing to do with any of those concepts (although continuous improvement still sounds good).

The good news here is that your knowledge, skills, and experience actually are the key abilities technology companies seek, although it often requires some translation on your part. The first part of translation is knowing the language, so you need to start learning about Agile. Today.

Here are just a few ways to get started.

  • Look into the PMI-ACP (Agile Certified Practitioner) certification. There are lots of courses and strategies for getting the knowledge you need – the actual hands-on experience may be harder, but this is a great certification which gives you the exposure, vocabulary, and talent to show that you understand Agile theory, methodologies, and practices.
  • Take a course on Lean. This is another great agile methodology more geared towards manufacturing but which is making inroads and holds applicability to many areas of the tech industry.
  • Take a CSM (Certified ScrumMaster) or CSPO (Certified Scrum Product Owner) class. This will give you a few glimpses of what Agility is and will teach you about Scrum, the overwhelmingly most popular Agile framework in the market today. There are classes all over the world and a basic certification can be achieved in two days.
  • Check out any of the numerous books about Agile methodologies and thought.
  • Get involved in Agile discussions on LinkedIn, blogs, and other online sources. See if there are any Agile Meetups in your area, and go  to them. Agile practitioners love to talk about Agile, so leverage that.

Additionally, get online to resources like Code School and PluralSight (who own Code School) and start learning about software development, at least at a basic level. You’ll be amazed at how far apart this knowledge alone can set you from your competition.

Remember, this may take some creative selling on your part, as well. I’m regularly surprised to see the number of established companies recruiting for an agile project manager who have no idea what “agile” actually means. This is a fantastic situation for you – as an interviewee. You can actually educate them.

However to do that, you must be prepared and armed with the knowledge you need in order to have the conversation in the first place. So forget about the PMP and invest in yourself and in the studies which will prep you to get into the tech giants of today and tomorrow.

Share This:

Six False Assumptions That Are Killing Retrospectives

These six commonly accepted (but false) assumptions about retrospectives are killing innovation and hindering your teams’ future execution.

  1. Retrospectives are meetings
  2. A retrospective length is dependent on sprint/iteration length
  3. Retrospective variety ensures team members do not get bored
  4. There are three basic questions in a retrospective
  5. The Scrum Master or Agile Coach must facilitate the retrospective
  6. A retrospective is designed independently of other Scrum/Agile events

1. Retrospectives Are Not Meetings

Retrospectives are not meetings. Retrospectives are events. Why is this important? We know that words have meaning and if you look at the definitions of “meeting” and “event” you will see that a meeting is an assembly of people for discussion or entertainment. An event, on the other hand, is something that occurs in a certain place during a particular interval.  Meetings start late and end late, and to be honest, meetings are typically a waste of time. Events are structured, start and end on time, have a purpose, and dare I say it, follow a process or method.

2. Retrospective Length is Independent of Sprint/Iteration Length 

The time needed for a retrospective is independent of sprint or iteration length. For example, a four-week sprint does not require a four hour retrospective.  A one hour retrospective is enough time for a high-performing team to identify the handful of action items required to improve their future execution, regardless of the sprint length. An average team, on the other hand, may need up to two hours to help them build individual and team retrospective muscle memory.

To maximize the amount of work not done, a team only needs to gather data (what went well/ what didn’t go well) for five events (planning, standups/communication, sprint execution, review, and retrospective) and this can be done in as little as ten minutes—shorter with a well-practiced team.  Analyzing sprint execution (generating insights), conducting a root cause analysis, and developing action items (lessons learned) are where the team needs to spend the majority of the hour.

Consider this: a four week sprint will have more standups and more execution days than a one week sprint, but this does not equate to a 4x increase in the amount of time needed to gather data in a retrospective. A high-performing team should be able to glean all their learning points from a 2-6 week sprint within the span of an hour. Anything more is a disrespectful waste of the organization’s money and the team members’ time.

3. Retrospective Variety is NOT the Spice of Organizational Life

Boredom: “an aversive state of wanting, but being unable, to engage in satisfying activity.”  

The idea of trying out a new retrospective activity (game) so team members do not get bored is misguided. The perceived or actual boredom displayed by individuals or teams toward retrospectives may be (1) a result of the type of work the team is doing, (2) a lack of understanding of the retrospective activity and/or a failure to achieve actionable outcomes, or (3)  the fact that great retrospectives are hard as they challenge people to be open and honest—we also know that boredom is a result of being too challenged.

Let’s assume that knowledge workers are challenged each sprint or iteration and their work is not the source of the perceived boredom. How does changing the retrospective activity (game) address the averse state of wanting to be engaged in a satisfying activity? And if retrospectives are perceived as being too challenging, then why would one believe that changing the activity would pacify this root cause of boredom?

Consider these points if you continue to believe changing up retrospectives in the name of boredom is a smart idea:

  • Inconsistent retrospectives, in structure and/or frequency, lead to mediocrity. According to Jim Collins, “The signature of mediocrity is not an unwillingness to change. The signature of mediocrity is chronic inconsistency [1].”   
  • Repetition. Repetition. Repetition. Learning something new, awkward, and difficult requires some repetition. It takes a while to get used to opening up, being self-critical, and learning how to respectfully challenge each other in and out of a retrospective.   
  • According to Doug Sundheim, “Debriefing (Retrospective) is a structured learning process designed to continuously evolve plans while they’re being executed.”
  • Culture is a product of retrospection. Edgar H. Schein points out that “culture is the result of a complex group learning process [2].”
  • Innovation is a product of interactions, and common processes that accelerate those interactions are necessary. According to a recent McKinsey Quarterly article, “…innovation is a complex, company-wide endeavor, it requires a set of crosscutting practices and processes to structure, organize and control it [3].”
  • So not only will “variety” in your retrospectives not produce desired results, it will also have a negative impact on your team’s ability to improve.

4. The Two Most Powerful Questions in a Retrospective Are:

  1. What was the primary objective?
  2. Did we achieve what we set out to do? Did we achieve that objective?

Why are these the most powerful questions during a retrospective? Simple: alignment. If the team is not aligned, if individuals cannot succinctly restate the sprint objective, then we (organization, leaders, Agile Coach, Product owner, etc.) have failed to establish the necessary conditions for the team to become empowered [4].

With an aligned team, the answer to the second question should be binary (yes/no) assuming the primary Sprint objective is clear, measurable, and achievable. Moreover, the primary Sprint objective should be connected to the external effects on the economic system (i.e. business value) and not an internal measures of performance (e.g. ready stories, velocity, burndown, etc. ).

What Went Well? What Didn’t go well? What can we do better? These three questions are commonly used and thought of as a proven retrospective design or process instead of as techniques that are helpful in gathering data and deciding what to do. Caution,  a real danger exists when asking a team “What they can do better?” if they do not share a common picture of “What” happened, understand “How” that something happened and, more importantly, “Why” it happened (root cause analysis). In a later post I will go into more detail on how a self-similar activity used in strategy and product development (What-How-Why) can be a powerful tool in building action items in retrospectives.

5. Who Facilitates?

A lot of people look to the ScrumMaster or Agile Coach to facilitate a retrospective, and indeed, when a team is just learning how to conduct and participate in a retrospective, this is important. However, the retrospective should be viewed as a leadership episode, where leadership is valued over facilitating the event.  In complex systems, leadership “takes place during interactions among [team members] when those interactions lead to change in the way those [members] expect to relate to one another in the future [5].”  How members relate to each other in the future is directly connected to how a leader (a person in an actual or perceived position of some authority) establishes a safe environment during the retrospective (a leadership episode).

The Product Owner’s position on the team is better suited for establishing this safe environment as they generally have over 51% of the vote when it comes to the product vision and backlog. On the other hand, the ScrumMaster or Agile Coach are often contractors or viewed as event facilitators, protectors of the framework, thus making the crucial step of setting the tone (establishing psychological safety) problematic. Development team members are also great candidates for leading the retrospective and should be given the leadership opportunity when the team is comfortable with a proven retrospective process.  It is perfectly acceptable for the ScrumMaster or Agile Coach to coach whomever is leading the retrospective during the actual  retrospective execution and then follow up with a one-on-one retrospective using a self-similar process.

6. The Leadership Pattern within a Retrospective Should be Tightly Coupled with Leadership Patterns of Other Events

Iteration or Scrum events should be viewed as a whole and not as standalone parts of a system. Just as Scrum exists in its entirety, the leadership patterns of each Scrum event should be tightly coupled (have interdependencies) where the relationships among those patterns work together in some fashion. Combining an off-the-shelf retrospective game with an ad hoc planning process (the letting the team figure it out approach), for example, is counter to basic Systems Thinking.  Leadership patterns within system events need to be connected. How a team plans, how it conducts its standups, and how it executes its sprint must be connected to how the team holds its retrospective.   

To illustrate this point, consider Russell Ackoff’s example of taking the best parts from 450+ different cars (best transmission, best tires, brakes, cooling systems, belts, spark plugs, etc.,)  and trying to put those best parts together to make the best car. The parts do not connect and therefore you do not have a car, you have a mess. The proliferation of retrospective games, ones that are designed independently of other Scrum events, are the equivalent of those incompatible best parts – they only contribute to an Agile mess.

 

Brian “Ponch” Rivera is a recovering Naval Aviator and Commander in the U.S Navy Reserve. He is the co-founder of AGLX, LLC, a Seattle-based Agile Leadership Consulting Team, and a ScrumTotal Advisory Board Member.

 

References:

[1] Jim Collins, Good to Great: Why Some Companies Make the Leap…and Others Don’t (HarperCollins, 2001)

[2] Edgar H. Schein, Organizational Culture and Leadership, 3rd Ed. (Jossey-Bass, 2004)

[3] Marc de Jong, Nathan Marston, and Erik Roth, The Eight Essentials of Innovation. McKinsey Quarterly April 2015

[4] Senge, P. M. (1990). The fifth discipline: The art and practice of the learning organization. New York: Doubleday/Currency.

[5] Hazy, J. Goldstein, J, & Lichtenstein, B.B. (2007). Complex Systems Leadership Theory: New Perspectives form Complexity Science on Social and Organizational Effectiveness. http://emergentpublications.com/documents/9780979168864_contents.pdf?AspxAutoDetectCookieSupport=1

Agile <a href=”http://www.canstockphoto.com“>(c) Can Stock Photo</a>

Share This: