The Daily Standup

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.

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?

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?