Schwaber differentiates Scrum from traditional methodologies and he asserts that Scrum is not prescriptive (Scrum does not describe what you should do in every circumstance). Sutherland and Schwaber admit they did not invent Scrum ideas. Both remind us that Scrum is a framework of best practices, which have been proven for years. Above all, keeping project work collaborative, honest and visible so that the team (and everyone else) knows exactly what is going on is representative of an agile self-organized team. Scrum and other agile processes focus on the practice of inspect and adapt allowing adjustments to be made as needed to keep the project moving toward the desired goals to produce business value with working software. Schwaber said more than once that Agile and Scrum rely on intelligent people doing the right thing at the right time. You can listen to Ken or Jeff talk about Scrum on You Tube. If you are interested in learning more about agile without leaving your desk, there are a number of instructional (and humorous) videos on You Tube about Agile and Scrum. Check it out. Please share your BA experiences on agile projects.

All the best,
Angie

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

As a BA there are a number of elicitation steps and analysis steps I may need to go through to figure out what solution will truly create advantage. I really appreciate what the author said about designing to performance. Depending on the problem, often it is a performance issue, especially in manufacturing or engineering industries. Not always. Times are changing and new practices may be needed. For any innovation, BAs must learn and adapt.

SMEs, BAs, architects and developers are often most effective when they are housed together, all part of the same team- and guess what? Some of us have been working on those types of teams going on 30 years before the word agile was ever coined. Really understanding your customer will always be a best practice. For me, familiarity breeds success rather than over the wall contempt. Having the appropriate resource allocation (the right people who can make decisions) and a sound, light-weight process (something iterative) are what I consider a best practice for success. Having worked with many cross-discipline, cross-functional teams, I have never found a better replacement for these best practices: an agreed upon approach, clear objectives, team collaboration, trust, and enthusiasm and throw in the appropriate amount of management support are all enduring and dare I say best practices that can bring any project to a satisfying goal. Oh wow am I showing my age? OK well maybe today our team may be global and we have to do most tasks with a web cam, use collaborative software, SharePoint, wikis, texting and Twitter but the rest still endure!

Collaboratively yours,

Angie

Someone asked why the BA definition in the latest BABOK v2.0 no longer uses the metaphor of a bridge between Business and IT. Kevin Brennan of the IIBA responded that

1. the BA role may not deal with an IT component 
2. the BABOK did not want to”promote a definition that appears to limit BAs to a facilitation role”.

I still like the bridge metaphor but I applaud the motivation of the IIBA to discontinue descriptions that sound like the BA does nothing but take notes from one group and translate them back to another.

Of course a BA is a facilitator eliciting requirements from different stakeholders, working with various business and technical stakeholders to reach consensus and shared understanding about their disparate needs and intentions. A typical BA masters many other analytical and design skills, particularly critical thinking, and problem solving in addition to facilitation. I respectfully disagree that the bridge metaphor limits BA role, and I will slightly change the metaphor and say the BA is more like a bridge-builder than a bridge. After all, BAs do not want to have the masses walking or driving over us to get to the other side. Ouch! BAs construct real bridges so people can reach their destination faster and safer than they would without one.

The most important message about the bridge metaphor is that you reach the other side successfully. Along the way – as the BA is building the bridge, the BA establishes trust, promotes collaboration, demonstrates active listening skills rather than pushing their own agenda, practices good time management and organization skills, focuses on critical requirement priorities, employs rational analysis techniques to suit the situation while simultaneously communicating clearly and succinctly in the most effective style that fits each stakeholder.

In summary to be an expert bridge-builder you must master many hard and soft skills and techniques to connect with various stakeholders (conversing in their unique languages and adapting and learning their terminology and about their systems and processes). Our ultimate goal is to bring everyone along to the other side successfully and to perform this feat well enough that we are asked to build many more bridges in our career for years to come.

All the best,

Angie

• 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!

To make your case stronger you will want to read the new white paper we have available for download. The paper is co-authored by Barbara Carkenord and Kimberly Terribile and discusses how skilled business analysts are instrumental in providing a number of organizational benefits including reducing a variety of costs on projects. Some interesting survey results also included. Download it now at http://www.b2ttraining.com/downloads/

©2009 David Ewing and World of Stock.

I had a discussion recently with a client about how the role of a BA in many organizations was traditionally thought of as a scribe in meetings. Thankfully with all the recent focus on business analysis as a discipline, the many different skills provided by a business analyst are just beginning to be understood by many industries. Why does a business analyst make a good scribe?

Business analyst professionals develop excellent listening skills, especially for details, throughout their career. One of the critical competencies of a business analyst is to provide clear, concise, and complete communication in many forms. The ability to record the critical elements of a project meeting is a walk in the park for an experienced BA. It is not the most challenging or glamorous thing we can do but concise minutes and clear agreements save a project team valuable time not having to revisit old issues and really help in getting new members up to speed.

Should BAs always be expected to scribe? No, but we can do it better than most. The good news is that clear, organized minutes are just a tiny aspect of the true value the business analyst role brings to a project. If you find yourself occasionally being the scribe, I have a few recommendations that I have used:

1)     Use a standard meeting template to keep the minutes organized.

2)     Provide context for the minutes by providing pertinent details, such as the meeting purpose and agenda, the date, time, length of meeting, location, invitees, attendees, and absentees.  Listing attendees will help with the next item. Be concise in all your descriptions.

3)    Keep a running log of decisions instead of trying to record every conversation that took place during the meeting. Project teams spend precious time revisiting topics with people who were not present or who forgot the results. Minutes reflecting decisions as well as the decision rationale will prove invaluable.

4)    Provide details about any open or new action items assigned during the meeting. Include a clear description about what is expected, who is accountable for the action, as well as agreed-upon deadlines. People who are responsible to complete an action must agree to the task and timeframe to be truly accountable.

5)    Include any associated documents needed by the reader to understand the meeting content. If during the meeting you reviewed a requirements package, attach it to the minutes, or if someone provided a presentation, include the PowerPoint slides. Even better if your project has a shared area for file posting and sharing - provide the document location in the minutes. Leading people to the appropriate document will alleviate the reader frustration by giving them quick and easy access to the necessary information and will prevent you from clogging up the email system with large files.

6)    Send out written meeting minutes and documentation in a timely fashion, usually within 24-48 hours and request feedback about any corrections. If you have regularly scheduled meetings you may want to start each meeting by asking people to approve the previous meeting decisions and actions.  

7)    If you have a shared directory, or project wiki or some other document manager available where you can post the weekly minutes and project documents – this helps the entire team stay in sync. A shared site also makes it convenient for team members to collaborate and to pull information as needed.

In summary, although BAs have many valuable skills that benefit the project. They are also likely to be among the best, if not the best communicators on the project. No matter how well respected you are as a BA, you are occassionally going to take minutes. So let’s be a team player and go for it! If any one has any good tips for meetings or a good meeting template to share, please write.

A very simple of example would be a business process which notifies a customer regarding their current order status. A customer may be contacted through email, phone, fax, an IVR solution, or directly via some other software like a CRM application etc. How the process is accomplished does not matter during business requirements but understanding why there is a need to make customer contact is important and additionally the information or data that needs to be communicated to the customer is also important.  The mechanism to be used to accomplish this communication is not yet necessary and if determined too early limits the solution options.

Most people agree that Business Requirements include high level statements such as the project mission statement, business objectives, scope, out of scope items, any assumptions and the constraints in a project. I would add that a crucial part of the business requirements are details about the affected core business processes, the data needed by those processes, the business rules, and the external entities that will interface with the business system under investigation. Until we have a detailed understanding of the business processes and interfaces we will continue to be challenged in defining the right solutions. Without understanding the “why” and “what”, sometimes we fix what’s not broken. Other times in solving one problem others are created.  As in the worn out phrase…”the devil is in the details” this really holds true in the BA’s world. A business analyst cannot be expected to enhance the levels of efficiency and effectiveness in business operations if he or she does not understand specifically where there are bottlenecks, redundancies, defects, and other inefficiencies that affect service, quality, timeliness or cost. 

Suggestions for CBAP® Exam Preparation

The following are recommendations from IIBA® on how to prepare for the CBAP® exam. Note that following these recommendations does not guarantee passing the exam.

·         Review the IIBA® BABOK®.

·         Review Frequently Asked Questions (FAQ) on the IIBA® Web site.

·         Review recommended resources on the IIBA® Web site.

·         Attend training, as needed.

·         Find opportunities in day-to-day work to practice tasks by following the BABOK®.

·         Find a Business Analysis mentor.

·         Join a study group.

·         Network on the IIBA® forum and/or attend local IIBA® Chapter meetings.

·         Review available study guide(s). 

The CBAP® exam is 3.5 hours long and consists of 150 multiple choice questions with four possible answers to select from. Some questions are based on “comprehension” (e.g., definition, recall, etc.) and others are based on “situational analysis” (e.g., given a scenario, which is the best course of action) where the applicant must do a bit of analysis to arrive at the answer. It is neither all of one type or the other but covers a range of Blooms Taxonomy.

Exam blueprints based on v1.6   exam versus new. v2.0 of the BABOK®:

13 6/30/2009

Click here to view the entire handbook now.

Organizations often prefer COTS applications because of a belief that these applications can be implemented faster out of the box than homegrown systems with very little custom development or ongoing IT maintenance. One mistake companies make is choosing a vendor or package before thoroughly analyzing their business requirements. Just like any other project the business drivers, the core business processes, the data, business rules, the users and external interface requirements need to be defined and understood before a solution is selected. Once the requirements are defined, performing a gap analysis with each of the COTS applications under consideration is recommended.

Whatever selection process is used, it’s my experience and many of our customers’ that COTS applications still require costly ongoing customization. Having worked in many large organizations that implemented different COTS products, I have a negative bias as I can’t recall too many success stories with COTS implementations or cost effective maintenance. I remember one example of a huge company where I worked that implemented a variety of well-established COTS packages. Following a merger with several other companies (who had their own COTS applications) and an analysis of the COTS maintenance costs, a new strategic direction was formulated which eliminated almost all the COTS applications. Future development efforts would be handled in-house. The main drivers for the change were across the board cost savings, business process differentiation and timely change management. In the past vendor maintenance costs continued to escalate as more and more customizations or features were needed to keep up with changing business requirements. As new requirements surfaced it was difficult finding developers with the right expertise. Additionally the vendor consultants, who really knew the underpinnings of the COTS design, were very expensive, not always available and did not always understand our business requirements. With customizations implemented, future upgrades to the product became very complex and risky. Lastly, some requirements were flat out rejected because they were in conflict with the COTS design or base product. Luckily today’s COTS applications are designed to be much more modular and scalable then some of the products in the past.

Let’s start a discussion about your experience with COTS implementations and customizations. Please feel free to vent and share any challenges you have experienced with COTS implementations or maintenance. Please share your lessons learned and what steps you take to work best with COTS selections and enhancements.