Subscribe via RSS Feed

Tag: "lessons learned"

Are You Holding Back Your Team’s Success?

Damaged WallRecently, I hooked up with a friend and decided to do a 3-day hike on the Appalachian Trail.  As part of our preparation, we decided to try a day-hike in a State Park near our homes. We took this trial quite seriously and even planned how to mentally and physically prepare for the day hike.  I won’t bore you with the details, but the day we set out for the hike, we were pretty psyched.

We did 8+ hours on the trail, walking up and down paths that burned our legs by the end of the day. In the last hour or so, when were truly coming to our “wall of tolerance”, we kept repeating to each other how fortunate we were for all the planning. Had we not trained for this or lacked  the right supplies, we would have never lasted the day. Without a doubt, doing the day hike before setting out on our 3-day hike out east was the smart thing to do.

We focused on setting ourselves up for success.  And even with all the planning, we still learned a lot about what to do differently on our next day hike.

Learning From the Hike…

I can only imagine how painful that day would have been if we didn’t work our way up to walking an entire day of 13+ miles.  Or what would have happened  if we only had half our water ration (we used it all).  It would have been one embarrassing, failure of a hike.

This is a far more common scenario than any of us realize. When we start a new project, we typically overlook fundamental / key things that would set us up for success.  We may actually be holding our team back from the start.  And because of that, our team  may be digging out from this “team debt” for the majority, if not all, of the project.

Hold Up There

If you don’t agree, let me  give you just two common scenarios  that prove my point:

  • You  are starting a project. The  team is staffed and eager to move forward. The technical team is building out the environment and frameworks.  The Business Analysts are ready to collect and refine requirements, but are struggling to get the needed time and commitment from the business.

This not only causes churn for the BAs, but typically squeezes the schedule during the initial coding activities, with incomplete requirements and test plans.

  • Another example: You  are staffing up a project quickly so you can hit a set of aggressive dates for the business.  In doing so, you need to procure development environments and machines for all of the developers. However, due to an overworked infrastructure team, or worse, due to corporate processes, a third of the team may be without development hardware and tools while they wait for their stuff.

While they find other activities to do while they wait, this literally amounts to two or three weeks that could have been spent on actual deliverables.

These are just two common examples. You could probably start listing off a couple more.

What Are They Thinking?

So when this happens, what is management thinking? Are they intentionally setting a team up with an obstacle? Do they simply not care and assume we can adapt?

I believe that in most cases, management simply doesn’t realize that the team is being put into this position and the cost is more than a slow ramp-up to the project. I, myself, have asked teams to “see if they could work around some obstacles”, clearly not realizing the pain I may be introducing, not just short term, but to the long term success of the team.

So What Are We To Do?

I think one of the most basic things we can do in these situations, is to be vocal.  Share your clear and honest explanation of what the cost and impact is.  It is important to be accurate and not embellish or magnify the challenges.

For example, let’s say you have a project starting and are scheduled to collect requirements for the first deliverables during the week of 11/01.  Your  goal is to have the requirements and test plans completed by 11/15 so the developers can begin development.

If the business stakeholders are not available as needed the week of 11/01, I think it’s important to point out that development may not start until 11/22.  This is because the test plans won’t be complete and the requirements won’t be clear enough (the normal clarification won’t have happened).

If you can clearly show the cause and effect, management should take ownership of the cost and impact of these situations. If we can show them the cost in terms of dollars or in terms of schedule, then you have the best shot of setting your team up for success and getting management to own the challenges.

What do you think?  Have you found other approaches to help set teams up for success?

What Elephants Teach Us About Software Development

The Blind Man and The Elephant

SONY DSCSo there’s a treasure trove of stories and metaphors that revolve around elephants, and lately in my work with Geneca, I keep on running into elephants.

One of my favorite elephant stories that I’ve been coming back to lately comes from several sources in Eastern Philosophy: The Blind Men and the Elephant. In this story, several blind men encounter an elephant. One touches the ear and says the elephant is like a hand fan. Another touches the trunk and says the elephant is the branch of a tree. The one who touches the leg believes the elephant is a pillar and the one touching the tail believes the elephant is a rope.

This metaphor tells us that different people with different roles and perspectives will have different ideas of what the “whole” is. This reminds us that on projects, since each person can’t see the whole, we have to have good communication with each other to understand what the whole really is. And this leads me to the next metaphor that I keep running into:

Getting in the Elephant Habit

When I listened to “Last Lecture” by Randy Pausch, a Professor who had cancer and was delivering the last and most important lecture of his life, I was struck by the technique he used to address the most anxiety-producing topic in the room. What he said was: “My dad always told me, when there is an elephant in the room, introduce them.” Then, he goes on to talk about the fact that he has cancer, which everyone knows, but nobody wants to talk about.

To deliver software predictably means to always be introducing the elephants in the room. When there are things that everyone in the room knows about, but no one wants to discuss – politics, friction between team members, risks, difficult decisions no one wants to make — it is our duty as the predictable partner to introduce these elephants.

One of the best practices of predictable software delivery means that we are speaking the same language as our client, apples to apples, oranges to oranges. Because we are the predictable partner, and because we believe in the best practices of predictable software delivery, we need to step up and introduce the elephants in the room, even if it is difficult and perhaps risky to do so.

I’ve noticed that the first time you introduce an elephant in the room, it is not well received. It is as though you have disturbed a social norm. It makes people uncomfortable. Often the first elephant I’ve introduced is the friction between two members of a team. Everybody has noticed it, but everyone has consciously or subconsciously decided to accept this friction that negatively affects the team, rather than face the uncomfortable moment of calling it out.

What I’ve found is that after introducing the first elephant, the second becomes easier. After the second, the third is expected. After the third, people have adapted to this behavior, and even begin to call out elephants they see. It becomes a habit, a part of the team culture. And having a team culture of calling out the issues rather than sweeping them under the rug is what being a Predictable Partner is all about.

Next week, I’ll talk about what we can learn from elephant behavior and how that can be applied to software development.

So, can you learn to adapt, or will you go extinct?

Photo Credit: Martien Uiterweerd

100 Missed Learning Opportunities a Day: Trim the Fat from “Knowledge Management.”

fireflies-in-jar-smOn teams of all sizes many lessons are learned each day, some big, some small. An “I-wouldn’t-do-that-again” happens here, or a “who-knew-it-would-be-so-easy-if-done-that-way” happens there.

These little lessons are fleeting and likely often go unnoticed even by those experiencing them. Like fireflies, they flash and they’re gone. When and where another insight will flash next is anyone’s guess.

The Benefits of Shared Wisdom

Many of the the “whys” of capturing and sharing lessons learned are obvious:

  • Leverage the expertise of people across the organization
  • Facilitate and organize the innovation and organizational learning process
      Help solve huge problems
  • Manage intellectual capital that may otherwise sit (and stay) in key individuals

Think of the most useful tool or method you’ve discovered for getting yourself organized. Now, realize that everyone else on your team has learned something similar, or better, or even synergistic making the value of your combined ideas a huge intellectual asset for the entire organization.

If teams could get to the point where identifying and sharing these bits of value became second nature, and it could be done at little or no cost, wouldn’t it be worth a try?

You know when you find it
In your darkest hour, you strike gold
A thought clicks, not the be-all end-all
Just another lesson learned…
— Alice in Chains, “Lesson Learned”

Why Capturing and Sharing Seems so Hard (And How to Overcome The Barriers)

Over the years I’ve been to many Project Retrospectives. Some resulted in useful information leveraged in future endeavors while others resulted in nothing but bellies full of pizza. So what makes some of our efforts stick and others not?


The way we think (or not think) about lessons learned often keeps us from identifying, sharing and leveraging them. To better understand how to get to the point where sharing ideas becomes natural, let’s look at some typical mindsets about knowledge sharing and what we can do to change them:

1. “I haven’t really learned anything here.”

Obstacle #1 in capturing and sharing a lesson learned is not seeing the lesson in the first place. If we wait for light bulbs to shine and sirens to wail, we’ll continue to hum along in our own worlds and keep all the good stuff to ourselves.

How can we start seeing the small stuff? Try this exercise. Keep a notepad next to you (dedicated to this task) for a couple days and take notes:

  • If you’ve been stuck and suddenly are making progress, think for a moment what got you rolling.
  • If you’ve had anxiety and suddenly feel relief, note what allowed for your change in state.
  • If you’re feeling particularly excited, motivated or happy about your work, note what it is you’re doing and think how you can bring that perspective to other areas of your work.

2. “My lessons learned aren’t new or unique.”

Individuals often neglect the unique perspective they bring to their work and therefore the inherent value in their particular learning process. The path down which we travel toward discovery can be as enlightening to others as the discovery itself.

  • Think about what you do outside of work that engages, excites, and motivates you (eg. fishing, tennis, video games). Now, think about how those activities influence the work you do. Write that down. Share it with someone.
  • Don’t censor. Write down all your lessons learned, your insights, your ideas. Others are likely to find value in more of those insights than you think.

3. “No one really cares about or has time for these.”

Most people enjoy learning and sharing what they know. But when teams assemble to do important work, people get busy. If a task isn’t considered critical to the activity at hand, that task is very unlikely to get any “CPU cycles” dedicated to it.

  • Get everyone on your team to do these exercises for three days. At the end of those three days, share the results with each other.
  • Do it again.
  • Then, work together to identify a means by which you can make this a part of your routine. Put it on the weekly meeting agenda, or make it part of your Daily Stand-Up Meeting.

4. “Why bother?”

We’ve all seen great initiatives kicked off with great intentions and high energy. However, without the right leadership, tools or motivation, the initial fire that burns strong and fast will soon fade to a hint of smoke that reminds us of its one time existence.

A vision for growth, development, and learning at an individual, team and organizational level is important, but it requires support and nurturing.

  • As leaders, encourage your teams to do these exercises. Take part in them as well. Repeat.
  • Share the results of these exercises with those around you, and ask other teams do the same.
  • Identify tools that may make this easier. They them. If a tool isn’t easy or can’t be incorporated into your routine, discard the tool and try another.

5. “I learned something, but at the result of screwing up. I’m not sharing this!”

Lessons learned are often born out of mistakes. It takes a very safe environment not only to share the lesson learned, but to bring to light a mistake large or small that may otherwise go unnoticed.

  • As a leader, create the safest environment possible. View mistakes as investments in education. Encourage the sharing.
  • As a team, aggressively identify obstacles. These obstacles are a safe context in which others can offer prior stumbles and associated lessons learned.

Making it Happen

Understanding this wisdom management as a two-step process can keep it simple for you to get off the starting block. The two steps are to Produce (identify and share) lessons learned and Consume (leverage) lessons learned.

In order to successfully Produce, there are two ingredients:

  1. Immediacy – Get in the habit of identifying lessons learned and make it easy to capture them as they happen.
  2. Motivation – Make it part of the routine and an expectation of each other.

In order for Consumption to occur, the two ingredients are:

  1. Visibility – Find a highly trafficked place online or off-line to collect the lessons learned.
  2. Relevancy – Group them, highlight them, revisit them regularly, identify where they have relevance to the work you’re doing today.

I hope this gives you a handful of ideas to get started on leveraging collective wisdom – ideas that don’t require an expensive knowledge management tool.

Photo Credit: Bryan Rosengrant

What practices do you employ on your team to identify and share lessons learned?