Organizations that are successful implementing agile approaches typically agree to support one main Agile Manifesto principle which is to value ‘individuals and interactions’ over ‘processes and tools.’ Agile is not a departure from principles that BAs have always embraced. We absolutely agree that it is difficult to elicit the best requirements without direct interaction with the domain subject matter experts and developers!

One major principle of agile is collaboration. Agile employs team collaboration in a variety of ways. First in agile approaches complete visibility is necessary. Whether the team works in a single war room or virtually using a SharePoint site, visibility into the progress of the project is a critical element. This really helps eliminate miscommunication around what is being worked at any given time. Additionally each agile project uses a prioritized requirements list to keep clear and visible the order that requirements must be worked addressed (in Scrum this is called a Product Backlog). Led by the product owner (project sponsor, product manager or key domain SME), everyone on the team participates in determining how many of the prioritized requirements will be included in the upcoming iteration.

Requirements are developed using collaboration. These requirements, often called user stories, will be briefly described at first on sticky notes or index cards (this can be done virtually) and they get detailed through more conversation with the users or user reps when the requirement is to be coded. Early user acceptance testing, and product demos (again another collaborative activity) really help everyone on the team understand whether the requirements are being correctly translated. Failing requirements are visible early in the project rather than waiting until the end of the project lifecycle during user acceptance testing on a traditional, plan driven project to find serious issues.

One more collaborative technique is the daily stand up meeting which many agile projects employ. This is a quick meeting with the entire team to ensure that everyone has visibility about the progress of the iteration. Project issues are discussed to inform everyone on the team and bring focus together to solve them quickly. In addition, everyone knows what each person is going to be doing on that day and how they will work together.

You may be asking what elicitation techniques a BA would use on an agile project. Interviews and facilitated user story workshops are most common but observation, document analysis, surveys, focus groups and prototypes are also common. Early user acceptance testing will be used to confirm that the requirements are correct.

BA’s may perform elicitation activities prior to the Iteration planning. This is sometimes referred to as Iteration zero (0). Again the key concept here is to make sure the business people or users are engaged as much as possible throughout the agile lifecycle. Compared to traditional projects the level of requirements detail known prior to the start of the iteration is less. It is on a smaller scale and typically requires fewer analysis techniques due to the tight timelines. One risk the BA faces on agile projects is that during the iteration if the business people are not available, the BA may need to represent the business and make requirements decisions. To do this the BA must have a deep understanding of the business. It is highly recommend that the BA work closely with the business to make available the appropriate SMEs during the time user stories are being detailed and tested for confirmation.

Agile and the BA – Part 2 will discuss how a BA can best be prepared to work on an agile project. I hope you will share your comments, experiences and concerns about agile projects. Collaboration works!

All the best,
Angie

 Learning Points

• The real difference between a PM and BA
• Leverage project management skills to make yourself a better business analyst
• Build a great PM and BA partnership
• Career paths beyond project management

• Q: I’ve always tried to teach you two things. First, never let them see you bleed.
• James Bond: And the second?
• Q: Always have an escape plan*.

*From the James Bond movie (The World is Not Enough)

In case you have never followed the Bond movies, Q was typically an elderly gentleman who would invent and demonstrate all the cool gear that Bond would use to confront and avert danger.

Imagine how great it was that 007 had the right weapon, tool or technique to keep ahead of his enemies and avert any danger. Glasses which could shoot bullets, exploding gum, ropes and parachutes that would suddenly appear in the throes of imminent doom, speed boats or cars, blasting from the water to land, allowing Bond to apprehend the bad guys in the most incredible way.

Q’s advice to 007 also works for business analysts.  A business analyst, like 007, needs to be skilled and confident. A BA must plan to be prepared for all the normal situations (never let them see you bleed) and an experienced BA must always have a well thought out “escape plan” to preempt failure even when the unpredicted occurs.

Q’s rules can help us change the negative perceptions of the BA role that some still hold. Have you ever been frustrated at complaints volleyed by the agile community against business analysts?  “A BA is an unnecessary middleman. The BA is an impediment to meeting project deadlines. BAs are often inflexible to react appropriately and efficiently when it comes to determining how much documentation is needed on each project.” Yada, yada, yada and on it goes. According to some there is no need for a business analyst on software projects. As a profession we need to collectively change this view of our value.

Never let them see you bleed
One approach is “Never to let them see you bleed”.  In other words prove the naysayers wrong on every project you work by making a difference to the final outcome and providing the highest value. Give them a reason to request you in the future because you have shown that you are prepared, confident and efficient. There are steps you can take to build an excellent reputation.
 
When assigned to a new project an experienced BA can hit the ground running by quickly sizing up the project and looking for similarities from prior projects. Considering those common threads, you can confidently plan the next steps in short order. For example, if you have previous experience with the project stakeholders, with that prior knowledge you know which elicitation methods and communication channels will work and can move ahead quickly.  As you articulate exactly what techniques or deliverables are necessary (and why) to anyone who asks you begin to change the negative attitudes about the efficiency and effectiveness of a BA.

Or take an example of a project similar in purpose, such as a complex enterprise COTS project where many different stakeholders were involved. You already know what type of documentation is necessary and how formal it needs to be. Lessons learned from the prior projects will provide a roadmap for the next.  Another key is to define deliverables necessary based on the project risk and to be secure in advocating those that need to be done to reduce the risk. You are not out to create the perfect requirements document but to ensure you have captured enough requirements clearly and correctly. You are focused on eliciting what needs to be understood and documented (communicated) for project success. Every project has some unique characteristics but many of the same characteristics that can be leveraged to the next effort. Adequate planning based on previous projects is a great way for you to stay in control of all the customary tasks that need to be done and to set proper expectations with the project team and other stakeholders.

Another timesaver is to look for repeating patterns from project to project where you can apply similar solutions. Patterns can be found and not limited to business processes, business rules, data, interfaces, stakeholders, business units, enterprise efforts, types of risks, type of defects, budgetary constraints etc. Look for the sameness in each new project so you don’t spend time reinventing the wheel on each project.

At the beginning of every project taking time to plan the BA activities, consider the project risks, review lessons learned, and pausing to think about any similarities or patterns from prior projects can improve your BA efficiency and value. When you practice repeating certain things time and time again with success you will become more confident in your recommendations and “never let them see you bleed”.

Always have an escape plan
Appropriate time set aside for planning is wonderful for identifying what needs to be done and accomplishing it efficiently for the normal course of events. On every project there is some amount of negative risk, hence we need a well thought out escape plan. One type of escape plan is that the BA is on the alert for business risks and unexpected issues. As mentioned, certain types of risks can be the same from one project to the next. Proactively managing risks on a day to day basis by prioritizing high potential and high impact risks and preparing risk response plans are a great way to have available the necessary escape plan. When negative business risks become a reality it is always better if you have already thought about what to do and have an action plan ready for how the problem will be handled. I think “Q” would be proud!

Another example of being ready for the unexpected is to always work on the most important requirements first. You should always know the priority of the requirements. This is considered a best practice. Then if the project has to all of a sudden be cut short or the analysis time is not enough to complete all requirements, the most important requirements are completed. This practices gives you an elegant escape plan.

Now in summary to mix my metaphors just a bit. I want you to imagine the Mission Impossible music, picture yourself as the BA James Bond, and think of your current project as you recite the mantra of these two rules:

1. Never let them see you bleed and
2. Always have an escape plan!