Subscribe via RSS Feed

Tag: "obstacles"

Delivering Successfully is like the Matrix: It’s All In Your Head

matrix-300x269

In this blog I usually  write about best practices that help set teams up for success. That is really what Getting Predictable is about.

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?

Is Your Software Development Team Set Up for Failure?

Obstacle - Man Jumping Over Word on ArrowI talk to CIOs all the time and I can tell you that there is one common concern keeping them up at night:  Am I getting the best RPM out of my team? Often the answer is no.

Unfortunately, many of the teams I’ve worked with are continually frustrated because they truly, legitimately feel they are being set up for failure. They’re tired of being told they’re late, spending too much money, or missing the boat when it comes to getting the business want it really needs.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  Who or what can we change to fix our team? If these concerns are on your mind, I highly recommend taking a look at my white paper: “Doing More with Less – Best Practices for Processes, People and Metrics.”

This whitepaper will help you identify opportunities for optimization based on your specific organization, business situation and culture. Some of the concerns I address:

  • Is your methodology getting predictable, repeatable results?
  • Do you have legacy practices and tools that actually hinder performance?
  • Are the right “heads” in the right “hats”?
  • Is everyone on the same page as to who owns the success criteria for projects?
  • Are you tracking the things that make a difference to the business?
  • Are metrics visible and “common” across IT and business?

This white paper will get you started in one of the most critical roles you have: Removing obstacles.  If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

Please take a look at this white paper as soon as you can and feel free to post your comments right here.

Geneca Whitepaper – Doing More with Less

What Abbott & Costello Can Teach Us About Software Requirements

Whos-On-FirstGrowing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube.  Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in  the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we  can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether  “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link.  I recently came across another short video that is a modern day technical version of “Who’s on First”.  I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

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?

Sabotage.

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?

ZY3HJR6M97DD

Is This Obstacle Real? A 4-Step Process to Deal with Obstacles.

This is the second in a two-part series: “Obstacles”

Last week I introduced my approach to increasing a team’s RPM and predictability by identifying and removing obstacles.

Now, let’s go further and look at a four-step approach to help a team effectively deal with the obstacles they uncover.

As a member of a team, you probably see obstacles all the time. You complain and then ask for help. However, when you ask for help, you have to sell others on why this issue should be dealt with. You may very likely be told to “work around it”.

Air Cav infantry Soldiers compete in company challengeSo, once you identify an obstacle, first and foremost:

1. Get a clear consensus that this is truly an OBSTACLE.
Obstacles and issues are different things. Obstacles aren’t risks either. So what is an OBSTACLE? A detriment to success. Something that prevents you from being effective at delivering on a commitment.

Make OBSTACLE a reserved word. Use it only to identify key challenges that need management support in order to remove.

2. Next, clearly identify what the obstacle is.
Is it a procedure that unmistakably interrupts the team’s performance and rhythm? Is it a tool that requires you to do all sorts of work-arounds and forces you to spend eight out of every 40 hours working around it? Is there a person being disruptive because he/she isn’t working on the same problem as the rest of the team?

These are all issues and risks. What makes it uniquely an obstacle, is that you are “working around” these issues and risks and creating unpredictable results. These issues and risks shouldn’t be here. It is reasonable to ask your organization for help in eliminating them so you don’t spend any time on them.

3. Clearly identify what the difference would be if the obstacle is removed.
If the difference is “your day will be better”, you probably did NOT find an obstacle. But, if removing the obstacle allows you to deliver a proof-of-concept two weeks early, then this is tangible and of common value.

4. Finally, directly identify how to successfully eliminate the obstacle.
For example, if this means you no longer need to use the tool – and you can “write your own” – then be clear: We can delete the tool and I do it myself.

If you are the manager of a team that is identifying obstacles, then use the above four steps to clearly test: Is this a real obstacle? Are the benefits of removing the obstacle worth it? How do I support my team?

Let the team deliver for you.
Management’s role is to remove obstacles — not to micro-manage the team. If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

And that is exactly what this blog is about — sharing the different best practices and thought leadership around improving your team’s RPM, helping them become more efficient, and, eventually, more predictable.

I’m excited to participate in a blog devoted to my lifelong passion — making software development predictable. How do you identify, understand and remove obstacles? Do you have results to share? Add your comments below. I’ll be keeping an eye out and look forward to everyone’s contributions and the discussions that follow.

Dealing With Obstacles That Slow Down Team Performance

This is the first in a two-part series: “Obstacles”

Welcome IT Leaders and Teams. Getting Predictable is a blog devoted to helping leaders and teams jointly develop a no-surprise partnership. We do that with best practices that help us identify, understand and overcome the obstacles that prevent teams from being predictable. This is the first of a two-part introduction about the spirit and mission behind this blog.

3639604882_b2b2ef6fc6_mAre You Being Set Up?

Imagine the reaction if you told your CEO the reason your team was late and over budget on his project was because the team was “set up for failure” … that they didn’t have a reasonable chance of being successful.

In my career, I’ve experienced this dreaded feeling more than I care to admit. In fact, I’ve worked with teams that are continually frustrated because they truly, legitimately feel they are being set up for failure. We’ve all been there. Leadership frustration rises because their teams are always missing schedules or are over budget.  To them, the only thing consistent (or predictable) is the team’s lack of predictability and a steady stream of unwelcomed surprises.

Throughout my career, I’ve heard this question from my peers, direct reports and senior executives:  What (or who)  can we change to fix our team?

Get Set Up for Success

I’ve dedicated most of my career to answering this question … to finding ways to help teams get set up for success rather than failure and to achieve a “no surprise” approach to delivering business value.

The truth is, technology teams are very tired of being told they’re late, spending too much money, or missing the boat when it comes to getting the business want it really needs. When something outside of their control changes, they’re tired of fighting physics and trying to stuff 10lbs of work into a 5lb work-week.  You may have a highly talented team that feels like they are in a no-win situation. What a loss of talent!

Many of us have a passion to find these best practices.  Our drive in this area has yielded some very powerful best practices and rich peer-to-peer discussions that have been truly rewarding for me,  my network and my co-workers.  Now, it’s time these practices are shared and some new ones are learned. Along with other contributors, it’s time to engage in conversation as a technology community … hence, this blog. A blog  devoted to identifying and fixing  the obstacles that prevent our teams from producing their very best.

For starters, let’s paint a picture of obstacles.

Suppose you neglected to change the oil in your car. The oil will get thick and sludgy, right? It affects the performance of the car.  At one point, you determine the problem and you change the oil.

In other words,  you effectively remove the obstacle that is holding back the performance of the car. And by simply removing the obstacle, the entire car, and all its parts now hum at a higher RPM.

Identify the Obstacles

This is what we, as leaders, need to do with our teams. We need to identify obstacles. To do that, we need to listen carefully to the obstacles our teams are pointing out. Then, using best practices, we need to help remove the obstacles, ultimately raising the RPM of our teams.

In my next post, I’ll share a way for a team to identify and communicate obstacles. And I’ll share one way I’ve worked with leadership to remove these obstacles and improve overall team performance and success.

Until next week, I’ll leave you with this:

 

Let the team deliver for you.

One of Management’s most critical roles is to remove obstacles.  If you don’t support your team in removing the obstacles that prevent it from delivering, you are setting your team up for inefficient and unpredictable results.

What about you? Can you think of any obstacles you wish your leadership would remove from your personal day to day processes?