Subscribe via RSS Feed

Tag: "transparency"

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.

Alignment Through Visibility

Testing-Alignment-Through-VisibilityIn my last post, I described how a lack of true alignment could create rework for a team. Worse, a lack of alignment may be the root cause of projects that are over budget and behind schedule. So driving alignment isn’t just a nice “political” move, it actually is smart business for your organization.

Because alignment is so critical to project success, it’s important to know whether your stakeholders are truly in alignment or just appear to be aligned but are actually going in different directions. There’s an easy exercise you can use to verify true alignment or simple agreement. This exercise is based on the concept of visibility.

Before I explain this exercise, it’s important to understand the difference between visibility and transparency.

Visibility vs. Transparency

I recently had a great conversation with a colleague about the difference between visibility and transparency.

Transparency is a behavior that a team member exhibits. Leadership and stakeholders have full awareness of the team’s effort and progress because of the transparency provided by the team members. Although this is desirable, it may not provide the stakeholders visibility into the project’s future.

Visibility is the result of transparent behavior. If I have visibility, then I know what to expect in the future.

Verifying alignment through visibility

Here is a simple exercise demonstrating how you can use visibility to verify true alignment.

Lets pretend we have business stakeholders who have agreed to build a lightweight version of Microsoft Word for a mobile device.

Originally, one stakeholder, we’ll call him Michael, was concerned over the concept of “lightweight”. He believed that the version needed to be able to read any version of Word, including showing “markup” made by tracking changes. He also thought having a lightweight version of Excel released at the same time was important.

After much negotiation, the stakeholders agreed to deliver a lightweight version of Word. The technology team provided an estimate of five months for the initial working release.

To make sure everyone is on the same page, I might ask the technology team:

“Is it reasonable that within two months, we will have a prototype showing us the base app that can l open and save documents and do fundamental editing and formatting?

Would it also be reasonable that everything related to formatting, spellchecking, email integration is done by the third month?

Finally, is it reasonable that the app will be fairly complete by the end of the fourth month so we can run some quality testing? Will we be able to complete the final testing and defect fixes in the last few weeks?”

If everyone high-fives and agrees to these assumptions, then there is a high likelihood of true alignment. Everyone has clear visibility and common agreement on how we track progress to our agreed upon goals. On the other hand, if the stakeholders don’t have agreement on these assumptions, then odds are they’re not in alignment around the ultimate goals and definition of project success.

In summary:

  • Assume it’s about five months to deliver
  • By end of second month we will have initial preview of base app, file functions, core editing
  • By the end of the third month we will have spellchecking and email integration
  • By end of the fourth month we have the app fairly complete and can start testing, packaging up, etc.

However, what if the delivery team reacted differently:

They say that five months was heads down development time. The testing, packaging, and changes would be “added” to the end of the five month schedule, making it six or more months.

Then, the business stakeholders may ask: “When will I see the markup-review? Is that at the second or fourth month check-in?” Only by having clarity and a common understanding on the future visibility of the project, can we truly be on the same page and have true alignment.

A quick summary:

Another way to look at visibility: Let’s agree upon how we track expected progress. If we can’t agree on that, then we probably are NOT in alignment.

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.

Estimating Without Fear: How To Do Away With Padding and Still Come Out Looking Like a Hero

Estimate-Without-FearWhen your team puts together an estimate, does it command a sense of confidence, trust  and respect from those reviewing the estimate? Or, is it assumed that  your estimate typically  is padded and may be off-by-an-order-of-magnitude?


Do people believe, that even though some changes will occur due to dependencies out of your control, your estimate is still reasonable and something the organization can  manage to?

Or, do they say that it would be great to hit that date, but still  challenge your assumptions and believe you’re really going to miss it?

I am sure that most of us will answer that “it depends”. It depends on the size of the project, the complexity, the individual asked (Harry never trusts our estimates), and so on.

So let me ask you to think of this from a different perspective.

  • Does your immediate management, your boss, typically have confidence in your team’s estimate?
  • Do your business sponsors and senior executives typically have confidence in your team’s estimates?
  • And for the most telling question of all: Do all of the members of your team who participated in creating the estimate, typically have confidence in the estimate and the ability to manage to it?

I am always surprised at how inconsistent these questions are answered, especially the last question.

In this post, I want to discuss the estimating activity that does the most damage in terms of  building  credibility and confidence, as well as  our  ability to predictably meet expectations.

Padding Your Estimate!

Padding an estimate is as common place as speeding over the posted speed limit. Sure, there are a few folks who typically follow the posted speed limit, but most of us realize that when they posted the 55 mph limit, that really is “highway speak” for 65 mph.  We pad that speed limit too!  But NOT for the same reason.

From my experience, padding an estimate is done out of fear.

We pad an estimate for fear of the unknown.

“I have worked with Jerry often enough to know that there is a chance he will want to tweak the report layout.  Also, even though he says keep it simple, he’s going to change his mind and will want to add features like exporting to Excel and PDF. If I pad this estimate, I’ll have enough time to give him what he really wants and be a hero by coming in on schedule and on budget. Hmmmm should I pad it by 25%, 100% or more? Hmmm?”

We also pad an estimate for fear of the known.

“I am going to need some new tables from the DBA team. I’m also going to need the backend services team to add some features to two web services.  This should only take a day or two, but I know that the process and wait time will take at least a week or two.  I should pad my estimate to allow for that, so I am not blamed if they take longer to deliver their changes.  I don’t want to be blamed. “

Remove the Fear Factor With Contingency Estimating

Your  fear is real. In fact, the truth is that many times, the fears become reality and we need the extra time. This is where  Contingency Estimating comes in.

The one consistent theme that padding an estimate has is a base and a pad. I think it will take two days (the base estimate), but because they always change their minds, this will take a full week to deliver (the pad).

With Contingency Estimating, you actually want to “advertise” and “magnify” your pad!  This is counter-intuitive, but you want to describe your estimate in the following way:

We believe this will take two  days.  We also believe, from experience, that we will take time during the review and find changes and enhancements. This happens every time and since Joe will want these changes, we believe we should plan on additional three  days of contingency time to let Joe volleyball back and forth so we can deliver this. So my estimate is two days to get it initially done, and three  days to let Joe modify,  enhance and get this done/done/done.

Now management can understand that if they want to reduce your five day estimate, they need to work with Joe – not you – on how to eliminate the rework or agree that the extra  three  days is  needed estimate to “get this right”.  The key is Joe owns the contingency time! And you have been transparent about what is driving your estimate.

Just as important, Joe knows that we have planned to allow for three days of review and enhancements and that he needs to have some ownership in time-boxing his review in that time-frame and schedule.

Here is another example:

We believe building this functionality will take about  one week. We can manage our part to the one week. However, we have to wait on the ERP team to modify their web services to handle the changes.  This typically should take three  days, however, they are so backed up, they typically take up to two weeks to complete the work and remove any defects. So my estimate is one  week and three days to do the core work.  However, I am adding seven business days as contingency time for integration, testing and making sure the ERP team and us are talking the same language.

Again, management can now understand the cost of the team-to-team communication and integration.  It doesn’t necessarily mean there is an ERP team problem! In fact, the challenge may be with your team and their ability to pro-actively manage in an integrated and distributed environment.

The truth is, it’s irrelevant “why” this happens when you build the estimate. It’s important to share the contingency time and then to tackle how to optimize later. This will build more confidence than “Padding” your estimate.

In Summary…

I hope you find this a reasonable approach to clarifying  for your management and team members what drives  your estimates and what part of your estimate is contingency planning for the “real world” challenges you deal with day to day.

Taking it a step further, I also hope this approach allows everyone to come to the table and begin the process of identifying areas that the teams can start managing better and  improve the actual time it takes to complete work. This would be done by first identifying contingency estimates and then addressing potential waste in the organization.

If you have a different opinion, I’d love to hear it. Please leave a comment and let us know!

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

Credibility: The Key to Quickly and Effectively Building Trust with your Client and Teams

Bridge over smooth water

Building trust bridges relationship gaps. Here’s how to do it.

Have you ever had a difficult encounter with a client and then found it hard to reach out to them? Have you ever been in a client situation where your trust has eroded? How about with a coworker? Don’t be afraid to admit if you have, because it’s a normal part of life and can happen quite frequently. One of the many challenges we have with professional and social engagements is building and keeping trust. I call this the “trust factor”.

The Trust Factor

The trust factor is strengthened by many different behaviors: Following through on commitments, walking the walk, being true to yourself, evoking transparency, and maintaining accountability. Time, of course, is also a crucial influence on the trust factor. The time it takes to build trust with any one person can take days, weeks, or even years. But in business, we all know that we must make effective use of our time to build trust as quickly as possible.

Trust Factor

Building trust takes time and requires focus on doing what you say you’re going to do.

In order to successfully and effectively build trust in your professional relationships, you’ll need the help of your peers, team, and clients. Once this is accomplished, a cohesive bond can be formed between teams, which will ultimately foster productivity and results. In order to have trust, one must establish a strong sense of credibility. This can be achieved by:

  1. Establishing clarity around roles and responsibilities which builds a foundation that supports credibility
  2. Reinforcing credibility by holding yourself and your team accountable
  3. Sustaining credibility by working together to make and honor commitments

Step 1: Build a Foundation that Supports Credibility

Establishing Clarity around Roles and Responsibilities


Think of it this way: You want your house to have solid foundation when it’s built, right? It serves as your house’s main support. The same theory applies to your trust factor. A poor or weak foundation to your house results in costly, ongoing problems. Having poor credibility and lack of role clarity supporting your trust factor, well, you can imagine.

The first step in establishing a foundation for your trust factor is to clarify team roles and responsibilities. To do this, your team has to be able to answer the question: “What is my purpose on this team?” Their answers to this question will gauge your team’s understanding around their roles and give them an opportunity to establish their credibility. Everyone’s trust factor will be firmly supported once credibility has been established.

Many organizations have a lack of clarity around roles and accountabilities. This becomes a caveat to project collaboration, credibility, and success. The slightest miscommunication or misunderstanding can damage an entire team’s credibility and momentum. Without a clear vision of established roles, a team will scramble when a new idea or problem presents itself. In addition to creating an atmosphere of uncertainty and a lack of predictability and credibility, missed opportunities, rework and delays will surely emerge.

Trust Factor and Knowing Your Role

Know your role and you will better know the expectations others have of you.

Step 2:  Reinforce Newly Enforced Credibility

Hold Yourself and Your Team Accountable to Meet Client Expectations

The first thing you need to do here is eliminate mediocrity. It is our responsibility to call people out for under-performing and encourage improvement. Imagine the implications to a team when more than one person is picking up extra slack. Feels counterproductive, stressful, and hurts the team’s morale, doesn’t it? By being accountable, tasks will not fall through the cracks. As a result, your progress will remain strong. If you see an area in need of improvement, be vocal about it. Be true to yourself and your peers (Read: being at face value) while maintaining a high level of transparency. This  will reinforce a sense of trust within your environment. Accountability greatly evolves your trust factor and will take it to the next level.

Trust Factor, Knowing Your Role and Accountability

Hold accountable both yourself and those around you.

Step 3:  Sustain Credibility

Working Together to Make and Honor Commitments

Finally, work together with your peers and clients. Keep metrics that add value and make sure that everyone understands the purpose, goals and format of the metrics. This will add visibility on what each member of the team has committed to accomplish and will stimulate accountability. It is at this moment that trust is mutual with you and your client or peers. Throughout the project, the synergy  created from mutual trust will make your team run on all cylinders.

Teams that work together to build trust are more likely to succeed at it.


Be transparent with your team to maintain credibility. By following through on your commitments, you will continue to grow trust with those around you. Sustaining a mutual trust between your client and peers will remove crippling roadblocks, allow you and your peers to see goals clearly, and induce a high performance environment.

Get Started. Build Trust Today.

Can trust be achieved in a short amount of time? If mistrust exists, can it be eradicated? This, of course, is the million dollar question. By simply treating your team as your true teammates and allowing a more fluid, open channel of communication, trust will begin to develop and results can easily be obtained.  Work on obtaining clarity and agreement from everyone at the beginning and watch your team go into overdrive. Amazing things happen when everyone is on the same page, working toward the same goal, and sharing a dedication for excellence.

Do you always hold your team mates accountable? Can you think of a time when you could have been more transparent with your client or team?