Skip to main content

Tag: Stakeholder

The Outstanding Business Analysis Moment in America Goes to OBAMA!

Written by Marcos Ferrer on . Posted in Articles.

This year the O.B.A.M.A. award goes to the man himself, for his live demonstration of meeting management soft skills for over seven hours, on television!  This is NOT POLITICAL – it is just an observation that President Obama is practicing these skills in the face of a very chaotic stakeholder environment.

So, what skills?

How about K.I.S.S.?  Obama presented four problem issues, to be discussed, each quite easy to understand.

How about facilitation with detachment?  He focused on the problems, did all he could to avoid the personalities, while constantly returning the focus to the issues at hand.

How about managing unproductive contributors?  Every meeting has its baggage in terms of folks who simply won’t participate in the agenda, are not interested in the problems to be solved, and use the meeting to grind their own axes.  Next time this happens to you, remember Obama, and his kind rebukes (Senator McCain, the election is over!).

How about preserving stakeholder interests?  Even as strong differences of opinion deadlocked the conversation, Obama kept reminding the participants that real people were being affected by the paralysis.  The imaginary people that are against government regulation of healthcare DID appear on Fox News – like the senior citizen who ranted against Obama’s plan, from her Medicare paid nursing home bedroom.

By letting the issues contrast against the personalities and private agendas, Obama did NOT win over the objectors to the “project” – they remain determined to keep the status quo.  What he did accomplish was to create a forum where the undecided can try to weigh the issues of problem solving against ideology, so at least they know what they are deciding.  Helping stakeholders decide is often as good as it gets for a BA.

Rather than dwell on the negative, I ask my kind readers to send me THEIR examples of an Outstanding B.A. Moment in America – we are seeking a right wing nominee, for a fair and balanced presentation!

Have fun, and please let us have your comments.

Don’t forget to leave your comments below

Who’s on First

Written by James Rivera on . Posted in Articles.

Who’s on First is one of the greatest and funniest comedy routines of all time, and in 1999, Time magazine named the routine Best Comedy Sketch of the 20th century. This routine still stands up today because it illustrates a universal truth we all understand and have experienced: that just the slightest misunderstanding in simple common terminology can lead to a complete breakdown of communications.

In this skit Costello plays a peanut vendor and fan of the St. Louis Wolves Baseball team, and Abbott is the team coach. Costello wants to know the names of the team’s players so he can “say hello if he meets them on the street.” The source of the miscommunication is the players strange nicknames that are interpreted by Costello as non-responsive answers to his continual questioning. The lineup for the team is; Who’s on First, What’s on Second, I Don’t Know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I Don’t Care is Shortstop. Here is a sample;

Costello: What’s the guy’s name on first base?
Abbott: No. What is on second.
Costello: I’m not asking you who’s on second.
Abbott: Who’s on first.
Costello: I don’t know.
Abbott: He’s on third, we’re not talking about him.
Costello: Now how did I get on third base?
Abbott: Why you mentioned his name.
Costello: If I mentioned the third baseman’s name, who did I say is playing third?
Abbott: No. Who’s playing first.
Costello: What’s on first?
Abbott: What’s on second.
Costello: I don’t know.
Abbott: He’s on third.
Costello: There I go, back on third again!

In the end, Abbott’s explanations leave Costello hopelessly confused and frustrated. The entire time I am laughing out loud at the exchange. Inside, I cringe because at times I have experienced this same level of confusion and frustration when eliciting requirements from stakeholders due to the subtle differences in our understanding of the basic terminology such as “What are Needs?” or “What are features?” or “What is considered a Requirement?” The problem for Abbott and Costello stems from the fact that even though they think they are talking about the same thing, in reality, they are not, and for a business analyst this disconnect is caused many times by a stakeholders’ colloquialisms, cultural norms, organizational tribal knowledge, or just plain ignorance.

If Abbott and Costello had agreed on some simple guidelines before engaging in this conversation, it may have gone very differently, for example if Abbott had said.

Abbott: Now, before I tell you the names of the players, I want to make sure there is no confusion. You see, as a joke, we came up with some very strange nicknames to confuse the ball game announcers, and boy do we get a laugh.

Costello: That sounds like fun, do tell

Abbott: Yes it is, you see some players have nicknames that are actually words that are questions like “Who,” “What,” or “Why.”

Costello: Well that is really clever. I can just imagine the confusion that creates.

Abbott: Yes, you have no idea!! So for example, the first baseman chose the word “Who” for his nickname, and the second baseman chose the word “What” for his nickname, isn’t that hilarious.

Costello: Ha, Ha, Ha, oh my that is funny

Abbott: Ha, Ha, Ha, makes me laugh every time. So here are the names of the ball players.

Abbott: Who’s on First, What’s on Second, I don’t know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I don’t care is Shortstop

Costello: Hey, What about the right fielder?

Abbott: Oh, he didn’t think it was very funny so his name is just Fred.

Costello: Got it, thanks see you later

Well this is certainly not as funny as the original routine, but it is much clearer, much shorter, and no one is frustrated. This is an example of what I call “orientation.” In this modified version of the skit, Abbott, spends some time getting Costello “oriented” to the terminology to make sure the conversation gets off on the right foot. The result is clear, succinct, and frustration free communication.

To achieve this type of orientation, you have to ensure that you are relying on not just the definition of common terms, but also the semantics or meaning. The best way to do this is to begin by asking some simple clarifying questions to make sure you are talking about the same thing.

Because you will be talking about software or product development and not baseball, you most likely will not encounter such strange nicknames as “Who” “What” or “Why.” However I have encountered some awkward and perplexing interpretations of common requirements terminology that has created some very challenging communications.

To understand the right questions to ask, for example, let’s first lay down some guidelines around two common terms, needs and requirements.

Understanding Needs

A need is a deprivation or something that is missing. In requirements terms, here are a few examples:

  • Something the stakeholder or a customer cannot do

“Customers do not have the ability to pay the bill from their cell phone.”

  • Something the stakeholder or a customer cannot do adequately

“The call centers experience high call volumes due to difficulties customers have paying their bill on their cell phone.”

  • Something they cannot see or don’t have

“The monthly call center report does not provide details on customer complaints by region.”

When thinking of clarifying questions, remember you are trying to determine what is missing or what they are deprived of, here are some guidelines.

  • Questions that pertain to something the user is attempting to do that they cannot do today
  • Questions pertaining to information that is lacking or insufficient to perform a task or make a business decision.
  • Capabilities that are insufficient, cumbersome, or prevent the user from performing a business task
  • Capabilities that cannot be performed in the correct order, or performed in a timely manner

You will notice that I am intentionally avoiding the use of the word “need” when suggesting clarifying questions about needs. The reason for this is that it is very common to confuse needs with requirements mostly because in our every day lives we don’t make the distinction between the two. I can remember my children telling me how much they “needed” the hot new video game, and I would very calmly tell them. “Well actually, you do not need that hot new video game, the only things you need are food, shelter and love, all of which your mother and I provide. What you really mean to say is you “want” or “desire” to have a new video game. As you can imagine, my children just roll their eyes, complain louder, and typically get their way.

Needs are not necessarily tangible things; they are a description of a condition or state. Much like hunger is a physiological condition that results from the lack of food, a need is a business condition that results from the lack of a capability. Make sure when you are discussing needs that you are talking about conditions or states of deprivation, and this will ensure that you are talking about a need and not something else.

One other distinction in regards to needs is whose needs you are referring to, business needs, customer needs, stakeholder needs. This distinction is based on who is experiencing this condition or state. In other words, who cannot perform the task, who cannot see what they want to see, or who is having an inadequate experience.

Understanding Requirements

Requirements on the other hand, exist only to satisfy needs. Requirements can also be classified as desires or wants unlike needs which specify something that is missing. There is a very important relationship between requirements and needs, and you must be able to demonstrate this relationship to ensure that you have a valid requirement. The following example also demonstrates that there are typically many requirements necessary to satisfy a single need.

Here are some examples:

The “Pay by Cell” feature will provide the customer with the following capabilities:

  • The system will provide the customer with the ability to look up their existing monthly bill on their cell phone.
  • The system will provide the customer the ability to pay by credit card on their cell phone
  • The system will provide the customer the ability to store their credit card information from their cell phone.

Note: you will notice I cleverly inserted the term “feature” without any explanation. For clarification, in this example a feature is a collection of requirements which also exist to satisfy a need.

When thinking of clarifying questions, remember you are trying to determine what capabilities will satisfy or fulfill a specified need. Here are some examples of categories of questions to ask:

  • Questions about how a specific capability will help the customer to perform a task they could not perform before
  • Questions about how having specific information will help the stakeholder make better business decisions or perform specific tasks
  • Questions about how specific sequence or timing of capabilities will provide a better experience for a user

A good rule of thumb is to avoid using the terms you are trying to clarify in a questions, such as What do you Need? What do you Want? or What do you Require?

Remember requirements exist to satisfy a need or condition. Much like food satisfies hunger, requirements satisfy needs. Also, like needs, you must also make the distinction between the various types or sub classifications of requirements such as customer requirements, business requirements, system requirements, product requirements, technical requirements, etc. This distinction is very important because the methods used to document these different types of requirements can be substantially different.

In the previous example, the requirements were specified in a functional form, that is to say, they describe the requirements in terms of the functionality or capabilities the product must have to satisfy the need.

Another common form of describing requirements is in terms of the experience the user has when interacting with the product, for example;

  • The user requests their monthly bill from the system and the system displays the bill to the user
  • The user chooses to pay their bill by credit card, and the system prompts the user for credit card information
  • The user chooses to store their credit card for future reference, and the system validates and stores the user’s credit card information

To ensure you and the stakeholder are talking about the same thing with regard to the style in which to document the requirements, here are some useful guidelines to ensure you both have the same perspective.

  • Should the requirements describe the experience the customer/user has when interacting with the product or service?
  • Should the requirements describe the capabilities that the product/service must have to support the customer interaction?
  • Should the requirements describe the capabilities the organization must have to support the customer interaction and the product/service capabilities?
  • Should the requirements describe the technical capabilities that must be present to support the customer interaction, product/service, and organizational capabilities

I have seen many different terms used to describe these four types of requirements, some that make sense and some that don’t, however, what is really important is that you use the guidelines above to ensure that you and the stakeholder are talking about the same thing, and then you can agree on what term to use to describe the final artifact.

For example, I have seen the following

  • Use Case, User Requirement, Business Requirement
  • Product Requirement, Functional, Non-Functional, System Use Case
  • Operational Requirement, Business Use Case,
  • Technical Requirement, System Use Case

Again it is all a matter of perspective and what is most important is that you and the stakeholder are talking about the same thing.

Is summary, the key to ensuring that you have a productive requirements elicitation experience is to first ensure that both you and the stakeholders are oriented to the same understanding of the goals to be achieved. These goals include, ensuring the needs are well understood and documented, ensuring there is a common understanding of what is and is not a requirement by associating with a defined need, and ensuring you clearly understand the perspective from which the requirements are to be written and agree to the final style of documentation.

James Rivera is a Project Solutions and Services Delivery Professional with over 17 years experience in Program Management, Business Analysis, Process Improvement, Education and Instructional Design and he currently leads the Enterprise Business Analyst team at a mobile telecommunications company in Seattle. He is a Contributing Author to : The Fast Forward MBA in Project Management 3rd Edition (Portable Mba Series) by Eric Verzuh (Paperback – April 25, 2008), where he wrote the Requirements Engineering Chapter, is a co-author of: Business Analyst Certification Program taught at University of Texas at Austin, Rutgers University – New Jersey, UNCC – Charlotte, North Carolina, and has been a Business Analyst and Project Management instructor at University of Texas at Austin, Rutgers University of New Jersey, St. Edwards University in Austin, Austin Community College, University of North Carolina Charlotte (UNCC) [email protected].

Bad-Ass BA Lessons. Part 1.

Written by Cecilie Hoffman on . Posted in Articles.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply “intelligent disobedience” and judicious audacity to your environment to earn those bad ass stripes.

The term intelligent disobedience comes from guide dog training. Blind people who live in cities listen for the auditory cues from a traffic light turning green to tell them it is safe to step off the curb into an intersection and walk across the road. Their guide dog is trained to watch for cars that aren’t showing signs of stopping. When the dog sees danger to their human, the dog is intelligently disobedient, and stays in a “sit” position, letting the human know that they shouldn’t step into the path of danger.

Judicious audacity is the intelligent application of aggressive boldness; that is, taking control of the situation in a fearless fashion because it is the effective and efficient thing to do.

Caveat emptor: there is a significant amount of risk inherent in many of these actions, though the payoff is high. Buckle up tight, fellow BAs, here we go.

Step 1. Exploit the Hidden Power in “Menial” Tasks
Step 2. Delegate!
Step 3. Compose in Real Time
Step 4. Define Gonzo Success Criteria
Step 5. Ask the Crazy-as-a-Fox Stupid Questions
Step 6. Get Their Attention
Step 7. Schmooze those Stakeholders
Step 8. Rat Out those Underachievers
Step 9. Speak Truth to Power
Step 10. Put on Your “Facilitator Flak Jacket”

We’ll cover the first four steps in this article. The remaining steps will be revealed in subsequent articles.

Step 1. Exploit the Hidden Power in “Menial” Tasks

We think that as we advance in our role, we shouldn’t have to do menial work. Tasks like taking notes or writing the first draft of a document or process may feel like they should be beneath us. Wrong perspective! Menial tasks aren’t always low brain power tasks; below are two examples of hidden power for the BA who can leave their ego at the door.

#1: Note taking and the power behind it

When you are the person recording the meeting minutes, you are in control of the official record of the decisions, action items, and open issues. Is the speaker making pronouncements in sentence fragments? You can stop the meeting and request that the speaker give you a statement that can be recorded. Does it appear that a decision has been made but you aren’t sure exactly what was decided? You can stop the meeting and request that someone give you a summary so that you can record it properly. Has an action item been agreed to? You have the power to suggest who should own that action item and what the due date should be. Is note taking a menial task? Hardly. You’re actually running the meeting and finalizing the decision making.

And, of course you are taking these notes directly in electronic form. Pen and paper is a luxury reserved for CEOs and poets; the rest of us have to be more efficient.

Before sending out the meeting notes, you should summarize the key points and decisions. Was there some fuzziness around a particular topic? Clarify it based on your business understanding or by contacting the Subject Matter Expert (SME). This is like stealth direction setting. And think of the visibility you have when you send around the meeting notes for comments and correction. Just be sure to have “recorded by ” in the meeting notes.

#2: Seize the moment: Draft the initial process/doc yourself

Do you ever get impatient with the lack of progress, or the inability of some people to get past a blank template? Start the document yourself and send it out to the team as a “suggestion”. The trick is to influence the process by presenting your ideas to kick-start everyone else’s thinking. Your natural BA instinct will be to try to get everything right before you show the document to anyone. In this case, though, you don’t need to get everything right because you are influencing, as opposed to analyzing; you’re pointing people in the general direction that you think is best, and encouraging them to build on top of your suggestions.

Step 2. Delegate!

Delegate? How am I supposed to delegate? I’m a single contributor, I can’t delegate; I get tasks delegated to me!

True. We BAs are single contributors, we don’t have the authority to delegate, but we have earned the right to suggest that a particular person or group should perform a task. In Step 1, above, there are two methods of “stealth delegation”:

You can delegate by recommending a person to own an action item from a meeting. If a person has special knowledge or interest in a particular area, it is appropriate to suggest they bring their expertise to bear on a task in that area. Minimally, you could ask them to draft a few slides or a couple of paragraphs outlining their ideas or concerns, which you can incorporate in the deliverable. They are likely to come up with some points you wouldn’t have thought of as well as being more invested in the success of the effort.

Delegate by putting a comment in a draft implicitly assigning a section by asking a question of a specific stakeholder, e.g., “Stakeholder A, do you have anything to add here?” Then follow up with that stakeholder both privately and publicly.

There’s also delegating by trading tasks – what can you do for the individual that you want to do something for you? This sort of “horse-trading” is a great way to leverage your own skills to obtain something you need, but can’t accomplish on your own.

In all these cases, be very clear about what you need from the person and when you need it. Follow up with them approximately half way through the time you have allowed for the deliverable to make sure it’s still on their radar. Be sure to emphasize that their special knowledge and input is vital to the success of the project and thank them for taking the time to contribute.

Step 3. Compose in Real Time

Whether you are doing a structured walkthrough of your BRD, or real time process development, when you have a live audience for work that is happening in real time under your fingertips, the pressure is on. This is one of the stages on which you earn your Bad-Ass BA performance award, if you are truly a master of your craft.

Let’s say you are using one of the many application sharing tools that allow people to see what is on your computer screen, no matter where in the world they are physically located and that you are revising the phrasing of a requirement that is giving people heartburn. Three people are talking at once. While you retype the offending requirement before everyone’s eyes, you get to say,

“Folks, let’s agree on who is the actor, here. Do we agree on that it’s the system? Good. Now, what was the exception condition that someone identified? Wait, what has to happen to trigger this requirement to come into play. One at a time folks! One at a time! Any conditions? No? Okay. Let me read this out loud to see if makes sense…. I think we want a different word, here, how about “configuration”? Any disagreement? Good. Now give me a moment to tune up the action … okay, please read this to yourselves. (count from one to five silently) Does anyone feel this does not express what we are trying to capture? Great. What’s the next one we need to work on?”

You own the stage, you clearly own the material, you are in the driver’s seat and you are getting the job done. Furthermore, you are putting pressure on the people who disagree to get their issues out in the open and resolve them by asking if anyone disagrees and explicitly making silence equal consent. The key is to determine when you’ve captured the meat of the idea and not let people wordsmith themselves to death.

How did you develop this skill? You’ve been taking notes in meetings (see Step 1, Point #1, regarding CEOs and poets) for years and doing the same thing; now you’re just doing it before everyone’s eyes and making it look easy.

Step 4. Define Gonzo Success Criteria

Slang: “gonzo” means conspicuously or grossly unconventional or unusual

As an exceptional BA, you should already have gotten all your project team members and stakeholders to focus on the success criteria for the project and the on-going process. Now take a dramatic step and get them to focus on the end customers’ success criteria for the on-going process. When you start doing this, the team members and stakeholders are likely to tell you that you are crazy and what you’re suggesting is impossible to do/measure/implement. Don’t worry, that’s a natural reaction to out-of-the-box thinking, and you are way out of the box.

The point of focusing on the customers’ success criteria is that we usually measure what is important to us, and what we feel is reasonable to measure. Too often, what we think is important is not what the customers consider important. Here are two examples to illustrate different aspects of this.

Scenario 1.

Airlines have determined that customers’ satisfaction is impacted by how long it takes to check in for a flight, so it makes sense to have a requirement that the flight check-in process be as efficient as possible, and to measure the time it takes to check in. It would be sensible and relatively easy to measure the time it takes for the counter personnel to key in the customer’s information and provide the customer with a boarding pass. If you are the customer, however, when do you start measuring the time to check in? Probably when you get in line at the counter.

So if there’s a 20 minute wait in line because the airline hasn’t staffed the counter properly, it may not matter to you that the time it takes the counter personnel to key in your information has been cut from 10 minutes to five minutes. Nor would you be impressed if they were able to cut it further to two minutes – you are still irritated by the long wait in line. The gonzo success criterion comes from looking at something that the airline doesn’t nominally control and may find difficult to measure: the amount of time spent waiting in line. Once you change your point of view to the customer’s, however, further improvement in the pieces of the process that you control may be wasted investment, compared to extending your control to other, more difficult to manage and measure portions of the process.

Scenario 2.

Software companies don’t want to give away support for their products so they generally require customer companies to pay for a maintenance license. When someone from the customer company calls in for support, the first thing the software company does is determine if that contact and company is entitled to support by checking that company’s “entitlement data”. It makes sense to the software company to make it as easy as possible for the customer companies to keep their entitlement data up to date, so the software company could have developed success criteria about how much time it takes the customer to update entitlement data. From the customer company’s point of view, however, there may be no reason to value entitlement data; the customer company just wants support, now. The customer’s success criterion is for the software company to “automagically” know that they are calling about a legal copy of the software for which maintenance has been paid.

Manual maintenance of entitlement data is just one possible way to meet that need. If the software company came up with another solution that led to the software itself automatically maintaining the entitlement data when it is deployed or updated, the customer would probably be delighted. But as long as the success criteria assumes that entitlement data must be maintained manually, the customers’ real needs are being overlooked. In this case, the gonzo success criteria requires ignoring the solution already in place and getting back to the customers’ underlying need.

As a business analyst, you are used to putting yourself in other people’s shoes to figure out what they want. Use that skill to add the end customer point of view to your requirements and metrics and you will increase your value enormously.

This is the first installment in a three-part series. The next installment will cover

Steps 5 to 8.

Installment 1

Business Analyst Times June 16/09

Step 1. Exploit the Hidden Power in “Menial” Tasks

Step 2. Delegate!

Step 3. Compose in Real Time

Step 4. Define gonzo success criteria

Installment 2

Business Analyst

Times July 14/09

Step 5. Ask the crazy-as-a-fox stupid questions

Step 6. Get their attention

Step 7. Schmooze those stakeholders

Step 8. Rat out those underachievers

Installment 3

Business Analyst

Times Aug 11/09

Step 9. Speak truth to power

Step 10. Put on Your “Facilitator Flak Jacket

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

Managing Large Groups of Stakeholders

Written by Jonathan Malkin on . Posted in Articles. 1 Comment on Managing Large Groups of Stakeholders

You’ve just been assigned a new project.  You’re excited to get started but then find out the customer wants to have 18 stakeholders instead of the usual six to eight.  Reaching consensus with 18 people is a little more difficult than with six people.  Try getting 18 people to agree on lunch and see what I’m talking about!

How do you handle a large group of vested stakeholders? 

  1. Push back on constraints
    Part of your job as a business analyst is to ask the tough and uncomfortable questions. Why does each of the 18 people need to be at this meeting?  Is each person a decision-maker or a provider of information?  Six providers of information were asked to provide their data in advance.  By providing information ahead of time they were no longer required at the meeting. Why are they there?
  2. Double the estimates for all work
    Reaching consensus in a meeting is one thing.  Reaching consensus on document reviews once everyone has gone back to their regular work schedule is another.  Make sure to double the expected turn-around time for all document reviews or other work requiring participation of all stakeholders.
  3. Organize the team
    Make sure each person on your team knows his/her roles and responsibilities.
    In our meetings typically I present, facilitate, and generally do the “song and dance”.  The project manager documents decisions, action items, why decisions were made, and anything else that may help.  The subsequent work of managing the project schedule, conducting analysis, and other key tasks is also clearly divided. 
  4. Expect additional work
    Additional tasks will “spring up”.  The project sponsor may request reviews, demonstrations, or other key meetings to keep abreast of all decisions and changes.  Make sure to do whatever it takes to make this person happy.  After all it’s the project sponsor who ultimately calls the shots and signs your check.

In my recent experience, a project sponsor wanted to see the “user experience”.  I created a document including a flow chart and screen shots walking through a simple purchase scenario.  We reviewed the document, demonstrated a live system and answered all of her questions.  The project sponsor was given a clear picture of the system she purchased and was able to assign additional tasks to her staff.

In summary, with a little planning and preparation, working with a large group of stakeholders can be a rewarding experience that asks you to work in new ways, to be patient and flexible,  and to improve your skills.  

Jonathan Malkin is a Business Analyst at Plateau Systems.  Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems.  Jonathan’s areas of support include 21 CFR Part 11 Validation, SF-182’s, EHRI compliance and customizations to COTS software for which he has won multiple awards.  His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries.  Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.

Jonathan may be reached by email at [email protected] or by visiting his LinkedIn page at http://www.linkedin.com/in/jmalkin

Why Agile?

Written by Cynthia Low on . Posted in Articles.

What’s so Great about Agility?

The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest “new thing”? Or is there some real value to it?

“Agile,” as a set of software development methods, was defined seven years ago, so the “flash in the pan” would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.

After defining what Agility is and is not, we will look at the value it can bring.

What is Agility?

The Agile approach has a number or key attributes that can be referred to as the “Essence of Agility.” They are:

  • Learning and adaptation – Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
  • Collaboration – The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
  • Customer focus – The customer is the central focus of an Agile project and is actively involved throughout.
  • Small self-directed teams – Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
  • Lean principles – The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like “Just Enough” and “Just in Time.”
  • Progressive requirements elaboration – We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn’t make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
  • Incremental delivery – The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer – at least for acceptance testing.
  • Iterative planning and adaptation – Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.

What is Agility Not?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

  • No documentation – The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
  • No planning – Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.
  • No requirements – The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
  • No schedule or budget control – Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”
  • Programmers doing whatever they like – The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

The Value of Agility

There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:

  • The right product – The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
  • Quality – Agility always includes a strong focus on the quality of what is built. This includes not only the customer’s acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
  • Schedule and budget – Time-boxing of an Agile project means that its schedule and budget are rarely “over-run” If things don’t work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer’s and management’s full concurrence.
  • Early warning – Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
  • Adapting to change – Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.

Every business values agility (lower-case “a”). What many are finding is that Agility (upper-case “A”) provides what it promises.

Copyright ©2009 Global Knowledge Training LLC  All rights reserved.

Alan Koch, PMP, is president of Ask Process. Inc., (http://www.askprocess.com/) and an instructor with Global Knowledge Training LLC. A longtime member of the business analysis community, Mr. Koch has 28 years experience in software development. He can be reached at http://ca.mc883.mail.yahoo.com/mc/[email protected].