Tag: "teams"

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

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

What Abbott & Costello Can Teach Us About Software Requirements

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

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

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

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

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

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

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

The “Spellchecker”

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

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

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

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

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

Seems reasonable.

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

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

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

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

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

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

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

Taking the First Step

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

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

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

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

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

Our manager responds:

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

And the team responds:

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

The Benefit of Acknowledging Spellcheckers

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

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

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

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

Now, Who Did You Say Is On First?

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

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

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

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

Photo Credit: Purple Slog

April 26, 2011 | 2 comments | View Post

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

The Vaccine Approach to a Software Development Project: Quality Assurance as a Value Added Partner

Last week, I talked about the risks that go hand-in-hand with the Bandaid approach to software quality assurance. With the vaccine approach, software quality assurance is not seen as overhead or a bottleneck. Instead, it is a value added partner that brings transparency and visibility in software development predictability.

Significantly different than the Band-Aid approach, in the vaccine approach the software quality assurance team is dedicated, full-time participants within software development teams. They are co-located and work collaboratively with both the business and developers. Acceptance criteria is defined in collaboration with the business and integrated with requirements. This provides significant advantage over the “Band-Aid” approach to testing, both within projects and across the enterprise application portfolio.

The Vaccine approach to software quality assurance provides more than operational benefits. It strengthens both the delivery team and the quality assurance function overall. Being embedded with and dedicated to a development team, software quality assurance people are immersed in the business problem as well as the solution while it is being developed. Being fluent in the application, a tester is more likely to recognize the difference between an application failure and an environmental or situational blocker, and better prepared to correct the situation. As a result, they are less likely to raise false defect reports that create “noise” that masks the state of application quality and impairs team efficiency by wasting other people’s time in disposition.

This approach also protects quality assurance leaders. When able to work only part-time in any given project, software quality assurance can do little more than produce testing artifacts and perform tactical execution. Working in full collaboration with a project development team, however, allows the software quality assurance team to gain deep business knowledge. A quality assurance team that is immersed in the problem domain is in good position to be IT knowledge workers. This makes them better business problem solvers, and stronger participants in IT solution delivery overall.

Engaged Participant vs. Disengaged Auditor

The intended deliverable of any IT project is a technically sound, functionally fit business solution. This is achieved through the engaged participation of all IT disciplines, including infrastructure, requirement, development, and quality assurance. By only playing the role of auditor, the quality assurance team is a disengaged member of the solution team that certifies an application as production-ready. Alternatively, by collaborating from the early stages of the software development lifecycle, and executing quality assurance continuously throughout, the software quality assurance team works as a value-added partner that directly contributes to an increased understanding and gradual evolution of a business solution. Ultimately, this approach increases both the value of software quality assurance and the return on IT investments.

What steps can your team take to move from a bandaid approach to a more holistic approach to software quality assurance and testing?

Photo Credit: Andres Rueda

December 28, 2010 | 0 comments | View Post

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

If Quality Assurance is intended to be a vaccine to projects, then why is it so often being used as a Band-Aid?

In our daily life, we take preventative measures such as flu vaccines early in a season to avoid, eliminate, and/or to reduce chances to get sick. This is similar to QA being part of a software development project early on in order to reduce defects and minimize project duration and cost. Unlike a conventional testing approach–which merely reacts to whatever has been designed or developed and frequently is perceived as interfering with development)–QA’s role early in the Software Development Cycle helps improve predictability and makes development faster, and less aggravating.

During my career, I have seen QA teams that are “shared resources” supporting many projects simultaneously rather than dedicated to specific projects. Huge armies of QA teams execute defined test cases/scripts to test and certify an application once development is complete. Because QA team members lack application familiarity and test only at the end of the development lifecycle, they require significant execution support. Often, the feedback they provide is late in coming and often inaccurate.

The Value of the Vaccine Approach

Compare this to a vaccine approach where the QA team is dedicated for the duration of the software development project and testers are co-located with the business and development team. Because they collaborate with the development team on formulating acceptance criteria and engage in testing continuously through development, they can spot the commonly-overlooked showstopper problem. Now, QA feedback is considered as timely and relevant and a value added partner in delivery. This increases the efficiency of the software development process and the effectiveness of solutions produced.

We all have our examples of exciting projects turned into nightmares. Creeping deadlines, tsunamis of defects, applications that fail to deploy or performance bottlenecks that just cannot be found. Unfortunately, these kinds of situations always occur at times when they are least welcome – right before the project deadline, during the holiday season or when you had planned that nice weekend getaway. Most of these nightmares can be eliminated if QA is considered a vaccine for the project lifecycle rather than a Band-Aid fix.

The Risks of the Band-Aid Approach

There are many operational risks with Band-Aid approach. It assumes that the test cases are of high quality, and that feedback is timely and actionable. These are unwarranted assumptions. Like any IT artifact, test cases may be ambiguous or confusing to testers (of poor technical construction) or they don’t test what needs to be tested (of poor functional construction). Since QA leads are shared across several applications, there are chances for error in writing test cases. Being part-time on every project, the QA team is forced to work independently from the development team. Test cases/scripts are often written to abstract specifications in the early stages, before software is ready to be tested, and executed in much later stages of a project once development is complete. They are not written in conjunction with the development of the software, or in full collaboration with development. Also, the development team is often not made aware of specific QA and UAT acceptance criteria, nor does it receive testing feedback, until very late stages of a project.

There is financial risk as well. This approach emphasizes unit-cost efficiency of test execution over a holistic approach to quality assurance. On a test-cases-that-can-be-executed-per-person basis this model looks attractive, but to be cost-effective, there must be low overhead of execution. The greater the effort required to stage testing activity (e.g., with test data or instructions to carryout testing), or to interpret the results of testing performed, the greater cost of execution.

What approach does your IT organization have to QA?

Next week, I will take a closer look at the benefits of a more holistic, Vaccine approach to QA and testing.

Photo Credit: Guerrilla Futures | Jason Tester

December 13, 2010 | 1 comment | View Post

Iteration Zero: Reduce Risk Before You Begin the Project

Reduce Software Project Risk Before Construction Starts

Last week we talked about the level of planning required to ensure that a journey (whether a travel adventure or a software project) be enjoyable, problem free and capable of delivering better results.

In the first stage of planning for our journey, we identified where we wanted to go and how we thought we’d get there. In software development, this can be thought of as business definition and understanding the business objectives. The second stage of preparation for our fictional journey — studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero. This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Iteration Zero sets up the groundwork for construction by implementing the reusable patterns and components in the application architecture and preparing the environment for a development team to be effective. This phase helps to remove the traditional Just-In-Time environment setup that often occurs in the construction phase. By adding an Iteration Zero, you are essentially allowing for time to be utilized more effectively and predictably during the construction phase.

One perception about the phrase “Iteration Zero” is that it implies an agile style of development. This is not necessarily so. The practices in “Iteration Zero” have been used successfully with several different development methodologies.

One of the major dependencies for an effective Iteration Zero is awareness of the success criteria of the project defined and agreed to by the business. They also need to be understood by the technical team(s) before the Iteration.

Creating a Forum to Ask Questions and Learn

One of the most important elements for executing Iteration Zero is the Workshop. The Workshop allows the team to see how the software is going to be developed from a process perspective. Additionally, it helps the team become familiar with the technologies, components and patterns implemented and added to the code solution. This begins the process of the team becoming immersed in the construction process.

In order for the development and quality teams to be effective in Iteration 1, the Business Analyst should begin creating the Business Rules Documentation. Iteration Zero provides them with a jump start from both the development team and the quality team.

Iteration Zero can also be used to identify risky technical aspects of the system. These risky elements should be studied to form a mitigation plan (during Iteration Zero) to learn as much as possible, as early as possible.

Hit the Ground Running

Although there are ways to prevent a project catastrophe, most of us have still seen at least one project land in the dumpster for a myriad of possible reasons. While there are risky elements outside of delivery that can hurt a project, adding and enforcing Iteration Zero is a great way to make sure your next journey goes faster, behaves more predictably, and adds more value to the business.

How is your team using Iteration Zero?

Photo Credit: Thomas Beck Photo

November 22, 2010 | 0 comments | View Post

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

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.

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:

Establishing clarity around roles and responsibilities which builds a foundation that supports credibility
Reinforcing credibility by holding yourself and your team accountable
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.

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?

October 12, 2010 | 2 comments | View Post

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

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

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

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

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

So, once you identify an obstacle, first and foremost:

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

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

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

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

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

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

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

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

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

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

July 6, 2010 | 0 comments | View Post

Dealing With Obstacles That Slow Down Team Performance

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

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

Are You Being Set Up?

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

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

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

Get Set Up for Success

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

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

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

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

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

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

Identify the Obstacles

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

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

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

Let the team deliver for you.

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

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

June 29, 2010 | 0 comments | View Post