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:

High-Performing Teams: Four Lessons From the Blue Angels

What do Seattle area technology companies and the U.S. Navy Flight Demonstration Squadron (Blue Angels) have in common? Aside from the fact that Seattle’s tech community and the Blue Angels continue to “Crush It” when it comes to delighting their customers, there is a deeper, relatively unknown bond that connects Seattle’s techies to the six Boeing F/A-18s they will see performing over Lake Washington this weekend.

Software and business teams including those at Capital One Investing, Alaska Airlines, Amazon, Tableau, Expedia, Nordstrom, Microsoft, T-Mobile, Qumulo, REI, Starbucks, Boeing, Getty Images,  and Wikispeed are using Scrum, the complexity-busting, productivity super weapon inspired by fighter aviation to help them rapidly deliver products to their customers in today’s turbulent market.

So how does Scrum connect to the Blue Angels? That’s easy. According to Dr. Jeff Sutherland, the co-creator of Scrum, “Scrum is based on [his] experience flying F-4 Phantoms over North Vietnam.” Furthermore, Scrum is not about software development but is a simple framework designed to fight complexity. Dr. Sutherland recognized the cognitive challenges faced in the technical and near chaotic environment of fighter aviation are the same as those faced by knowledge workers. Just as the Blue Angels plan, brief, execute, and debrief each performance and practice, Scrum teams in Seattle follow the same empirical process in each of their sprints.

So what else can Scrum and other small teams learn from the Blue Angels? The list is long but here are four lessons to consider over this airshow weekend.

1. Unstable Systems (Teams) are the Most Agile 

The Blue Angels are not an unstable bunch, as far as I know, but the Boeing F/A-18s they fly are inherently unstable. Unstable aircraft are highly maneuverable (agile) but require a skilled pilot and onboard flight computers (a management system) to coordinate the movement of the various flight control surfaces during routine and dynamic flight. Similarly, according to the authors of Team Genius: The New Science of High-Performing Organizations, unstable or volatile teams (the central paradox of teams) are the most productive and successful when held together by a skilled leader [1].

Bottom Line: Diverse teams, when led by a skilled leader, are the most agile. 

2. Team Size

The two pizza rule made famous by Jeff Bezos is a nice heuristic to describe the ideal team size—usually around 6-8 people. The Blue Angels fly in a formation of six but have eight customer-facing core members whose combined appetite will break the Amazonian two pizza rule—naval aviators can eat a lot. The optimum team size, according to current research, is 5-7 members but effective teams have 4-9 members [2].

Bottom Line: The ideal team size is 4-9 members.

3. Pairing

Imagine losing 50% of your team each year…all at the same time. Will you be able to deliver at the same level your customers are used to?  At the end of this season, CAPT Tom Frosch, the current Blue Angel #1 and team leader will be replaced by CDR Ryan “Guido” Bernacchi.  In addition to having a new leader in 2016, the team will add a new #3 and #6 while the current #3 moves to #4 and current #6 moves to #5. So how does the team deal with this much change? They have smaller pizza parties.

Early in the season, before the team flies in a Diamond (four-ship) or Delta (six-ship) formation, the team will break into smaller teams, or pair-teams. Blue Angel #2 will coach his boss on how to lead the formation. Blue Angel #4 (the old #3) will coach his replacement while learning a new position. And Blue Angel #5 (the old #6) will train the incoming #6. By pairing, veteran team members serve as advisers and transfer knowledge to new members through open and honest criticism in and out of the debrief.

Bottom Line: Pairs are the “basic bricks from which the edifices of larger teams are built [2].”

4. The Power of Proper Debriefing

The most important event in any continuous improvement or innovation cycle is the debrief (retrospective).  At the end of each and every flight, the Blue Angels follow the same debrief process where they leave their rank and egos at the door and focus on what is right, not who is right. You will not find Post-it notes or a ScrumMaster facilitating their debrief. Instead, team members will follow the same proven debriefing process they have been using their entire careers. This complex team learning process (debrief) builds culture, team resiliency, and improves future execution.

Bottom Line: Learn how to conduct a debrief and stop playing retrospective games.

Conclusion

Fighter aviation has a profound influence on how Scrum and high-reliability organizations approach their day-to-day work. Unfortunately, some people who want to build high-performing teams using Scrum (or other agile frameworks) continue to deny or discount that the many lessons learned in fighter aviation can and should be applied to their practice. According to a recent BBC report, psychologists recognize that human behavior is the same across technical environments, and applying the lessons learned from aviation will help mitigate group cognitive biases in any organization.

Ready Break. Ready Roll.

Brian “Ponch” Rivera is a recovering Naval Aviator, a 2003-2004 F-14 Demonstration Team Member, 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] Rich Karlgaard & Michael  S. Malone. Team Genius: The New Science of High-Performing Organizations (Harper Business, 2015).  Pg. 74

[2] Rich Karlgaard & Michael S. Malone. Team Genius: The New Science of High-Performing Organizations (Harper Business, 2015).  Pg. 97

BBC report: http://www.bbc.co.uk/programmes/p02x3vwh

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: