Tag: "featured"

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

Last 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.

October 19, 2011 | 0 comments | View Post

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”. Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

Part of the team and has skin in the game
Already a respected leader and trusted by the team not to impose their personal views
Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

Make sure the team does not give an estimate that is simply unrealistic. I talked about this in a past blog called “Attitude of Estimation”. As a facilitator, you want to encourage the team to come up with an estimate that is workable.
Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.

Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered. Project Managers can offer perspective on dependencies and resource availability. The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in. Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

September 22, 2011 | 3 comments | View Post

IT as Great Facilitators Part 3

Commitment Based Estimation

I want to tie together two concepts I have blogged about in the past few months. Specifically, how proper facilitation can help a team confidently develop a plan that is realistic and manageable. This is what I call Commitment Based Estimation. As a quick review, Commitment Based Estimation is an estimation approach that helps a team:

Develop estimates they genuinely believe are achievable
Feel ownership for their estimates
Treat these estimates as commitments and therefore honor them by managing to their plan

You can find my previous posts on this topic here:

Experiencing Why Commitment Based Estimation Works

I’ve used the following facilitation exercise to help teams understand some of the flaws with our typical approach to estimation. This activity also demonstrates why Commitment Based Estimation can lead to much higher quality results.

I always do this 2-part estimation exercise in person and always with a group of people. Important: If you do this with others, be sure to state the following rules:

You cannot ask any questions. Do your best with the information I give you.
Write down your answer. This is important (especially when doing this in groups).
You cannot collaborate or look at your co-worker’s answers.

I’d like you to choose a shopping mall or large shopping center that is a typical weekend shopping destination for folks near your office. The key is that it shouldn’t be across the street from your office, but requires a planned trip to get to. For example, where I work, there is a shopping center called Oakbrook Mall, which is about four miles from my office.

Now here is the first step. I’d like you to personally estimate how long it will take to leave your office, go to the shopping center, and find a store that carries designer sunglasses. Then, purchase a pair of glasses with mirrored lenses for your spouse or other family member. Then drive back to your office and drop off the glasses. Oh … and one other thing… On your way back to the office, please pick up an ink cartridge for your inkjet printer.

Now, I challenge everyone to come up with the estimate above. They each get about 90 seconds to come up with their answers.

The First Readout…

I then go around the room and ask everyone to read exactly what they wrote down as their estimate. It is important they use the exact words they wrote down. 60 minutes is not the same as one hour.

If you do this with a group, you will get all different answers. Typically you will get:

Someone who is optimistic and says a very short time. From my office, they might say 30 minutes.
A few folks who give a pretty precise estimate. For example 53 minutes, or one hour and 12 minutes.
Someone who might be swagging it at one hour or “an hour and a half”.

That Was the Setup. So Now You Change the Game…

After everyone has done their readouts, I then say “great job” and explain that I want them to estimate again. However, this time they have something to lose. I pretend that I am giving away an iPad or some other prize to the three folks who provide actual estimates.

So, I want them to redo their estimates. Knowing there is a prize at stake, they now have something to lose!

And Then the Fun Begins…

I now give the group another 90 seconds to redo their estimates.

If you actually created an estimate while reading along, I’d like you to take the opportunity to make it “more accurate”. Pretend you could win a real iPad if you create an estimate that you can deliver on.

I then go around the room and ask everyone to give both estimates. So again, here are some typical results during the second readout:

The person who was optimistic at 30 minutes says: My original estimate was 30 minutes and my new estimate is 42 minutes.
The folks with the precise estimates of 53 minutes either stay the same, or they may go up a little to 61 minutes.
(This baffles me.) There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70.
And every once in a while someone “pads” their estimate and says “one full day”.

Seriously – the Lessons We Can Learn …

This seems like a hokey exercise. Yes – I am a hokey person 🙂 . But let’s look at the real takeaways:

When we did our first estimate, we didn’t take it seriously. The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently, and try to come up with an estimate we can confidently deliver on.So when our project teams are estimating, are they approaching this as the first go around? Are they saying “You want an estimate? 53 minutes.” Or do they understand there is something at stake? They should re-think and verify that they can deliver on their estimate. Do they understand there is much more than an iPad at stake?
We assume that an estimate should be as low an estimate as possible, even if it creates risk to delivery.When we estimate, are we so afraid of estimating for real world contingency and risk that we always estimate optimistically? We probably shouldn’t pad to a full day, but we aren’t asked to make the estimate the “best case scenario” either.It should be an estimate that we all believe is achievable and can be managed to!
When I do this in group, everyone wants to ask questions. Is there construction? What time of day are they going? Do they know what store has the glasses? But as part of the rules, I say no questions are allowed.When they do this exercise, they can even be frustrated that they are being asked to create an estimate without knowing these answers. They think “How am I supposed to estimate this”?And this is exactly what happens in real life with our project teams! It is the nature of our world that teams will always have some questions that can be answered and many others that cannot be answered. Yet, we still ask them for estimates that we can plan and execute against.

Commitment Based Estimating

Commitment Based Estimating is about helping a team deal with all three of these challenges. In my next post, I will talk about how proper facilitation can help a team deal with these challenges and deliver a Commitment Based Estimate that everyone believes in and the team can manage to.

Can you think of any situations where it would have been worthwhile to try this exercise before delivering an estimate?

September 8, 2011 | 1 comment | View Post

IT as Great Facilitators Part 2

In my last post I talked about how facilitation is a key role, we each provide, in the IT world. I also described the two pitfalls facilitators sometimes fall into: The Presenter vs. the Scribe. Now, I am going to share two basic practices I’ve seen facilitators use to manage a room and deliver effective facilitation sessions. These aren’t the only two recommendations, but I have found they help me personally manage some very strong groups.

First, the Check-in…

One challenge facilitators face is having a single person in the room dominate the discussion. There are two typical causes for this situation.

The first possibility is that others perceive the ‘dominator’ as having all the answers. This person has been around twice as long as us and is a genius. So rather than the rest of us spend 30 minutes trying to solve the problem, we can just let “Joe” tell us the answer now and finish up the meeting early.

The other possible reason for the ‘dominator’ is that the person who is dominating believes no one else has anything to add. They shut down others by interrupting or attacking an idea before it’s given a chance to grow.

Both of these situations means that the room is in dire need of a strong facilitator. Someone who can help everyone feel that their opinion matters and collaborate to achieve their desired goals.

One simple way to get ahead of this curve is a practice I call the “Check-in”. At the beginning of the meeting, as the facilitator, you describe your understanding of the overall team objective and the specific goal of the session. For example, the team objective may be planning the next company outing which is a picnic. The purpose of this particular meeting is to choose a theme for the picnic outing.

This part is simple enough. But then, you go around the room and ask everyone to share their specific role related to today’s meeting. Now it gets trickier.

One person may have been part of the planning committee of past events and is there to bring their experience. Another person from HR and is there to help choose the theme and, more importantly, to make sure the theme is appropriate, professional, and compatible for special-needs employees. There may be an individual who is there to observe, learn and support the team in activities like coordinating picnic vendors.

Because everyone shares their “role”, as a facilitator, you can clearly ask individuals to speak up, or prevent a ‘dominator’ from interrupting by explaining that “Jerry from HR” needs to chime in on any concerns from their role’s view.

As the facilitator, you aren’t trying to control the room or shut down any individual. You are simply asking everyone to both play their role and support others in their roles.

Next, the Chair…

This technique is useful when you are facilitating a group of people and standing in front of the room. Maybe you are at a whiteboard or easel, recording decisions or helping others capture ideas. The idea is that while you ares tanding up front, the room of four to 12 folks are the working team.

When I am in this position, I always make sure to have a chair at the front of the room. If I am not physically at a table, I will have a chair just to the side of the whiteboard where I am standing. The purpose of the chair is to allow me to relinquish and regain control of the room.

For example, if there is good discussion around a topic, even if it’s disagreement, I want to encourage this discussion and let the participants feel in control of the room. I will sit down at my chair and really listen to every word.

If at one point, things are getting off track or out of hand, or if the energy is getting low, I will stand up out of my chair and show my intent to start facilitating. I usually do this by raising a question.

This seems like a very small tactic, almost making you think, “Bob – are you serious?” But if you are trying to lead a group, especially one that you don’t work with often, and need to make sure you are facilitating without confrontation, this is a natural way to control the energy and rhythm of the room. (To understand the importance of energy and rhythm, be sure to read my previous post on the role of facilitators.)

What has helped you facilitate more effectively?

These are just two ideas that I have seen effective facilitators take advantage of. While there are other techniques I may share in future posts, I love to learn and hear about other approaches. What are some of the effective tricks you have used to help lead and facilitate your team meetings?

August 24, 2011 | 1 comment | View Post

IT as Great Facilitators Part 1

In the IT world, we all play the role of a facilitator. Technical architects facilitate sessions for estimating and creating designs for their teams. Project managers facilitate team and client meetings and make sure the team is on track to reach its goals. When Business Analysts collect requirements, they may facilitate large requirement meetings. With so many kinds of facilitation roles, can we assume we know what being a facilitator really means? Do we, as facilitators, recognize that this is a significant role we need to work at and manage in order to be effective? How do we make sure we stay “within” our role as a neutral facilitator and not push our own agenda?

So you think to yourself, “Yes Bob, this is obvious. Of course I am an effective facilitator.” But let’s really test how effective each of us really are.

The Two Extremes of Ineffective Facilitation

When I have been a less-than-effective facilitator, I am acting in one of two extremes. I either go into “Presenter” mode or into “Scribe” mode. Let me demonstrate these two extremes.

On one side, a facilitator may go into “presenter” mode. Although their role is to facilitate a discussion (e.g. illicit requirements from business users or help a team arrive at estimates), the “Presenter” actually comes to the meeting with an opinion, specifically, a desired outcome. They are there to help others meet his or her agenda, rather than facilitate the room to develop its own opinions. When a facilitator starts presenting, he or she does not allow others in the room to collaborate towards finding their own solutions. This shuts down the energy in the room. This also means the participants may not “own” the solution.

At the other extreme, a facilitator goes into “scribe” mode. When a facilitator is in “scribe” mode, it means that when he or she walks into the meeting, they sit and take notes and meeting-minutes but do not influence the dialogue. This often allows others in the meeting to go off topic and start discussing points not related, in any way, to the objective of the meeting. Also, if someone is “checked-out” or “shut down”, there is no true facilitator in the room to make sure their voice is heard.

The Responsibility of a Facilitator

The best facilitators enable others to define, own and work in order to achieve their objectives. While the facilitator may bring an approach, the solution is owned by the individuals they are facilitating.

A Good Facilitator:

Helps the team clarify and align on their objective and then facilitates the team so they make progress towards their objective.
Helps keep the group’s energy high, so everyone is contributing and feeling heard.
Keeps momentum or rhythm flowing towards the objective.
Does not change the team objective during facilitation. (Although they can help the team change direction if the team believes it is required.)
Helps an entire group make progress towards its objective and makes sure everyone’s opinion counts.

Additionally, a good facilitator is constantly taking the group’s temperature in terms of:

Energy in the room: Everyone is engaged, participating and making constant progress towards accomplishing their objective.
Rhythm of dialogue: The dialogue is flowing but stays focused on the initial goal of the meeting.
Focus: The meeting is staying on track and accomplishing its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective, vs. topics that derail the goal.

Are You an Efficient Facilitator?

Even if we believe we are doing an effective job at facilitating, we may actually be playing a Presenter or even Scribe. Here are ways we can test our effectiveness:

Are you directing conversations with your own agenda? Or, are you enabling the team to have its own conversations?
Are you making sure the team stays on topic and on track to meet its objectives?
Are you making sure everyone in the room is being heard, and no one’s idea’s are shut down? (This can affect the energy of the room.)
Did you leave your opinion at the door? A good facilitator helps get to a solution, not give a solution.
If you had not attended the meeting, would the team have accomplished the same result? (Maybe you are not being as affective as you think you are.)

When It Comes Together…

Simon Sinek recently shared the following quote: “Don’t show up to prove; Show up to improve”.

When great facilitators lead meetings, they enable a dialogue that allows the room to make a decision. They do not abuse their role to force an outcome. Instead, they help everyone do a better job and accomplish fulfilling work. The room fills with energy and momentum that can’t avoid delivering results. When meetings feel this energy, you know you are leading the room and are an effective facilitator.

Do you consider yourself an efficient facilitator? Are there any other suggestions you can offer to help others meet their objectives?

August 9, 2011 | 7 comments | View Post

Is Your Software Development Team Set Up for Failure?

I 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

July 6, 2011 | 0 comments | View Post

It’s 10am and the Requirements Session has Started… Do You Know Where Your Business Team Is?

When sharing Getting Predictable^SM best practices, specifically around requirements definition, a common question that comes from I.T. management, Business Analysts and Project Managers is:

“How do I get the business to come to the table? How do you get the business folks to commit to the time needed to properly collect requirements for a project?”

Most business folks are very busy, but the underlying problem is more than just time management.

Many business users feel it’s a waste of their time. It’s truly annoying to have to tell the “tech folks” requirements. They’re gonna get it wrong anyway.

And you can’t really blame them.

Let’s picture their world:

You’re working 8+ hour days doing your full time business job. You have plenty of regular weekly meetings you go to, some that are a waste of energy. Now your boss tells you the tech team wants to meet to ask: “How you do your job” or “What features would you like in the new system”.

You show up and as you start sharing your thoughts, they keep suggesting a better way. At times, you hear things like “what you are asking for is very complex – or is undoable”. A bit frustrating, but you trudge on.

The Requirements Sign-off

Then the business users are asked to read the requirements and sign off.

First off, some of the documents read like a technical manual for a Sears Washer and Dryer explaining how to disassemble the drive motor and replace some fan belt so your washer doesn’t make that whining noise anymore. The part of the documents that do make sense to you are sort of right – but you’re not sure how much effort to spend to get it 100% perfect.

This might be a little exaggerated, but go ask your business user to read the above paragraph and listen to what they say. Many will surprise you with their feedback.

Over the next couple of months, the I.T. team asks a few clarifying questions here and there and some of the questions have no resemblance to your original requirement.

When you get the new software, it isn’t what you asked for. And the technology team is combative. The I.T. team is saying your requirements were wrong and that’s why the system doesn’t work properly.

Surprised?

Hmmm… Why in the world would the business want to experience this?

While a little exaggerated, I have to admit that over my career I have heard business users say this. There is some truth to these remarks and they represent obstacles for our teams.

That said, there are some simple ways to get the business to check in and truly get passionately involved. Here are some quick ideas to point us in the right direction:

First and foremost, Listen.

The joke I share with my technical leads is that “Before we might say ‘no’ to a particular feature, at least listen to their entire request. Then you can say ‘no’”.

And yes – this is intended to point out that all too often, we start compromising a requirement because we know the business better, or their way takes four weeks to do and tweaking the requirement can get it done in one week with an off-the-shelf product. We need to listen to their full need and the “why”. Then you can be a partner and offer them options.

This brings me to the second suggestion.

Give them Options.

Don’t simply tell them the system can’t send the data to all 123 data centers and get responses in under 30 seconds, assimilated in 14 languages and then graphed real time.

Explain to them this one requirement may take two years and 24 people to pull off and that if they would be willing, here are two or three alternatives that may work and would take two months to get completed. Ultimately it’s their budget and their choice on schedule.

They will feel less like something is being “done” to them and more like you are truly trying to help them through this process.

Finally, Give them what they asked for and Quickly.

What I mean by this: If they asked for a special screen to do a quick side calculation, and you see they have energy, create a quick mock-up or even a prototype and ask if this is what they had in mind. Make sure you don’t embellish. Give them exactly what they asked for.

If you have a great idea, then show them a second version of the mock-up after you showed them theirs. Let them buy into it.

In an iterative world such as Agile, it is part Agile to quickly turn around a requirement for user feedback. Even in Waterfall, you can create anything from paper prototypes (see my previous Lo-Fi post) to a wireframe or real code for those scenarios that the user was really passionate about.

Before you know it, you’ll need a bigger conference room for your requirements meetings because all the different business stakeholders will want to come and give you “their” requirements. They won’t trust their colleagues to represent their opinion.

Do you have issues getting the business to come to your requirements sessions? How do you deal with it?

June 21, 2011 | 0 comments | View Post

Prototype Technologies are Ruining Your Prototypes

I want to challenge our thinking on how we use prototype technology in our world of software development. Are we using prototypes to help our business users all get on the same page and visualize a solution? Or are prototypes targeted at our internal team, so they can understand what the resulting system “should look and behave like”?

Prototyping can mean different things to different groups. For purposes of this post, let’s use this definition:

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.

When I researched this definition, there were some key points that consistently turned up. They include:

A Prototype isn’t the final product.It is designed to test a vision and illustrate a requirement for a final product. For example, if you want to design a car with the gear shift on the left side of the driving wheel, you could create a prototype with only that level of detail. It may not have a horn etc… Just enough to ‘prototype’ the proposed change.

A Prototype is used to eliminate ambiguity. In other words, it helps drive a common vision across project participants. For example: “Oh… so when you said make it smaller, you really meant tiny or minuscule. I see now”.

A Prototype is used to drive feedback. This helps an idea grow before making huge resource or financial commitments. We might build a working prototype of an Internet Alarm Clock that plays your music stored in the Cloud on the Internet. It may be fully functioning, but it is a one-off. Its purpose is to gather our initial reactions and generate additional ideas based on the working prototype.

Finally, a Prototype might be a Proof-of-Concept. This is used to test the feasibility of an idea and whether the initial vision can actually be delivered with the desired results. This is more of a design based prototype.

Why We Prototype

To summarize, prototypes can be used to:

Drive a common vision across stakeholders
Confirm our understanding of a desired end-state
Provide a forum for feedback among internal stakeholders and external customers.
Act as a proof of concept, flushing out the feasibility of an idea

Most prototypes serve one or more of the above the purposes.

These days, there are many tools for prototyping. Everything from HTML for creating working-light-weight prototypes for review to wireframe tools such as iRise or Balsamiq. There are even PowerPoint files with “wireframe templates” in them to build wireframes and mockups using PowerPoint and it’s native tools.

So What’s the Problem?

In spite of the great tools out there, I’ve been in situations where these tools actually get in the way of our goals. They don’t help the business users get to alignment. In fact, prototypes created with these tools can actually drive a “compromise” in their design. Let me explain using an example:

I have three business users working to define a new “quick order” system for their web site. The Business Analysts spend a couple of hours working with them to collect their vision for the new shopping experience and all the tweaks necessary to take their website to the next level.

We take these requirements and have a designer build a quick prototype so we can make sure this is what they wanted. The final wireframes (built in HTML or another technology) are then emailed around to the business folks for feedback.

Now Volleyball Sets In!

Volleyball starts when one group, in this case the designers, emails information to the users and then the users email back their clarification or changes and the cycle continues.

It’s like each side is sending something over the wall or volleyball net. And, just like in volleyball, if one side drops the ball (or gives up) the other side scores a point.

At this point, the challenge is to effectively create a common vision across multiple stakeholders using email! (Hmmm, I wonder if this is how congress works.)

More often than not, the business gets the prototype to where it’s “Good Enough” and then approves it. They want to get going and hope they can tweak it as it is being developed.

Let’s see how effective this is at achieving our goals for prototyping:

Drive a common vision
Confirm understanding of a need
Provide a forum for feedback
Checking feasibility

I would argue that this process is extremely ineffective and delivers inconsistent results. When someone says this is close enough, are they really saying they feel like we are all on the same page?

If it DID accomplish these goals, then any system that used this approach would have less change requests, less defects and lower overall development cost.

But there is a better way. The Lo-Fi way.

Enter Lo-Fi Prototypes

Here is another way to create and finalize prototypes. Let’s go back to the meeting where the Business Analysts were collecting requirements. After they collected the high-level requirements, they use actual post-its that are cut into screen widgets. For example, there are post-its in the shape of data entry fields, list boxes etc. You can even use fan-folded post-its looking like a drop down box.

Now we ask the business users to actually build their screens. Using the post-its, scissors and markers, they create a lo-fidelity prototype. Whenever possible, we print out existing screens, even screens of a competitor, and mark these up with post-its and markers.

The prototype is NOT designed to flush out usability or the end look and feel. It is used only to enable the business users, as a group, to quickly build their lo-fidelity prototypes and share their vision and intent for the system.

I’ll emphasize that it is CRITICAL they understand that the final system will be a bit different due to design requirements, usability, branding, etc…

This approach is extremely effective and scalable. In fact, I have facilitated a small group of business users using this method to create more than 50 screens and report prototypes in a session.

There are a couple of great benefits using this approach:

The stakeholders feel ownership for the prototypes
It eliminates ambiguity, frustration and misunderstandings due to volleyball
Stakeholders can iterate immediately
They work as a group, helping drive alignment which results in less rework
Prototypes can be scanned into the requirement documents

At times, we give a few of the more critical lo-fi prototypes to a developer to create a hi-fi prototype (an HTML based prototype that can be interactive) over lunch. And yes – I said over lunch! The users can then get a real understanding (feedback) on their vision.

So if you really want to use prototypes effectively, forget about all those fancy tools. This down-to-earth, friendly approach will help you fast path collecting clear requirements and reduce confusion around the real needs and intent of a system, eliminating the pain of volleyball.

As a final note, I believe there is a place for using technology in prototyping. I am a fan of those tools. But I think we have gotten so technology focused, we tend to forget the real goal and use the technology appropriately.

What kind of prototyping tools does your team use? How do you think the post-it approach would go over in your environment?

June 7, 2011 | 2 comments | View Post

You Guys Start, We’ll Figure This Out Later

We’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?

May 24, 2011 | 0 comments | View Post

The Attitude of Estimation

Over the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.

Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.

To clearly share what I mean by our attitude, let me share a typical estimation experience:

Experiencing the Attitudes of Estimation…

I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.

One person on our team, let’s call her Ann, quickly throws out “This should be about two days”. Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.

I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.

After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.

One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.

Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.

Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.

Why These Attitudes Make Sense…

I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!

Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.

And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.

Commitment Based Estimates

Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.

When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.

I also don’t want them to pad estimates and not be realistic.

So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?

I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.

In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?

In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.

I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:

Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day, three days or five days etc…
If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)

The Goal: Consistency

Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.

I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!

As always, please feel free to share this post with anyone you think might benefit.

May 10, 2011 | 3 comments | View Post