My sister’s partner, Adam, recently shared the original Top Gun article that inspired the movie with me. It reminded me of my father. My father was a RIO in the F-14 in the seventies and eighties, and later taught at Top Gun. He passed a few years ago. I think about his life, his service to his country, and what, if anything, I can apply to my life. Despite being around him, visiting his office, going on “tiger cruises”, he didn’t talk much about how he went about his work.

The article mentions the debrief after the “bad hop”. I coach teams and leaders to build better software, and, I’m always on the lookout to borrow (OK, steal) metaphors that can give us more of an edge. Project, sprint, iteration retrospectives are often the highest leverage catalysts for change. However, I wondered if I could take some lessons from a pilot’s debriefing for this.

A 2015 HBR article by Doug Sundheim lays out the simple format of these reviews. https://hbr.org/2015/07/debriefing-a-simple-tool-to-help-your-team-tackle-tough-problems

There are four key questions:
1. What were we trying to accomplish? Start by restating the objectives you were trying to hit.
2. Where did we hit (or miss) our objectives? Review your results, and ensure the group is aligned.
3. What caused our results? This should go deeper than obvious, first-level answers.
4. What should we start, stop, or continue doing? Given the root causes uncovered, what should we do next, now that we know what we know?
[1]

The three things that really help me with these are:

1. Start with Objectives

The key part of this that is different from how I usually run sprint, kaizen, project retrospectives is starting with the objectives over starting with question 4. In Scrum, we start with the “sprint goal” so this is built in. If using a flow based model, the objective is something you need to be explicit about adding into your system. OKR’s can work, or a milestone, or an operations review. The key bit is starting with what you ALREADY agreed was the goal so that things don’t drift off into discussions on the meaning of life.

I’ve seen this often where we argue about what to change, and it’s only until we bubble up one level to discuss what we’re trying to achieve, that we realize where the alignment problem is. Is it Predictability or Innovation we’re after? If you don’t know, you’re not likely to solve it at the “Keep, Stop, Continue” level. If we can start from common objectives, we have greater chance of finding tactics to achieve.

2. Make it routine

The current program I’m leading, we stopped the cadence of the overall (cross team) retrospective. We experimented with doing them after standup, when there was time. Individual teams do it after planning, usually. However, we never ended up doing them. Now that we’re operating in a flow based model using a Kanban system, we identify tickets (features) that are challenged. The question is when to set aside time for debrief.

For pilots, briefing occurs 90 minutes before a flight. Debrief within 30 minutes after. Using the analogy of a post flight debrief, we could set a rule that whenever a feature is moved from “to verify” to “done”, we schedule a retrospective within one day. Or after the feature is live with data, we review.

On the other hand, as Don Reinertsen says, cadence helps lower transaction cost [2] making small batches economically feasible. So, if we schedule each debrief on demand, the cost of getting everyone aligned is higher.

So, now we are experimenting with retrospectives on a biweekly cadence with debriefs and post-mortems on demand. Stories are queued up for discussion, in advance (flowing off our kanban board to another board where we will have improvement meetings). I’m looking forward to what we learn from this. I expect we’ll have better attendance, however I also worry we won’t talk about the “good hops” that happened and why.

3 Make it safe

In the Sundheim article, he explains how the Army teaches you to “leave your stripes at the door”. Bourke in a similar article discusses how fighter pilots will leave off their name tags and rank insignia during debriefs. Why all this attention on safety? Not only is it good for morale, it’s essential to create a learning environment. In an environment where you are fighting for self preservation for your ideas, hide mistakes, and point the finger on blame, you won’t learn. Your lizard brain will take over. As the two year project Aristotle showed at Google, creating psychological safety also correlates strongly with the highest performing teams at Google.

So, in the valley where your boss is already wearing flip flops to work? One thing I do is to borrow a trick from Henrik Kniberg from Lean from the Trenches. He moved his retrospectives to a room where there were only chairs and a whiteboard, no conference room table. [4] It’s strange but it seems to help reduce the finger pointing. The second thing I do is to remind people at the beginning of the meeting that it’s about the process, not the people.

If the folks are new to this, an explicit exercise might be in order. I’ve run secret straw polls ala Ester Derby and discussed Norm Kerth’s Retrospective Prime Directive in pairs. You need to be aware of how much safety is in the room, how much power distance exists and adjust your approach accordingly.

I would not be where I am today if it were not for a few key people who took time out of their busy schedules to help me in my career. Some of them helped me when I wasn’t even sure I needed help. Some helped when I knew I needed it. I would guess that most of them had a deep seated–almost sacred–calling to grow and develop others. They did not do it to help themselves or further their career.

In a world where we are obsessed with “what’s in it for me” mentorship is clearly different stuff. Sure there are the much touted “teach a man to fish” or succession planning benefits. While these benefits probably exist, I know intuitively when someone is taking a fake interest in me. Humans can sniff out disingenuous motives like BO in a movie theatre. If people are changing jobs every 2-4 years, the motive for developing someone need to come from a long term intrinsic motive to help others, because you find joy in this. Or else it’s easy to be disheartened with developing others when the person you mentored leaves for another company.

A couple of years ago HBR published an article about gender imbalances in top jobs at corporations. They discovered the missing ingredient was not mentorship, or coaching, but sponsorship. This means someone who is not trying to improve you, but someone who will advocate for you when you are not there. Who is your advocate?

So when you are looking to grow or learn something new in your career, it is important to pick the right mentor. But how do you go about it? It’s a bit like dating. You want someone you respect, someone you trust and someone who likes you back.

Some questions to ask yourself:

Who is doing what I want to do? Maybe 5 years from now.

Who shows an interest in you? Who listens to you?

Who do you respect? Who inspires you?

Who has a record of following through on little commitments (showing up to meetings on time, doing what they said they would do?)

Make a list of four or five people.

Next, you need to see if they are interested and available to mentor you. This is a bit like asking someone out on a date. Most successful people are more than happy to help out someone else. But they may not be aware you have this desire. The thing I’ve done usually is take them out for dinner and ask them to tell me about how they have gotten where they are. Be curious. Ask what books they read. Ask who mentored them. Be natural and friendly, as an equal not a subordinate. Then when they give you a suggestion, like read this book or talk to this person, follow up and schedule a meeting to share what you have learned.

How about you? Who has mentored you? How did you end up in that mentor/mentee relationship?

To coach someone (or yourself) to learn the Toyota Kata, there are 5 simple questions.

1. What is the target condition?
2. What is the actual condition now?*
3. What obstacles do you think are preventing you from reaching the target condition? Which one are you addressing now?
4. What is your Next Step? (next PDCA/experiment) What do you expect?
5. When can we go and see what we have learned from taking that step?

* Ask these questions to reflect on the last step, because you don’t actually know what the result of a step will be!
1. What was your Last Step?
2. What did you Expect?
3. What Actually Happened?
4. What did you Learn?

These questions are designed to help line managers learn to apply the improvement kata in their organizations. The benefit of applying the improvement kata are more adaptability for your team, an ability to create new solutions to unforseen problems. As a ScrumMaster or manager, you can ask these questions every morning at standup, using a visual control like a Kanban Board or a Card Wall to evaluate short cycle experiments.

The reason I’m excited about the Coaching Kata is that I think in the agile community we are stuck in the “tool age”. As coaches, we look to things like Lean Startup, Business Model Canvas, Kanban, SAFe, Innovation Games, Cynefin as “the new innovation” that will keep us relevant with our clients (and well fed). We copy a solution what another consultant is doing, not understanding the thinking process they used to develop that solution. The solution might not fit the context. I fall victim to this thinking. It’s the hammer in search of a nail that Weinberg warned us about.

And as coaches we often accuse our teams and clients of applying “cargo cult” agile practices, standups, tdd, atdd, copying each other’s practices, but not understanding why they are doing them. Then we wonder why we hit a wall with our agile adoption efforts. This is a problem because we also see teams not get the sustained continuous improvement from agile methods. They have gotten an initial sugar rush of improvement by doing something new. A hawthorne effect. By studying the team, you see an improvement. But after that, they hit a new plateau of performance.

In the lean transformation community, they have a similar problem. A factory will install lean tools like just in time manufacturing, andan cords and kanban systems. They deploy lean problem solving tools like kaizen workshops, value stream mapping, A3 problem solving reports, and standard work. But the real change is modest or not observable.

Is the answer then to eschew any new idea, to “go it alone” and develop everything custom? How will this scale? For the answer, I look again to the lean manufacturing community.

In recent years with work by David Mann in Building a Lean Culture and more recently Mike Rother, the Lean community realizes that it’s not enough to deploy some tools to achieve sustained improvement. You need to change the thinking that managers and team members. How do you change someone’s thinking? Enter the kata.

A kata is a pattern, routine or habit. Originally from martial arts, it’s about training your brain and body to automatically respond in a specific way. By practicing the routine, you get create new neural pathways that reinforce behavior. By practicing the improvement kata daily, you get to change your behavior, which changes your thinking.

Is there a danger that Kata will be the new practice or flavor of the month consulting offering? Yes. How do we avoid this in ourselves and our teams? Don’t sell the “kata”. Instead, encourage you and your team to develop a daily habit around asking coaching questions, directed toward a common challenge or vision, and build in visible and observable feedback loops using experiments to get better.

Arne Roock developed the Kanban Kata as a way to do this with Kanban Systems. The same with double loop learning, OODA loops, etc. Applied in the same spirit of curiosity and exploration, it could achieve the same result. You are using the scientific method to improve your ability to improve.

In Mike Rother’s Toyota Kata, he describes the approach that managers and executives have towards PDCA as a management system. Quote:

“If we assume that at any time anything we have planned may not work as intended, that is, that it is always possible that the hypothesis will be false, then we keep our eyes and minds open to what we learn along the way. Conversely, if we think everything can work as planned, then we too easily turn a blind eye to reality.”

This describes the difference to how traditional management looks at any improvement program like Lean or Agile, and how Toyota views it. Traditional management tries to control our adoption of Agile or Lean and “install” the process for improvement, expecting that it will go as planned. In Toyota, they expect that there hypothesis for improvement could be wrong. This informs their attitude towards setting targets, goals or any hypothesis. It’s similar to how Ries views validated learning in “The Lean Startup”. It’s possible that your hypothesis in your business plan will be disproved, which is why we measure our progress with validated learning. This stance towards learning or knowledge is a fundamental shift. And I find I need personally to challenge myself each day to really observe. To go and see where work is done. To be a learner, not a “knower”. As Ohno said:

“We are doomed to failure without a daily destruction of our various preconceptions.”*

In one sense, this is extremely difficult, unnatural. We are taught through our professional lives to credentialize ourselves, to establish our knowledge and rightness of our plans. To assert control. And in another sense, it’s very familiar and natural to return to a childlike wonder and awe of the world around us. My son reminds me of this. He is a natural scientist and explorer, always asking why. Always testing his hypothesis, whether a spoon will fall on the floor for the thirty third time at breakfast, or how a leaf tastes. We are natural explorer’s and scientists. So, what is keeping you from a positive attitude toward learning and exploration? How can you remove those impediments? Any ideas out there?

Massive budget and schedule overruns continue to plague business and government projects alike. Flyvbjerg and Budzier’s recent research published in the Harvard Business Review shows that among the 1400 projects surveyed, on average they were 27% over budget. Even more alarming, 16% of project had massive overruns, what they call a “black swan” with a cost overrun of 200% on average and late by 70%. These are projects that can cause stunning failures in already troubled companies.

An example discussed – Kmart undertaking an “IT modernization project” costing $1.4 billion in 2000, then realizing that it was so highly customized as to be cost prohibitive to maintain. They then ran a $600 million supply chain software project in 2001 – which they pulled the plug on in 2002 – both contributing to Kmart’s decision to file for bankruptcy.

These reports mirror similar data from the late 90′s when Standish published its original CHAOS report, oft cited by Agilists. Depressingly, the 2009 CHAOS report shows an even more dismal trend of cost/budget overruns.

Why, in the last 15 years, why has the industry not gotten better at delivering large IT projects? Large is a subjective term. Let’s define that in dollars for now, say anything over $10 Million dollars. To answer that, the key may be in the projects studied.

Most of the projects studied by Flyvbjerg and Budzier were government projects (92%). However, they claim the results were mostly the same between them and private company IT projects they looked at. So, it’s probably not only due to the massive incompetence by our fellow technologists in Government that are the problem. From the article, it appeared most of the projects were IT replatforming projects, for example – installing COTS software for existing in house solutions – Oracle, SAP or a CRM system. My theory is that it is these very large re-platforming projects that are frequently the issue. They touch so many systems, so many discrete business units involved across the globe, and the desire to do customization so they become impossible to upgrade.

Now, there may be good reasons to replace a creaky platform, as Jonny Leroy puts it, but the way you do it is just as important as the business justification. One pattern we use at ThoughtWorks is the Strangler Pattern, where you slowly replace the existing application with a new application, to avoid a spectacular project failure.

An example from the article of a successful project by the Emirates bank in 2006, shows a successful way to run a large complex project. This was a project to replace the banking back-end with an upgraded system. The project was threatened to go off the rails when the bank merged with National Bank of Dubai, and they had to work for both banks.

The lessons learned from this successful project were to:
1. Stick to schedule
2. Resist changes to the projects scope
3. Break the project into discrete modules
4. Assemble the right team
5. Prevent turnover among team members
6. Frame the initiative as a business endeavor, not a technical one
7. Focus on a single target – readiness to go live, measuring every activity against it.

Many of these are hallmarks of good Agile projects. Break a large project into smaller pieces, stay focused on your release criteria and make sure that you are solving a business problem, not a technical one. Number two may strike us as an Agile faux pas, not allowing change in scope, but I believe the authors are referring to “Mission Creep” rather than changing featues in a requirements spec. Drifting missions or just unclear goals strikes me as a hallmark of any unsuccessful endeavor.

I recently had to put together a presentation. While I enjoy putting together presentations, sometimes I forget that I’m not the audience. While my technical knowledge of how to conduct a meeting, plan an iteration, or hatch an evil plot to take of the world may be fascinating to me, if those listening don’t know what’s in it for them, they may rather eat a spoonful of sand than hear me talk about it.

That’s why I like to refer back to Presentation Zen often to make presentations that are engaging, relevant, and don’t make my audiences want to stab their eyes with a fork. Here is the list of questions from the book that I find very helpful, from the book, to help focus my presentations:

1 How much time do I have?

2 What’s the venue like?

3 What time of the day?

4 Who is the audience?

5 What’s their background?

6 What do they expect of me?

7 Why was I asked to speak?

8 What do I want them to do?

9 What visual medium is most appropriate for this particular situation and audience?

10 What is the fundamental purpose of my talk?

11 What’s the story here?

12 And this is the most fundamental question of all. Stripped down to its essential core: What is my absolutely central point?

Leader standard work is a concept in Lean Management, popularized by David Mann in his book “Creating a Lean Culture”, that creates standard work for managers. For many in the Agile community, the notion of “standard work” brings a repellent idea of standardization and work standards, and the oppressive boot-jack command culture that comes with that. And yet, the way that Toyota implements standard work, it is much more akin to coding standards or working agreements, where you record the current best agreed upon way of the workers in the system for doing something, than an oppressive regime of McQuality Checks.

Soul Crushing Bureaucracy It's Not

David describes the principle nicely in his presentation on Creating a Lean Culture Process Focus and Leader Standard Work. The purpose of Leader Standard Work is to create behavioral change that drives Lean Leaders to visit the place where work is being done. This, along with Visual Management and a Daily Accountability process helps ensure the technical improvements in the Lean Transformation aren’t lost to the culture of firefighting and backsliding into what he calls the “pit of instability and despair” or what I like to call, “business as usual.” So, there are many organizational benefits to Leader Standard Work. And the good news is, it’s also a great way to drive some sanity into your day as a manager.

The way it’s implemented is by a handy one page sheet of paper that has checklists on tasks and audits that you do as a manager in your daily routine, in addition to a space for notes on abnormal conditions and countermeasures. I’ve been using this personally for the last few months and it’s been very helpful for me to make sure I check on schedules and due dates for upcoming workshops. It’s also a good place to note things I need to bring up with my manager and team in the daily kickoff meeting (think daily standup with more of an exclusive problem solving focus).

So why bring this up in an Agile Project Management blog on Daily Standups? Simply put, this form of discipline has enormous potential for driving out Daily Standup Withdrawal that Stacia Broderick discussed some years back. In years past, I would see my role as a ScrumMaster as asking the right questions in Standup to bring out the impediments and record them. While this is good, wouldn’t it be better to have discovered the impediments before the standup? What if the impediments were discovered and noted before the standup? What if we had a cut on the initial root cause analysis was done on why they existed? I’m sure it would be too much to ask for a proposed countermeasure, too? This is easily facilitated if given the supporting structure to ask the right questions, and come prepared to standup with some initial answers.

The more I’m exposed to concepts of Lean Management, the more I feel these are the missing ingredient the servant leader role of ScrumMaster. While it’s great to be a facilitator, it’s even better to be a facilitator who has been to gemba, the place where the work is done, and knows what the current state is and where we are according to our plans. Now, this doesn’t mean they don’t empower the team to understand what’s going on and propose changes themselves. But think of how much better their questions would be if they have already seen and thought about the problem at hand

Think of a ScrumMaster or Iteration Manager who has their standard work of checking the burndown chart, updating the defect aging report, creating the invitations for retrospectives and printing more story cards. Wouldn’t this make it easier for the ScrumMaster to serve the team, and to notice when there is something wrong? Also, wouldn’t it make it easier for a new ScrumMaster to step into the old ScrumMaster’s shoes, instead of it being some mystical rite of passage that occurs in a CSM class or in daily knife fights on delivery projects? to rely on that person to serve them.

At the last Lean Software Meetup, Jeffrey Fredrick quoted a line in David Allen’s book Getting Things Done book that stuck in my mind: “Decisions not made cause stress.” As someone who has been on and off the GTD wagon for the last 4 years, this made sense to me. And yet and as one who practices Lean thinking, this has been causing me some degree of a dilemma, as a core Lean principle is deferring commitment. Maybe you can help me sort this out.

The idea of Allen’s book is that there are many open loops in your life. You may have 503 email messages laying in your inbox, a garage full of boxes from your last move, a shoe box full of story cards from last week’s user story workshop, (and my personal favorite) a large heap of easel pad paper with multiple facilitation sessions worth of stuff. What causes you stress is not that you have this stuff out there, but that you haven’t decided what you want to do with it. In GTD lingo, it’s “unprocessed stuff”. Each time your mind “reminds you” about this stuff, it causes you stress, because you haven’t decided what you are going to do it. Like rubbing a cancer sore in your mouth, it causes a little bit of psychologically resistance each time your mind passes over this stuff. You’re mind says: “You need to decide what to do with your mountain of junk in your garage.”

Once you recognize this as a source of stress, then Allen advocates making executive decisions about this stuff so that you can live more flexibly and responsively to new input. There is a process of capturing and making decisions in handy flowchart that appeals to my inner geek. More than just putting more systems in my life than are necessary, it generally makes things better for me. This is especially true for me given my tempermant.

Four years ago, I was a stressed knowledge worker. I had a high volume of incoming stuff that caused me a lot of angst. I adopted GTD and things improved. What gives?

Personality Typing, such as Myer’s Briggs, gives some insight. As a type Perceiving (INTP), I tend to be more comfortable when options are open. Those who are Judging temperments (not judgemental) tend to feel comfortable right after a decision is made. I recall a recent example where a colleague of mine who I suspect is a J, was very tense before a decision was made on the CMS decision of choice. When the decision was made, he was very relaxed, congenial. So, it may be that for the types J, they are stressed at unmade decisions. Those with personality preferences P, like me, are stressed when I’m forced to make a decision, which causes me to put things off.

Therefore, as a P, Allen’s book represented a light at the end of a tunnel for me. Suddenly I was making decisions about my voicemail messages, my overflowing inbox and personal life with ease, before it got too late. While this was a little unnatural, that dentist appointment was scheduled, the conference booked, the retrospective occurred without a hitch, my mother was phoned and happy. And much of my angst over email was no longer plaguing me, thanks to inbox zero. I was generally getting more of the administrivia done in less time than I used to so I could focus on the stuff I loved.

Are you committing too early?

OK. So this has generally been a net benefit for me personally. But what about this the lean notion of deferring commitment, last responsible moment, real options, etc? This concept is essentially the idea that it’s unwise to close off an option early, because options have value. Like a pilot who is flying to Ohare during a snowstorm from Seattle. She knows that the last responsible moment is when she is over Denver. Deciding early to divert to Detroit is unwise, because things may clear up. Your passengers would value making their other connections. But deciding after Denver would be unwise, “the last irresponsible moment” because you are committed to one action or the other. Options have value and exercising them early causes you to loose potential value.

Does GTD and the habit of deciding before you have to, cause me to make poor decisions in the here and now for the benefit of feeling less stress, when I could be better off delaying those decisions when I had more information? Does this occur in boardrooms all across the US where management make decisions because of the generally accepted principle of “no decision is worse than indecision.” Or in teams for that instance, where we make decisions on API’s, languages and databases too early, because having an unmade decision was causing our management britches to get in a bundle. What’s a girl to do?

One faint glimmer that comes to me is the idea in Allen’s flowchart again. Not all decisions are the same. There are the 2 minute actions that you can quickly dispose of, like a “thanks” email or a “Yes, I will be home for dinner”. And there are those things you can delegate (either up or down). Taking a moment to decide that you don’t have to decide is a net benefit. And what about those decisions that may not be appropriate to make now? The important thing, he advises, is for these decisions to be deferred in calendars, tickler files or other trusted systems so they can be evaluated at the appropriate time. This could be done for conference deadlines, dinner plans, or deadlines to place orders for hardware for your new load balancer. As long as you will be certain to revisit that decision at that time, and your information is correct on when you need to revisit the decision, this type of thinking could reduce stress and simultaneously defer commitment, enabling you to make decisions when you have the most information.

Will this cause you to lower your anxiety about unmade decisions? Maybe, maybe not, depending on your temperament on the P/J scale. Will it cause me to justify my natural tendency to delay what I need to do, aka the student syndrome, cauing me more long term stress? I think that as long as you give yourself a reasonable buffer and use your trusted systems to remind you when you have to decide (whether it is a physical tickler file, or an iphone alert, or a google calendar event), it shouldn’t.

What do you think? Have you had a situation where you had less stress and made better decisions by deferring commitment? Or have you had a situation where it paid to make decisions early, before the last responsible moment?

Esther Derby tweeted a great question that stuck in my noodle the last week: estherderby: skimming Good to Great. some profiled companies ain’t so great anymore.

Since Good to Great provided great inspiration for me, this caused me some consternation. Circuit City, Fannie Mae, and Wells Fargo aren’t doing so well. Turns out, Esther isn’t the only one asking this. As Peter Levitt (of Freakonomics Fame) asks, and blog author Peter Galuzska points out, it’s not exactly fair criticizing Jim Collins for things that happened 8 years after he published his book, since he was looking at historical market performance. True, but makes you wonder at taking the advice in the book.

Good to Great analyzes 11 companies that had average stock returns, and then had a dramatic jump in returns after a certain inflection point. It analyzes them for patterns in the data and comes up with a number of principles for what catapulted them to greatness including: level 5 leaders — leaders with personal humilty and great professional will; a hedgehog concept — focus on the intersection between the three circles of what you are best at the world at, what you can make money doing, and what you love; turning the flywheel — iterating on your plan so that you evolve into greatness; the stockdale paradox – having absolute faith you will survive and simultaneously confronting the most brutal facts of your current situation. Then I recalled that what Jim Collins states at the end of the book is that what may take your company from good to great is not what will make it an enduringly great company.

For those, he points to the Built to Last book principles:preserve the core ideology and stimulate change, create BHAG’s (Big Hairy Audacious Goals) — like the 747 at Boeing; don’t tell time, build clocks — build a lasting organization, having a core ideology other than maximizing profits – like 3M’s innovation culture or Nordstrom’s cultlike focus on customer satisfaction. These businesses from Built to Last are still enduring, not all are great…but they all endure. I wonder if Circuit City and Fannie Mae had followed these principles if they would have survived. Did Circuit City not follow its core ideology when it fired all its senior sales people and replaced them with people who knew nothing about their products? Or was Fannie Mae the victim of the unforeseeable challenges in the lending market?

It’s hard to know without doing original research of what went wrong. That is one of the great things about these books is that they are built on rigorous research. This is unlike many of the avalanche of business books based on success stories that have little or no data to back them up, like Who moved my cheese. Some have rightly argued that they suffer from selection bias, selecting the winners from a group of companies and finding what was common about them, while not looking for those same factors in the businesses that failed. Yes, this is true, and is the challenge with any research where you are trying to uncover causality without using the scientific method. It’s hard to create a true scientific test when there are human lives at stake. All you can do in the real world is experiment, see what works, and then measure your results. Hmmm…this is starting to sound a lot like Scrum to me.

So what does this have to do with Software Project Management? These books provide useful ideas of what you can do in your organization with teams to get unstuck. For instance, it gives you a lesson for how great leadership behaves to encourage greatness. A level 5 leader looks surprisingly like a servant leader in Scrum (personal humilty and a high degree of professional will). Or building a core set of values that you don’t change and experimenting with everything else (like adopting team values in your project charter ).

So, while the underlying research may be called into question, the ideas in these books stick, because they make sense, because they are sometimes paradoxical, and they are based on some research. I wonder what a similar research project would be like for Software Projects? Is this analysis similar to the Chaos report, where researchers look at common factors for failed and successful projects and try to isolate those factors? If we wanted to study what a successful project was what factor would we use to measure success? We couldn’t use market returns. Traditional measures like “on time, on budget on scope” also fall flat, as projects where that was the case, called challenged projects, are often a market success. What do you think?

Here is a very clear blog article by Chris Sterling outlining the rationale behind capturing and assigning actions for impediments at the daily standup. He explains the connection to the continual improvement philosophy of Kaizen. Spot-on, Chris.

We’ve used this technique in teams I’ve worked with, along with longer bi-weekly retrospectives to drum up the individual, team and organizaitonal impediments that stand in the way to high performance. This is a way to radically improve their team performance and mitigate risks early in a project. Whether you don’t have a continuous build system or a team member is out due to an emergency medevac for his pet poodle, these things all deserve space on the impediments wall. By making the rule that there must be at least one impediment a day, and by assigning impediments to individuals for daily resolution you drive accountability for continual improvement to the members of the Scrum team. It also builds trust with teams for the ScrumMaster, that you are doing your job in clearing roadblocks for the team. I encourage all Scrum teams to capture their impediments at daily standup in this way.

Peter Gibbons and his pals 'actioning' an impediment.

This part of your daily standup should feel energizing. You should leave feeling like things are being done, like in some small way, things are better. It should not feel like a catalogue of all the ways your team and organization suck. You may recall the office space scene where they take the life-sucking fax machine to the field and beat it to bits. It should feel like that. Like you are liberated and empowered to remove these obstacles today. (Note, I don’t condone violence to ‘human impediments’, they must be resolved in a different way.)

A way to consider this is to focus on the next action needed to resolve your impediment. List the next physical verb step on your impediments wall that you need to do in order to eliminate your impediment. Do you need to go to Boeing Surplus to buy cheap hardware? Do you need to get an appointment with the CEO to lift the travel restriction so your test team can have face time with your dev team?

Pay close attention that you are avoiding all yak shaving activities. It’s better to do something OK today than do something perfectly tomorrow. This applies to impediment removal also.