Tag: "featured"

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

How to Turn a WAG (Wild-Ass-Guess) Into a SWAG (Scientific-Wild-Ass-Guess)

Next in our Providing Meaningful Estimates series we talk about turning WAGs into SWAGs.

S-W-A-G stands for a Scientific Wild Ass Guess. It’s sometimes used more as a tongue-in-cheek way of saying: “This estimate isn’t really reliable. I pulled it out of the air.”

I’m going to show you how to put the S — the science — back in a WAG so even an off-the-cuff estimate can be meaningful and useful to your audience. The easiest way for me to demonstrate how to improve your SWAGs is to use a simple example.

Consider providing a SWAG, an order of magnitude estimate, on how long it would take you to read to The Fountainhead (752 pages) by Ann Rynd. In fact, stop reading this article right now and come up with your estimate. Please don’t do any research. Just take a moment and give me your “best” wild-ass-guess (WAG) right now. I’ll pause for a sec.

No seriously, take a moment, and come up with how many days it would take you? 1, 7, 14,…… 365? Just take a moment.

Now, I’m going to l give you a technique that to add some S to your WAG and make it a more a scientific answer.

Actually, It’s All In the “Words” We Use When We Present to Provide Our Estimates.

Whenever someone asks you for high-level-estimate and you can’t really do proper research, you will need to make assumptions. The key is to expose these assumptions with your estimate and to demonstrate how changes in assumptions might impact your estimate.

Here’s a framework that demonstrates how this works:

When providing an estimate, always provide a range. And for each number in the range, provide assumptions. It sounds simple, but the difference is pretty significant.Always start out by thinking: What is the lowest reasonable number your estimate might be. More importantly, explain provide why do you think it is unreasonable to assume that the estimate might be lower.So for The Fountainhead, you might start the estimate with:“I can’t imagine it taking me less than 7 or 8 days. Assuming I find the book interesting, I can probably read 100 pages a day and a little more on the weekend. But with my workload at work, and errands in the evening, it’s not realistic to expect me to read more than 100 pages or so each day during the week.”
Next, think about what is realistically the longest this task should take you. When you give this estimate, you also share what assumptions need to be true for you stay within this estimate (not exceed your high number).Returning to our example with The Fountainhead, you might continue your estimate with:“I can’t imagine it taking me more than 40 days. If it does take longer, then the book must have been written in a 3-point font or in French (I don’t speak French) or a crisis at work came up. I have to believe that I could force myself to read 20 pages a day, and even if I find it boring, I’ll get through the book in 35 to 40 days.”

Wild Ass Guess Vs. Scientific Wild Ass Guess

Now, let’s contrast these approaches in terms of reading The Fountainhead- a. All 752 pages.

WAG: It might take me anywhere from 7 days (a week) to 30 days (a month).

Using our new framework, you would answer:

SWAG: “I can’t imagine it will take me less than 7 days, assuming life doesn’t throw me any unexpected curveballs and I can read 100 pages a day. I can see it taking me as long as 38 or 40 days if I can only get through 20 pages a day due to boring content or unexpected crises at work. If it takes me longer than 40 days, then it not only was painfully boring, it probably is written in some ridiculous font or written in French (I don’t know French).”

I hope you agree, that the second example provides a level of confidence that we thought through our WAG and have some reasoning behind our estimate.

Check Assumptions. Manage Expectations.

The correct wrap up for a SWAG is an opportunity to further manage expectations by saying:

“If The Fountainhead is as good a book as you say it is, , then let’s assume I’ll get it done in about 14 days. Within the first 2 or 3 days, I can update you on whether this was a reasonable swag or not.”

This means within the first 2 or 3 days, you determine if the SWAG assumptions are correct. You can even restate your SWAG now that you have started reading it and verified your assumptions (one way or another).

If you still aren’t convinced, let me show you how effective this approach can be might be by by using a one more example real life example.

A Real SWAG in Every Day Life.

You own a home and want to build a deck on the back of your house. You ask two contractors to come out to your house and give you bids on the work. With each of the contractors, you walk through the backyard and show them where you want the deck. They show you different styles of decks and after reviewing the pictures, you choose your preference.

Each contractor tells you they will give you an exact estimate for cost and a proposal by the end of the week. But you have a key question: Your son is graduating college in two weeks and you want to know if the deck will be completed in time for the graduation.

Contractor #1 answers:

WAG: “The deck could take anywhere from 2 to 5 days. So if we start Monday we should have it done by the weekend. Let’s just hope we don’t get any bad weather.”

Are you at all nervous that the deck will not be done in time?

Contractor #2 answers:

SWAG: “I can’t imagine it taking less than 2½ days. If we can get the deck primarily built the first day, we’ll need the 2nd day to stain, make final adjustments etc. So by the time it’s dry and tweaked we are at the 2 or 3 day mark. It’s important that we don’t get any rain on Tuesday when we stain the deck.

Sometimes when we put the “supports” in the ground, we find obstructions we need to move. That could make the job take up to 5 days. If it takes longer than 5 days, then you have a surprise waiting under the ground. I don’t think you do, but until we start the job, I can’t be 100% sure. Of course, this assumes the weather doesn’t blindside both of us.

So barring any golden surprises, we should be able to complete the job between 2 to 5 days. I would hope to have it wrapped up by day 3 but I’ll know more on Monday.”

Which contractor gives you more confidence in their ability to deliver on what they said?

More importantly, if the estimates are off, they can talk with meaning. They can discuss what assumptions were wrong, or what had they not considered. In other words, it doesn’t feel like they just pulled a number out of the air without any thought or real consideration.

In summary: The Framework

So, in order to turn your WAG into a SWAG, start your estimate with:

The shortest or lowest estimate that is reasonable
Why it isn’t reasonable to be shorter/lower
Explain how large it is possible to go
What are the assumptions that would make it go that large
What are your assumptions that could cause it to larger
Finish your estimate with a viable, in between reasonable “target” in between that you believe is reasonable to start with. Explain how and when you will be able to validate assumptions and firm up your estimate.

April 8, 2011 | 2 comments | View Post

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

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

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

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

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

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

Does your immediate management, your boss, typically have confidence in your team’s estimate?

Do your business sponsors and senior executives typically have confidence in your team’s estimates?

And for the most telling question of all: Do all of the members of your team who participated in creating the estimate, typically have confidence in the estimate and the ability to manage to it?

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

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

Padding Your Estimate!

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

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

We pad an estimate for fear of the unknown.

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

We also pad an estimate for fear of the known.

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

Remove the Fear Factor With Contingency Estimating

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

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

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

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

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

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

Here is another example:

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

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

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

In Summary…

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

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

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

March 18, 2011 | 0 comments | View Post

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

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

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

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

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

So What is Management Really Thinking?

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

Management is Trying to Make a Business Decision!

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

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

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

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

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

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

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

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

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

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

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

Estimating is a Minefield!

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

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

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

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

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

Photo Credit: Denise Chan

March 2, 2011 | 1 comment | View Post

CEO for a Day

A Simple Decision Making Tool: What if I Were CEO for the Day?

Sometimes I find myself thinking inside the box too much. I automatically enforce rules and behaviors based on what I believe an organization would do as opposed to what it actually could do in a situation. For example, it is easy to think that your company would never “buy in” to your idea and execute them. You may think that there is no time, no resources or no to a whole bunch of other things.

The truth is what a company does or does not do is usually up to people like you. A good idea is hard to beat down. The difficulty is finding the mindset to help break out of our everyday self-imposed box. I have a technique I use called “What if I were the CEO”.

If you were “King for a Day”, you might not have to answer to others and face fewer challengers. This is not necessarily a helpful decision making perspective. Unlike the King, the CEO has owners, internal staff and external staff to answer to on a daily basis and is always dealing with repercussions. However, the CEO can still help steer a company to start a new initiative and execute on the “right idea” at the “right time”. For a decision-making perspective, I like to look at something and ask, “If I were the CEO, how would I consider this problem? Could I direct some of the company’s resources to make it happen?”

I give you a mythical instance. Say you work at a custom software development company and your client (who has been a long-term partner) wants something done in less than a month. Although you think it should take six weeks, the client is coming to you with that expectation. Do you agree to the gig, try to find a way to solve the problem, and then tell them “Hey, it will actually be six weeks the way we have it planned — or we could do two weeks with half functionality.”

Or do you sit back and really try to make sure you are thinking about all of the opportunities. If you were the CEO, is this client worth more than the standard answer? Will this affect your reputation as a business? Can this be more than a vendor relationship? Is this really the business you are in and not something that got mangled in the sales process?

Now, you are truly looking at all of the options. What if you could shrink the schedule by adding more people even if it was on your own dime? (Mythical Man Month people get in that line over there, but some problems can be addressed with man power if you manage and architect correctly.) Can you do that with more people, different people, partnering with another firm, working in a completely new way to achieve the outcome? Do you contemplate redefining the engagement with the client as a true partner between businesses as opposed to a transaction? What would you learn? What options might this create?

Thinking along these lines has helped to remove my own mental obstacles. It generates creativity without irresponsibility. The goal is to come up with more than just the standard answers and then see if you can validate them with your client and your management. But what if you acted like you were CEO for today? Could you make a difference?

January 11, 2011 | 1 comment | 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

Everything I Know About Software Development I Learned from Elephants

The Swiss Army Knife of the Animal Kingdom

Last week, I talked about the importance of introducing the elephants in the room. So now that we have the elephant in the room, let’s examine it and see what we can learn from elephant behavior and how we can apply it to software development. The irony of the “elephant in the room” metaphor is that it suggests that elephants are these large, bulky creatures that are imposing and not dynamic. In fact, elephants are one of the most versatile mammals on this planet. The elephant’s trunk is used to tear up food, so the elephant can digest it. It is a hand that can grasp objects, a means of drinking without having to bend over, and a way of spraying mud on themselves to protect their skin from the sun. It is even used as a tool for social interactions, to enhance their highly developed sense of smell, and to defend themselves from predators.

To deliver software predictably, we need to become dynamic, adaptable creatures as well. As the speed of technology gets faster and faster, we’re going to have to give up the idea of just doing one or two things really, really well. We’ll have to be like the elephants’ trunk. We have to know the foundation of coding, but not be married to any single language. We’ll need to understand the best practices of project management, but be flexible in our methodology and apply the best methodology to the best practice. We will need to master requirements facilitation, but have many different tools to gather requirements and to custom fit the requirements process to the appropriate projects.

Even We Can Become Extinct

If we are rigid and only do things one way, technology will pass us by and we’ll become extinct. However, if we are adaptable with our tools, practices, and methodologies, we’ll continue to evolve to meet the demands of business using the best that current technology has to offer.

In the past, the slower speed of technology may have meant that a method and tool would be useful for many years. In the fast pace of technology today, it is never the case that we can say that any idea, method, or tool works every time. We need to be constantly transforming ourselves, our ideas, methods and tools to confront new challenges.

We may come to find more and more that projects are changed or canceled once we have gained momentum. Perhaps what made business sense when we started the project no longer makes sense due to new technology which has changed the marketplace. Rather than letting this disturb our equilibrium, we should begin to develop habits that allow us to shift rapidly and be adaptable to such change. Those in technology who can rapidly adapt will excel in tomorrow’s marketplace.

Being flexible and adaptable isn’t easy. It requires us to constantly let go of things that we know as true. Something may have worked for us before, but it may not work now. Or perhaps we have a perfect tool in mind for the job, but our client has a tool they like more. We have to let go of what has worked in the past for what it will take to accomplish the challenge before us.

And Maybe Dumbo Wasn’t That Far Off Base

One last thing we can learn from elephants is to use our big ears. Disney’s portrayal of Dumbo, the elephant with ears big as wings, wasn’t that far off base: Elephants have huge ears and an exceptional power of hearing.

As a predictable partner, we also need to always be using our ears. Not just to listen to what our clients are saying, but to really understand the meaning of what they are saying.

We can do this by maintaining a curiosity with our clients and what unique strengths and issues they have. Listening is a good first step, but when we are curious about our clients’ strengths and issues, then we have motivation to not just hear, but to understand.

Also, using our ears helps ensure that we are speaking the same language. It ensures that we are talking apples to apples and oranges to oranges. Our active listening helps our clients to know that they are being heard.

So next time you pop in the Disney classic about the elephant with the big ears, take note. Just like the underdog elephant who learned to fly, we can also use our ears to help us find success with our teams and clients.

December 6, 2010 | 0 comments | View Post

What Elephants Teach Us About Software Development

The Blind Man and The Elephant

So there’s a treasure trove of stories and metaphors that revolve around elephants, and lately in my work with Geneca, I keep on running into elephants.

One of my favorite elephant stories that I’ve been coming back to lately comes from several sources in Eastern Philosophy: The Blind Men and the Elephant. In this story, several blind men encounter an elephant. One touches the ear and says the elephant is like a hand fan. Another touches the trunk and says the elephant is the branch of a tree. The one who touches the leg believes the elephant is a pillar and the one touching the tail believes the elephant is a rope.

This metaphor tells us that different people with different roles and perspectives will have different ideas of what the “whole” is. This reminds us that on projects, since each person can’t see the whole, we have to have good communication with each other to understand what the whole really is. And this leads me to the next metaphor that I keep running into:

Getting in the Elephant Habit

When I listened to “Last Lecture” by Randy Pausch, a Professor who had cancer and was delivering the last and most important lecture of his life, I was struck by the technique he used to address the most anxiety-producing topic in the room. What he said was: “My dad always told me, when there is an elephant in the room, introduce them.” Then, he goes on to talk about the fact that he has cancer, which everyone knows, but nobody wants to talk about.

To deliver software predictably means to always be introducing the elephants in the room. When there are things that everyone in the room knows about, but no one wants to discuss – politics, friction between team members, risks, difficult decisions no one wants to make — it is our duty as the predictable partner to introduce these elephants.

One of the best practices of predictable software delivery means that we are speaking the same language as our client, apples to apples, oranges to oranges. Because we are the predictable partner, and because we believe in the best practices of predictable software delivery, we need to step up and introduce the elephants in the room, even if it is difficult and perhaps risky to do so.

I’ve noticed that the first time you introduce an elephant in the room, it is not well received. It is as though you have disturbed a social norm. It makes people uncomfortable. Often the first elephant I’ve introduced is the friction between two members of a team. Everybody has noticed it, but everyone has consciously or subconsciously decided to accept this friction that negatively affects the team, rather than face the uncomfortable moment of calling it out.

What I’ve found is that after introducing the first elephant, the second becomes easier. After the second, the third is expected. After the third, people have adapted to this behavior, and even begin to call out elephants they see. It becomes a habit, a part of the team culture. And having a team culture of calling out the issues rather than sweeping them under the rug is what being a Predictable Partner is all about.

Next week, I’ll talk about what we can learn from elephant behavior and how that can be applied to software development.

So, can you learn to adapt, or will you go extinct?

Photo Credit: Martien Uiterweerd

November 29, 2010 | 0 comments | 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