Subscribe via RSS Feed

Tag: "team performance"

Project Retrospectives: When looking forward makes more sense than looking backward

iStock_000016701854SmallRecently a consultant asked me if I encourage teams to do a project postmortem or retrospective once a project is done.  The goal is to review what worked well and what didn’t.

Solutioners are from Mars, Supporters are from Venus

Solutioners-are-from-marsRecently, I was asked to facilitate a team-building session for a group of directors.

It started with the normal “storming”, “norming” and “forming” that takes place when teams form. But then I had a huge AHA – a major breakthrough that, for some reason, has eluded me for quite some time.

In this meeting, there were nine directors who collaborate with each other across projects.  One of the directors, let’s call her Mary, began to explain how her team members were struggling to get their deliverables done on time. One particular customer, she explained, was beginning to get a little frustrated with their inconsistencies.  As soon as Mary finished describing her challenge, one of the stronger directors on the team, we’ll call him Joe, responded with his idea: “Well, can’t you work around the issues this way?  Shouldn’t this solve the problem?”

Joe continued to explain his ideas and approach.  He was talking for about 45 or 60 seconds before Mary deftly interrupted him and started explaining to him why she was frustrated and continued to explain her challenge in more detail.

Mary and Joe started talking at each other in  an extremely painful conversation.  At some point other people in the room said, “Hey guys, do you see what’s happening?  You’re talking at each other.  You haven’t heard one word that the other person has said.”

I think we’ve all experienced that.  We’ve all faced a situation when we’ve seen two people talk at each other.  Until they feel heard, they can’t hear the other person.  This is not a new concept.

We asked Joe, “What did you hear Mary say? Did  you hear her?  Because she didn’t think you heard her.”  In response, he effectively repeated some of the words that Mary said.  “So you’re having quality issues, and you’re missing your commitment so you’re getting beat up.”

We then turned to Mary and asked, “Is that what you said?” And she said, “No, that’s not what I meant.”  This went back and forth a couple of times. We’ve all been there.

And then I had the AHA!

Look at what really happened here.  Mary was sharing her situation.  She accepted ownership for the situation, and even though she was struggling a little bit, she wanted to work through it.

Joe loves solving problems. He wanted to share a solution. That’s his job! He immediately tried to help Mary solve this problem by offering her solutions.  But Mary didn’t want him to solve it for her.  Rather, Mary was just looking for people to provide support. Mary wanted to hear, “That’s got to be painful. Is there something we can help you with?”

Supporting vs. Solutioning

Many times when a colleague (especially a peer or direct report)  first shares a challenging or frustrating situation, they are  looking for your support.  They don’t want to be perceived as “giving up”,” out of ideas”, or relinquishing ownership for the situation.

There are other times when the individual may truly be asking you to step in and help solve the problem. They may feel they are in over their head. They need your help to find a solution.

What Joe did was fail to ask, “Do you need help? How can I support you?” He assumed the way he could support Mary was to give her a solution.  This approach made Mary feel insecure because she felt like Joe was going to take control of the situation and undermine her authority. It may have even made her feel stupid.

I think back to two leaders within my own company, both of whom have an affinity for solution mode regardless of what you want to talk about.  If you approach them to talk about how bad traffic was on the way to work, they don’t say, “Oh yeah, I ran into bad traffic too.”  They will actually say, “Did you consider taking a different expressway so you don’t hit traffic?”  They’re actually giving you alternatives to which you might go, “You’ve got to be kidding!  I’m not looking for alternatives! I know how to get to work.”

If you take two people who live in solution mode and put them together, they may struggle to understand who owns what and how to collaborative more effectively.  They both assume they personally own and are accountable for solving the problem because that’s how they’re wired.  Although they might have good problem solving skills, solutioners can make others feel like they’re not as good at their job or they’re failing because the solutioner had to grab ownership of the problem and solve it.

Unlike solutioners, supporters are not pulling ownership and accountability away from someone, which makes it safe to interact.

My current thinking is that if you take a solution person and a support person and put them on the same team, then they tend to really complement each other. You have to be careful, though, about putting two strong solutioning individuals together, especially if they don’t know how to throttle it or are unaware of what they are doing.

Bottom line, when you interact with your team or a colleague, I’d be aware if they are asking for you to be in support mode, or actually solution mode. This can help you be more effective at setting the team up for success!

Mars vs. Venus

I recently shared these thoughts with several colleagues who validated my thinking. One of them chuckled and said I just  summed up the book, “Men are from Mars, Women are from Venus.” (The bestselling the book that explains that sometimes all your partner really wants is for you to simply listen and be there for them.) This really made the concept hit home, and in fact, it helped me out at home too!

Do you have any solutioners on your team?

Alignment: Antidote to Rework

Alignment-Antidote-to-Rework1In my last post, I introduced the Getting Predictable℠ Best Practices and explained  how they are designed to set project teams up for success “from the start”.  These practices cover three areas: Alignment, Commitment and Visibility.

Now I am going to dive deeper into the  concept of alignment and why it is critical to reducing rework and helping any team (not just IT) meet its  expectations, each and every time.

What is Alignment?

With technology initiatives, the goal of best practices around alignment looks like this: The business stakeholders all have a common answer to the question, “What is success for this project”?  In other words, they have agreement when the team can stop and everyone can  high-five because they all got what they needed.

At the other extreme (and this is the problem we are trying to solve), we don’t want the business to say to the team: “We have a really critical schedule, so you guys start and we’ll figure it out later”.

Why is it so important to focus on aligning the business stakeholders?  Isn’t it more important to focus on aligning the technology team to the business? No it is not more important – and this answer is of huge importance!

The technology team can’t align to the business goals if the business doesn’t agree on those goals! In other words, if the business isn’t in alignment, how can a technology team align?

What are they aligning to?

More importantly, a lack of alignment on the business side means there is almost certainly rework ahead for the technology team.  As the business goes through the process of coming into alignment, the IT team needs to make constant adjustments.  Sometimes in small ways, but other times the change can be significant and involve removing or changing an entire component of the solution.

When was the last time rework got extra schedule or budget?

This blog will cover those Getting Predictable℠ Best Practices that focus on helping the business get alignment on answering this question:  “What is the definition of success for this project?”.

Alignment is a great idea, but I don’t think it can work for me

Now you  might be thinking: “I can’t get my business folks to a single meeting, let alone get them to agree!” In future posts, I will share best practices that have worked for me. They don’t all work, and they don’t apply to all situations, but I have come to rely on these simple practices to get the results I am looking for.

And there is a huge side benefit.  By helping the business come into alignment on the key objectives of a project, I end up building a new level of trust in my relationship with the business team.  This truly was a pleasant surprise.

You will find some past posts, as well as future posts that focus on key areas such as:

  • Facilitation techniques
  • Aligning the business when they are geographically distributed
  • How to align interested parties that aren’t decision makers
  • Being adaptive to change and protecting alignment
  • When a lack of alignment is ok

So what do you think?

Do you believe this is a problem in your world?  How bad is it? I’d love to hear examples in the comments below.  If you don’t have this problem, why?  What do you believe you are doing right?

Getting Predictable℠ is a collection of best practices 
that set teams up for success from the start.

What Drives The Getting Predictable℠ Best Practices?

startIt’s all in the phrase: From the Start. I am frequently asked how the Getting Predictable Best Practices got started.

Getting Predictable℠  best practices cross many subject areas including requirements collection, tracking project progress, facilitation techniques, providing estimates that drive confidence, and so on. With such a wide array of practice areas, you’re probably wondering what binds them together. In other words, is there a common theme or vision that drives current and future best practices and recommendations? The answer is YES – there is indeed a common theme. And, as you guessed, this blog post reveals the vision aligns Getting Predictable℠ in all of its many flavors from discovery to definition through execution.

From the Start

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Wow! How profound! (Yes, I am being sarcastic at the moment but there’s truth here as well) For the majority of my career I have been on the client side of consulting relationships. I have heard some pretty big promises and I tend to be very skeptical. As I read my own description of Why Getting Predictable℠ exists, it’s hard not to think how empty it sounds! So let me explain. Let’s pretend we have a project kicking off and we have approximately four weeks to collect the overall requirements so the technical team can begin their planning and staffing of the project. So we e set up meeting with key stakeholders and business users for the first week in March to kick off the requirements gathering. The business is extremely busy and coordinating their schedules is like herding cats. All too frequently, you do not get full traction and commitment from the team during the first few days. In fact, it is possible that you might not get to full throttle until the second week of the four week schedule. Since we didn’t pad our four week plan, this lost time needs to be addressed. It is important for us to be adaptive and stay on schedule despite losing three to five days at the beginning. I want to emphasize that is not a rare situation. Especially when launching a new initiative. Would you agree?

Let’s take a different perspective…

Let me share a different way to view this. It may be a day here or a day there, but if we actually lose four to five days getting up to speed across the four weeks, we have lost 25% of schedule. We are potentially 25% late and over budget for this phase. And we haven’t even started yet! Here is my point: Although most of our leaders and managers would never intentionally handicap or put the team at risk, they are unaware that missing a meeting or pushing a date is actually doing harm to the team. If this story, in one flavor or another, resonates with you, then your success and the success of your project are being put at risk from the very start of your project. Why does this happen?

It’s all about the frog

If you put a frog in boiling water, it will immediately jump out. It’s way too hot. But if you put a frog in room-temperature water, and very slowly turn up the heat to a simmer, the frog will stay in its comfortable hot tub until it perishes. Ouch! On your project, it may only be a day here or a few folks there, not available, but before you know it, your project is starting to simmer. So let me repeat:

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Getting Predictable best practices identify and address the situations, activities and events, that can slowly handicap the teams chances of success before they even get going.

Now You’ve Got My Attention. Tell Me More.

Getting Predictable℠ Best Practices cover the gambit: Discovery, definition, execution, and organizational effectiveness models. In this blog, I focus on the best practices that address defining and launching a project or initiative. I call this set of best practices Getting Predictable℠ Definition. Getting Predictable℠ Definition addresses the three key areas that impact a project right from the start:

  • Alignment: Driving alignment around project success across all stakeholders.
  • Commitment: Developing estimates and plans the team can commit and manage to.
  • Visibility: Having a common view of progress as well as a a common definition of when the team has delivered on the defined project objectives.

In my next posts, I will discuss each of these areas in detail so you can see there is a method to the madness of Setting Teams Up For Success FROM THE START.

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment below.

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

You Guys Start, We’ll Figure This Out Later

Ready Set GoWe’ve all experienced a project that is kicked off just a bit sooner than maybe it should. You know this because you hear those infamous words:

“You Guys Start,
We’ll Figure This Out Later.”

Consider this simple phrase a warning sign that your project is in danger before you even start. The business team is still trying to figure out what they need. Yeah, they know their problem is clear but the solution is anything but.

So what’s behind this all too familiar call for help?
Lack of Alignment.

What the business is really saying:

“You Guys Start and We’ll Get Aligned. Right Now We Can’t Agree.”

This lack of alignment is almost always due to the business stakeholders’ struggling to determine and agree on what “success” is. This can apply to a product implementation, customer software development or even a change in business processes.

Some disagreements can be on the large scale:

Should our first release of tax planning software only focus on Federal tax strategies or must it support State tax planning too? If it should, which State? All 50? Isn’t that going to take forever?

Should we develop a full suite of open source Office type products including a word processor, spreadsheet, Powerpoint like tool? Or should we simply focus on our core offering, the presentation tools?

Some disagreements appear less strategic:

Does the solution have to support our customers in four countries and be localized in six languages? Or can the first release simply support our current client base?

Should our solution include a Spellchecker for the medical terms that we will collect in our survey tool?

“You Guys Start, We’ll Figure This Out Later” = Less Than Successful Project

In spite of this warning, the project needs to start. So we begin our planning and whenever possible, hedge our design to accommodate change. But, in the end, how likely is it that we deliver what they, the un-aligned business stakeholders, fuzzily define as success?

More often than not, they never get aligned. And if a new business person gets involved, who knows what their view of success is. At the end of the day, we are responsible for a potential “less than successful project”. Hmmm – they may even call it a failure!

And this shouldn’t surprise us! In fact, if you hear the words “You guys start…”, that should be a predictive flag that you may be setup for failure.

The message is clear: The Business needs to own the risk of having an I.T. team start without alignment among the Business. And the Business along with I.T., needs to jointly own and collaborate on how I.T. will re-plan once the business has completed their work by finally agreeing on what is project “success”.

What About Agile?

When I share these ideas with colleagues, I typically get two reactions. The first includes smirks and smiles saying: “Yep – we’ve heard that and you are right, it is painful.”

The second reaction comes as a challenge: “Wait – isn’t that what Iterative development is all about? The business can plan and change direction with every iteration?”

The assumption is that Iterative methodologies such as Scrum or Agile, can be an effective way to solve nonalignment situations. They break up a project into small durations (iterations) that focus on specific feature sets. An iteration may be as small as a week, but may be defined as large as four weeks. (You’d be surprised at how much energy this last point generates.)

This is often considered a safe/natural solution because at the beginning of each iteration, the business will look at the list of everything they want and define the target features they would like the team to work on for the next iteration(s). This re-planning allows the business to change its mind and adapt based on feedback and potentially changing business conditions.

An Iterative process doesn’t resolve alignment issues!

But we still have a problem here: The Business Stakeholder who kicks off each iteration is now accountable to determine what “success” is for that iteration. If they aren’t aligned with the original/other stakeholders, then they are actually steering the ship off-course. And there is NO visibility. The rest of the stakeholders may not even know what decisions and tradeoffs have been made within an iteration planning meeting.

But wait Bob! When we do an Agile project, we always have all stakeholders in the loop about which features were completed and what will be planned for the next iteration!

And to that I say: You are not the norm! So congrats!

When most organizations embrace Agile, they are focused on the core I.T. team, planning and execution. They don’t have a model for how this changes the behavior of the business stakeholders in their planning and management of initiatives.

True, we tell the business folks we want them in the room with us, giving us quick feedback, etc. But what we often don’t do is explain to them that this level of feedback requires them to constantly re-baseline what features are “in and out” based on their goals and budgets. There is no formal process for shifting this ownership over to the business.

So what’s the point?
ITERATIVE ALIGNMENT

The fact is that more often than not, a project will be started after hearing: “You Guys Start, We’ll Figure This Out Later”. It is the nature of business and politics. In fact, as I illustrated above, our iterative processes can almost “enable” a lack of alignment.

It’s important for us to set goals for the business to do regular “alignment-check-in”. We need to make sure the business owns and is accountable for understanding what they are asking for, and what changes have been made.

We should strive to eliminate the surprises at the end of a project where a business stakeholder asks:

  • Where did this feature come from? or
  • Why is this functionality missing?

Even if we followed the requirements to the letter.

So what do you think? Do you disagree? If you agree, who do you think should be accountable for managing this within your team? Within the business?

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

Wont-Hold-You-To-ItI have to be honest on this one.  Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate.  I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point  in the future, management gets the  real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way.   How can you go from $100k to $125 or $150k?   Or from two months to almost four months?

And, inevitably,  the creator of the swag estimate is asked,  “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the  first question you have to ask yourself is:  What was management thinking?  When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

  • Go/no-go on a project, or
  • Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
  • Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions.  That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive.  No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks.  I am not looking for a plan with milestones and staffing requirements.  I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you.  Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details.  Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for.  Are they looking to free up resources?  Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%?   Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done.  Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it.  I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan

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