Skip to main content

Tag: Business Analysis

Carl’s Top Ten List of Questioning Techniques for New and Not So New Business Analysts

Written by Carl Miller on . Posted in Articles. 1 Comment on Carl’s Top Ten List of Questioning Techniques for New and Not So New Business Analysts

(Courtesy of the School of Hard Knocks)

Numerous studies on the failure of IT projects has indicated that the lack of user involvement as one of the leading contributors. As Business Analysts we realize it is not only the quantity of involvement but also the quality of that involvement. Good questioning techniques allow Business Analysts to constructed the required models from which requirements are elicited.

One of the most frequently asked questions by new (and not so new) Business Analysts is about questioning techniques and what questions to ask. Here, in David Letterman style, is my top ten.

10. Be prepared. 

We ask questions to elicit information that allow us to construct and validate models. So make a list of questions:

  • Where do you sit in the organization (org model)
  • What are your inputs / outputs?
  • Can you give me an example of them?
  • What are the volumes
  • What is the quality of inputs /of outputs? (i.e. what is the metric)
  • What is the flow of work

These are at the information level i.e. getting the facts, figures, information. Being prepared will help completeness. With the information gathered, could you construct the models desired?

9. Ask open ended questions

Open ended questions i.e. what is the toughest part of your job? This allows people to as we say ‘walk in with their stuff’. It allows them to bring up what is important to them. .

  • allow them to walk in with their stuff
  • allow them to identify their issues
  • don’t give them leading questions

Sometimes this unearths significant problems. True sometimes open ended questions lead down rat holes. My view? The user will talk about them or at least have their concern colouring their answers. Better to get them out on the table, deal with them and move on.

8. Follow the lead of the interviewee without giving up control

  • You control the interview
  • You do that by blending your agenda to their style
  • It’s not a battle of styles – reflect the interviewee style
  • Follow the lead of the interviewee but be prepared to re-direct as required
  • The purpose of the interview is for you to get the info you need

7. Draw a picture…in pencil

  • It’s an iterative process …let it be that
  • Build models and let the user alter them
  • Stretch and direct the users thinking

(thinking now of data flow…thinking now about inputs/outputs, thinking now about quality metrics) 

6. Talk to the consumer of your analysis document

  • You are the liaison between the business and IT
  • Are the consumers getting what they need to do their job?
  • How do you know they are?
  • There are standard modeling techniques derived for good reasons – use them
  • Be part of making them even better – we are always in transition

5. Ask probing questions

  • Why is it so important to you?
  • What keeps you up at night?
  • If you could change three things about the process what would they be?
  • Make them think not just give you facts and process flows
  • These are higher level questions than information gathering

4. Use active listening to ensure understanding

  • Make sure you understand in a way the interviewee intends
  • Ask clarifying questions
  • Ask for examples
  • Paraphrase and then ask ‘Did I get that right?’

Make sure you get a confident confirmation before continuing, otherwise try again until you do get it right from the user’s perspective. 

3. Talk to the horse as well as the trainer

  • Everyone has a view of the problem
  • All views are valid from their own point of view
  • One point of contact is efficient but can you get everything you need?
  • Ask questions they know the answer rather than questions they would have to speculate on the answer.

An executive is unlikely to give accurate process flow but may well know the intent. The reverse is true of the front line workers. 

2. Ask questions to validate answers

  • Ask the same question in different ways and to different people
  • look for metrics
  • look for established methods and procedures to validate
  • resolve discrepancies – when issues are in question attempt to resolve
  • at the very least identify the discrepancy

It is a common error to assume we know more than we do, When we ask a question to which we already know the answer very quickly we learn otherwise and begin to validate information.

1. You are a leader in your organization

  • You represent the interests of the business unit
  • You match business needs to requirements
  • You specify the requirements which satisfy a business objectives/achieve business goals and represent the executive level intent.
  • If you do not represent the needs and interests of the project and executive intent who will?

Don’t forget to leave your comments below.

Decision Making: An Underlying Competency or What A Business Analyst Does

Written by Kupe Kupersmith on . Posted in Articles. 2 Comments on Decision Making: An Underlying Competency or What A Business Analyst Does

kupe Aug27I don’t read the BABOK® all the time, but when I do I focus on the Underlying Competencies. This area is somewhat hidden but needs to be found by all business analysis professionals. The Underlying Competency knowledge area in the BABOK® provides a description of the behaviors, characteristics, knowledge and personal qualities that support the practice of business analysis. However I say they don’t support what you do as a business analysis professional, it is what you do as a business analysis professional. For today’s post I am going to have us take a look at a specific Underlying Competency—decision making—to make my case.

You should view decision making not as something that supports your work, but rather all analysis techniques and processes support decision making. One of your main responsibilities is to help others make better decisions. If decisions are not made during a project nothing can be accomplished. Think about your work. How do you decide on what tasks to do first in your day? We all know that there is not enough time in the day to do everything you want to accomplish. Therefore, you have to make decisions on a daily basis of what activities you should or should not focus on, prioritization. This decision should be based on the work yielding the highest impact on the issues that are most important to your customers. Before you can make good decisions about what to focus on, you need to help your customer decide what is most important to them. To help them do this use supporting techniques and processes, examples include Impact Mapping, Root Cause Analysis, and defining the problem and business outcomes. You see, these tools help to make decisions; decision making does not support them.

Throughout a project there are so many activities that support decision making. One of the key reasons for undertaking stakeholder analysis is to determine who the decision makers are and how they make decisions. Not everyone will agree on the top priorities for the project, so understanding who makes the final decision is critical. If you can’t get a group to decide on the best path, this decision maker has to make the call so the project can move forward. The absence of a decision maker means the risk of project failure increases.

Once you know who the decision makers are you need to know their speed in decision making and what information they’ll need to make a decision. How do you find this out? By asking them. When it comes to the speed of decision making, I split people into two groups: The first is the person that does not want any information until the last responsible moment, and then they want it all. They can take in this information and make a decision fairly quickly. The other wants information over time. Even if the information is changing, they like to get the information so it can whirl around in their head for a longer period of time. Then, when they need to make a decision they feel comfortable making the call. If you approach either one in the opposite way, they will get frustrated. Stakeholder analysis supports decision making!

Elicitation is another activity that completely supports decision making. What? Elicitation is about drawing out information. Yes, this is true, but who cares if you draw out information and don’t use it. You draw out information to help make decisions. Sometimes I think brainstorming is the most misunderstood activity because it gets viewed as a way to quickly come up with ideas. There is so much more to brainstorming. After coming up with great ideas you have to make decisions about how to move forward, like ordering features or stories in terms of importance. The beauty of brainstorming is it allows for the best chance of buy-in. By having everyone share their thoughts and ideas openly they are more likely to buy into a decision on moving forward. Their idea does not have to be chosen, they just need to know their idea was heard by the group. I wrote a blog post about buy-in if you want more information about it.

The last technique I want to hit on today is prototyping. You draw pictures of a part of the system to help your customer make decisions on how they want to interact with a system. You can have multiple pictures and play the eye doctor role, do you like it better like this or like this…one….or two. And it helps the development team decide on the best ways to design the system or features.

Start thinking of all the analysis techniques and processes as tools to facilitate decision making. Having this mindset will allow you to make decisions about what is most important. If the activity you are about to take on helps the team come to a good decision faster: do it.

I have decided I have said enough for now!

Kupe

BA Practice Lead Handbook 10 – Business Analyst Practice Sustainability: A Focus on Innovation

Written by Kathleen B. Hass, PMP on . Posted in Articles.

The remaining articles in this series will be about sustainability: building a BA practice to last. This article will focus on the need for BAs to become creative leaders driving innovation.

In this complex global economy, your organizational change initiatives need to result in innovative solutions; incremental changes to ‘business as usual’ are no longer enough for organizations to remain competitive. Yet, many CEOs do not believe they have the creative leadership needed to capitalize on complexity to bring about innovation.

So what does innovation have to do with business analysis? For BAs to reach their full potential and add the most value to their organizations, they must become creative leaders of innovative change.

Traditional BA activities are still important, but a new focus on innovation is the 21st century call to action.

Business Analyst as Creative Leader of Innovative Change

Serving as a key project leader with a perpetual focus on adding value to the business, the business analyst becomes a powerful change agent.

The business analyst comes to the forefront of project management to close the gap in areas that have historically been woefully overlooked in mission-critical business transformation projects. Areas that are the purview of the business analyst and that require much more attention for project success include: 

  • Conducting enterprise analysis with an expert team of diverse background and capturing the details about the most valuable opportunities in a Business Case by:
    • Defining business problems and identifying new business opportunities for achieving innovation and remaining competitive
    • Understanding the business and the effects of the proposed solution across the enterprise
    • Insisting on innovation, fostering creativity, rejecting business as usual, welcoming ambiguity and disruptive change
    • Maintaining a fierce focus on the business benefits the initiative is expected to bring to the enterprise in terms of value to your customers and wealth to your bottom line
    • Validating that the new solution capitalizes on the opportunity and will contribute the expected business benefits. Managing the benefits expected from the new solution during and after project completion.
  • Translating the business objectives into business requirements using powerful modeling visualization tools. Using an integrated set of analysis and modeling tools and techniques to make the as-is and to-be business visible for all to see, understand, and validate. Using disintegrated desktop tools is simply ineffective because BA deliverables cannot be kept current and consistent, and therefore lose their value as reusable organizational assets.

For BAs to become creative leaders of innovative change, they must operate at the enterprise level and delve into strategy execution. BAs need to think of themselves as change agents, visionaries, and credible leaders.

Business Analyst as Change Agent

The prevalence of large-scale organizational change has grown exponentially in the 21st century. All indications are that change is here to stay. John P. Kotter, professor at the Harvard Business School, is regarded as an authority on leadership and change. Kotter’s prediction:

The rate of change is not going to slow down anytime soon. If anything, competition in most industries will probably speed up even more in the next few decades.

Kotter foresees that as the rate of change increases, the willingness and ability of knowledge workers to acquire new knowledge and skills is becoming central to career success for individuals and for the economic success of organizations. BAs that are able to develop the capacity to handle a complex and dynamic business environment are vital to their organizational survival. These BAs will grow to become unusually competent in advancing organizational transformation. They will learn to be creative leaders of innovative change. 

Powerful economic and social forces are at work to force innovation and change, including the rise of the Internet, global economic integration, maturation of markets in developed countries, emerging markets in developing countries, and the turbulent political and financial landscape. Competitive pressures are forcing organizations to reassess their fundamental structures, products, and the way they interact with their customers. The amount of change today is formidable. Some react to this change with anger, confusion, and dismay, and it falls upon the business analyst to lead the transformations most organizations must undergo. In her role as change agent, the business analyst brings a fresh new approach to projects in many ways:

  • Fosters the concept that projects are business problems, solved by teams of people using technology as a strategic tool
  • Works as a strategic implementer of change, focusing on the business benefits expected from the project to execute strategies
  • Changes the way the business interacts with the project team, often significantly increasing the amount of business resources/expertise dedicated to projects
  • Encourages the technical team members to work collaboratively with the business representatives
  • Builds high-performing teams that focus more on the business value of the project than on the “way cool” technology
  • Prepares the organization to accept new business solutions and to operate them efficiently
  • Measures the actual benefits new business solutions bring to the organization.

Creating and Sustaining the Project Vision

A common vision of project objectives and resulting business benefits is essential for a project team to bring about significant change. A clear vision helps to direct, align, and inspire team members. Without a clear vision, a lofty transformation plan can be reduced to a list of inconsequential projects that sap energy and drain valuable resources. Most importantly, a clear vision guides decision-making so that people do not arrive at every decision through unneeded debate and conflict. Yet we continue to underestimate the power of vision. As a BA, insist on a common vision, as stated in the business case, revisit it often, and use it to drive decision making.

Building your Credibility

When acting as a change agent, the business analyst needs to develop and sustain a high level of credibility. Credibility is composed of both trustworthiness and expertise. A credible leader is one that is trusted, one that is capable of being believed. Above all, a business analyst must strive to be a reliable source of information. In addition to these elements, colleagues often judge others’ credibility on subjective factors, such as enthusiasm and even physical appearance, as well as the objective believability of the message. At the end of the day, professional presence, ethics, and integrity are the cornerstone of credibility.

Credible business professionals are sought out by all organizations. People want to be associated with them. They are thought of as being reliable, sincere—and creative. The business analyst can develop her credibility by becoming proficient in these critical skills and competencies, all of which should be part of your professional development plan:

  • Practicing business outcome thinking
  • Conceptualizing and thinking creatively
  • Demonstrating interpersonal skills
  • Valuing ethics and integrity
  • Using robust communication techniques to effectively keep all stakeholders informed
  • Empowering team members and building high-performing teams
  • Setting direction and providing vision
  • Listening effectively and encouraging new ideas
  • Seeking responsibility and accepting accountability
  • Focusing and motivating a group to achieve what is important
  • Capitalizing on and rewarding the contributions of various team members
  • Managing complexity to reduce project risks and to foster creativity
  • Welcoming changes that enhance the value of the solution or product.

Understanding the Real Business Need: Innovation

Business analysts are now being challenged to rethink their approach—to not just record what the business is doing or wants to do, but to operate as a lightning rod to stimulate creativity and innovation. To do so, business analysts are rethinking the role of the customers and users they facilitate, looking at them as creative resources that can contribute imagination and inventiveness, not just operational knowledge. The business analyst who works across and up and down the organization, getting the right people at the right time and in the right place, can fan the flames of creativity.

Transitioning to Creative Leadership – What does it Look Like?

Creative leaders have many distinguishing beliefs and observable behavioral characteristics. According to John McCann, educator, facilitator, and consultant, creative leaders:

  • • Believe in the capability of others, offer them challenging opportunities, and delegate responsibility to them
  • • Know that people feel a commitment to a decision if they believe they have participated in making it
  • • Understand that people strive to meet other people’s expectations
  • • Value individuality
  • • Exemplify creativity in their own behavior and help build an environment that encourages and rewards creativity in others
  • • Are skillful in managing change
  • • Emphasize internal motivators over external motivators
  • • Encourage people to be self-directing.

Constructive Dialogue

A skilled and credible facilitator can set the stage for groups to engage in productive dialogue that incorporates creativity, ambiguity, tension, and decisiveness. The business analyst is perfectly positioned to be that credible leader and facilitator, one who sets conditions that lead to creativity in motion: You will know it when you see it: Participants are willing to have their ideas and beliefs examined and reexamined; participants look upon each other with respect and realize the benefits that come from open, candid, lively discussion.

Expert Facilitation

As a creative leader, the business analyst combines constructive dialogue with expert facilitation as creativity-inducing tools for stimulating the sharing of unique ideas. Not only does the collective “IQ” of the groups the business analyst works with rise, so can the CQ, the creativity quotient. In fact, business analysts who encourage creativity and guide groups at all levels through the innovation process can increase an entire organization’s CQ.

Thinking Outside the Building

The greatest future breakthroughs will come from leaders who encourage thinking outside a whole building full of boxes.
—Rosabeth Moss Kanter, Ernest L. Arbuckle Professor of Business Administration, Harvard Business School

What kind of barriers should business analysts expect to encounter when they try to become the invaluable creative leaders organizations need today? The creative leader must learn to penetrate a formidable set of customs that exist in any organization. In a Harvard Business Review column, Rosabeth Kanter calls these organizational cultural barriers “inside the building thinking.” These may pose the strongest obstruction to creativity and innovation. 

What does this mean for the business analyst in her role as facilitator, charged with helping groups engage in productive dialogue? Business analysts must be cognizant of the fact that their first inclination—and the first tendency of their stakeholders—will be to limit their options by focusing on similar companies doing comparable things. So it is up to the business analyst to be aware of and encourage the group to penetrate the inside-the-building boundaries.

To unleash creativity, business analysts must challenge their stakeholders (users, customers, managers, project managers, developers, and executives) to use not only systems thinking, but also complexity thinking and out-of-the-building thinking to look at the entire ecosystem that surrounds their organizations. It is only then that they can set the stage to bring about lasting innovation.

Becoming a Creative Leader

Leadership is the capacity to mobilize people toward valued goals; that is, to produce sustainable change—sustainable because it’s good for you and for the people who matter most to you.
—Stew Friedman, author, innovator, management professor at the Wharton School

Stew Friedman, professor of management at the Wharton School, former head of Ford Motor’s Leadership Development Center, and author of Total Leadership: Be a Better Leader, Have a Richer Life, posed this question to business leaders across the country: “What kind of leadership do we need now?” The most common response was adaptive, flexible, and innovative. Because of the current sense of turbulence in the business world and in our lives, the leadership attribute that comes to mind most often is a means for dealing with chaos, which Friedman calls playful creativity. 

Every person can have a capacity for leadership, regardless of organizational level or title. Leadership should not be confined to work but extended to one’s personal life, community involvement, and family life. So how do we become creative leaders? We need to actively work at it by experimenting with how things get done at work, as well as in other parts of our lives. It is not the experiment that counts, but what we learn from it. Did we really create something new? What worked well, and what didn’t?

Putting it all Together

So what does this mean for the Business Analyst?

BAs must continually strive to overcome the three great inhibitors to creativity: fear of failure, guilt about appearing to be self-centered, and ignorance of what’s possible. If BAs are not focusing on removing these barriers through experimenting, imagining, and continually trying new things, then they are “missing opportunities to strengthen their capacity to gain control in an increasingly uncertain world.” Hence, Friedman asks: “So, what small wins are you pursuing these days? How will they improve your ability to be creative and to have greater capacity to adapt to the rapidly shifting realities of your life and work?”

Creative leaders produce sustainable change. Strive to become a creative leader—and strive you must, because creative leadership is gravely needed for your organizational survival.

Leaders rely on their credibility and ethics to succeed; never sacrifice your integrity. Create the most sophisticated professional development plan you have ever had. Focus your plan on communications, creativity, innovation, facilitation, and team leadership. Include all types of learning:

  • Formal training and certifications
  • Informal mentoring
  • Experiences that stretch your capabilities
  • Self study
  • Reading, reading, reading.

Finally, don’t take yourself too seriously. People want to work with leaders who are credible and present themselves well, but they also want to have fun. Learn how to balance seriousness with playful creativity. Spend a lot of time planning your meetings, the techniques you will use, the outcomes you need. Then take a step back and make sure the experience will be fruitful, rewarding, and yes, fun for all participants.

So what does this mean for the BA Practice Lead?

If you are a BA Practice Lead, insist that your BAs conduct real enterprise analysis to drive innovation before a Business Case is created and used to propose a new initiative. If your BAs are assigned to a project and these activities have not been adequately performed, help them pull together a small expert team and facilitate them through this important due diligence. And continually ask: “Are we really innovating?”

Portions of this article are adapted with permission from The Enterprise Business Analyst: Developing Creative Solutions to Complex Business Problems by Kathleen B. Hass, PMP. © 2011 by Management Concepts, Inc. All rights reserved. The Enterprise Business Analyst: Developing Creative Solutions to Complex Business Problems

Don’t forget to leave your comments below.

References

Business Analysts Lead from the Center

Written by Angela Wick on . Posted in Articles.

wick Aug13If I asked you to draw a picture of “leadership” what image would appear?

One image you might conjure is an org chart—the typical two dimensional, somewhat triangle-shaped hierarchy. “Leadership” is somewhere near the top.

Many BAs buy into this pyramid leadership scheme. BAs assume they are not leaders because they are near the bottom of the org chart or somewhere off to the side in a special “we-aren’t-sure-where-this-person-fits” box.

But all BAs, regardless of their level of experience, are perfectly positioned to be leaders—not leaders from the top—leaders from the center.

What does it mean to lead from the center?

Most BAs don’t operate at the top of an org chart, they operate as a hub. They sit in the center of multiple resources and pass information back and forth across the spokes.

A BA’s spokes tend to reach many teams and many levels of leadership. BAs often have a unique perspective because they see a 3D cross-section of their organization—they see the “how” and “why” that people looking down from the top of the org chart cannot see.

How do you demonstrate leadership from the center? The spokes are the key! The spokes connect BAs to their resources. They represent shared information and support the relationships between BAs and their stakeholders.

To be an effective hub, a.k.a. an effective leader, BAs need to know how to engage their stakeholders—how to get and keep their attention. 

Do you have strong engagement with your stakeholders? How can you tell if your stakeholders are engaged? How can you improve stakeholder engagement? 

Symptoms of Weak Stakeholder Engagement 

Weak stakeholder engagement stalls your career, minimizes trust, wastes money, and hinders projects and processes. Here are a few symptoms:

  • Strongly conflicting requirements between stakeholders.
  • Stakeholders are silent, roll their eyes, sigh or multi-task during meetings.
  • Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, do not provide resources, etc.
  • Stakeholders show up late for meetings, leave meetings early or skip meetings.
  • Disparate groups do not understand other stakeholders needs and benefits from the project.
  • Progress is slow.
  • Discussions loop in circles.
  • Decisions are difficult to obtain.

Signs of Strong Stakeholder Engagement

Strong stakeholder engagement builds trust and maximizes the value of a project or process. Here are a few signs of strong engagement:

  • Stakeholders have a shared vision and can communicate the vision to their team/s.
  • Stakeholders understand their connection to each other.
  • Stakeholders trust each other and the BA.
  • Stakeholders enthusiastically participate in meetings.
  • Stakeholders make themselves and their resources available to the BA as needed.
  • Questions, discussion and meaningful debates.
  • Proactive, 2-way communication

4 Ways to Improve Stakeholder Engagement and Build BA Leadership Skills

  1. Analyze your stakeholders. Try to determine what motivates your stakeholder. What is their definition of success? Think about the project/process/problem and ask WIIFM (What’s in it for me?) from each stakeholder’s perspective. Truly empathize with each stakeholder to understand what they will gain or want they want to gain.
  2. Observe you stakeholders. Take the time to observe stakeholder behavior and interactions. Observe how they react to you. Do they share information with you openly? Do they seem bored or annoyed? When you talk about specific projects or processes do they seem excited or do they frown and roll their eyes? Also, observe how stakeholders interact with each other. Who comes into meetings together? Who eats lunch together? Which stakeholders seem to annoy each other or question each other?
  3. Boost your facilitation skills. Facilitation skills are critical for leadership and relationship building. Your meetings should be interactive, visual and physical so that all stakeholders contribute in a meaningful way. You should be able to engage SMEs and executives to generate creative ideas to solve complex problems.
  4. Boost your communication skills. Be prepared to discuss your project/process/problem with people from all parts of the org chart. What level of detail does your SME want? Your manger? Your CIO? Do you communicate visually? Can you spontaneously illustrate a process, an idea or an issue on white board during a meeting?

All BAs are Leaders

From the beginner BA to the director of the BACoE, BAs bring people and ideas together. They align organizations and pave the way for value-driven change. They bring a 3rd dimension to the org chart with their unique perspective across organizations and leadership levels. 

Maximize your influence and leadership potential by building strong relationships with your stakeholders. Connect with them. Understand their priorities and motivations. 

Be the hub. Mind your spokes. 

How do you demonstrate leadership in your organization? How do you keep stakeholders engaged?

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as we Know it? Part 5

Written by Steve Blais on . Posted in Articles.

FEATUREJuly30thBeing the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 5:  Wherein the business analysts encounter the Scrum Master, Scott discloses his concerns about business analysts and Verna summons

The organization was quite dynamic.  Meetings were held in the hallways and corridors of the vast headquarters on a more frequent basis than in the meeting rooms. This might be considered by some to be an agile practice since the meetings were held not only standing up, but moving along, which meant that the meeting had to be completed by the time one or more participants got to their destination or their ways parted.

Thus it was that Brian and Ann attended meetings that morning.  Brian ran into Ann as he came out of the elevators after arriving at work, his black Swiss Army backpack slung over one shoulder and a cup of coffee in his hand.  Ann had had an earlier morning meeting with Belice Despacio who was assistant to the CFO. Ann was presenting the information she had amassed on the efficacy of buy versus build decisions on the Backbone project. She considered it her ‘kiss-off’ project for the organization.

“I don’t know about you, but I’ve been avoiding people like the plague these past couple of days trying to get things in order.” Brian greeted her.

“Me, too. You mean you haven’t seen Ken or Scott?”

“Not yet.  But it looks like the waiting is over.”  Ken came down the hall toward them.

“Shall we make a break for it?  If we run in different directions one of us will get away.” Suggested Ann.

“It’s all right, kid.” Said Brian doing his best Bogie imitation. “They’d find us wherever we went. We gotta stay here and face the music.”

“It isn’t even High Noon yet.”

“Well,” said Ken with a vacuous smile. “It’s the Last Brigade, or maybe I should say Lost Brigade?  I see that you have managed to infiltrate your business analysts into the projects anyway.”

“Nope,” said Brian continuing to walk. “There are no business analysts on the Backbone project. There are new developers who used to be business analysts and there are product owners who used to be business analysts.”

“And there are impact analysts working with the product owners,” added Ann.

“Why do I feel this is a trick?  Once a business analyst always a business analyst.”

“First of all,” said Brian, putting his backpack down and facing Ken. “There is no such thing as ‘once a business analyst’. None of us were born business analysts nor did we plan to be business analysts throughout school. We all gravitated or were inserted into the position and the profession. Most of us came from other disciplines like systems analysis or engineering for which we were initially trained. Both Ann and I have done some turns as project manager. Many of us came out of school as engineers or with IT degrees. So it’s not that difficult to move back to one of our former positions. Besides, you have a lot of former Java and C++ programmers working on your dot-net and C# programming projects.  Do we say the same thing about them?  ‘Once a Java programmer always a Java programmer’?”

Ken ignored Brian and walked away.  “Good luck in your new jobs elsewhere in the organization, Allen.  But remember, the New Order of Agile is taking over.  Two more divisions have decided to also go with agile. There won’t be any place to go soon.”

As Ken walked down the hall and Brian shouldered his backpack, Ann mused, “We were avoiding that?  I wonder what he really wanted to see us about.”

“I guess I distracted him.”

“O, well, looks like today is the day.  Here comes Scott, and he looks like he knows why he wants to see us.”

Scott looked troubled.  He came straight at them like a shark after its prey. Brian could hear the Jaws theme playing in the background.

“I’m glad I found you,” breathed Scott. “Can we go someplace to talk,” he said conspiratorially looking over both shoulders. “How about a cup of coffee.”  Brian stared at the cup of coffee in his hand and then at Ann and said, “Sure.  Why not? I’m not on the clock yet anyway.”

After they got settled in a corner table of the cafeteria with their coffees, Scott leaned forward, put his glasses on the table and pushed back his longish black hair. “What do you know about Scrum Masters?”

“It’s a Zen discipline arising from the sport of Rugby in which there is both a ball and not a ball and the less you try to score the more goals you make,” offered Brian.

“My, we are quick this morning, aren’t we, and only on the first cup of coffee,” commented Ann. “We know what a Scrum Master is, Scott. What’s your problem?”

“We drafted our Scrum Masters from our developer teams. We let them volunteer because we didn’t want to impose any management selection of roles on them. These are, after all, self-organizing teams.” He paused for acknowledgment, and receiving none, continued. “Those who said they would like to be Scrum Masters were sent to Certified Scrum Master classes at our expense. So we got a number of CSMs to fill the role for the Scrum teams.  Of course it was difficult. Most of the developers did not want to give up their coding to run interference for the teams. Many also felt that the Scrum Master had to indulge in politics and wanted no part of that. “

“I’m not sure I understand,” interrupted Ann. “What ‘politics’ are they concerned about?”

“One of the primary duties of the Scrum Master is ‘removing impediments to the development team’s progress’ * and another is working with the organization to promote and promulgate Scrum: ‘The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t’ And these things mean that you have to deal with the rest of the organization and that means politics.”

“Isn’t that what you and Ken are doing?” asked Brian.

“Yes. And we take seriously those edicts. And we are ‘leading and coaching the organization in its Scrum adoption’. But that is beside the point. And the point is that we don’t have enough Scrum Masters, and those we do have are not working as well as they should.”

“Didn’t they go to class and get certified?” Asked Ann.

“Yes. I said that. And the certification is two days of class followed by an exam. And it’s a fairly easy exam, too.”

“You passed it?” asked Brian.  Scott didn’t pick up the sarcasm. He continued: “And they tell you what to do, but there is no real training in how to do it. And, for example, in one of my teams a senior developer is somewhat arrogant and is shredding the new, young product owner. She has left the room in tears as a result of his questions.  And all he says is ‘there is no crying in software development’. And I have no experience in dealing with such things, since I am basically a developer.”

“Once a developer, always a developer”, chided Brian, only for Ann’s benefit as Scott was oblivious.

‘As I recall,” Ann tried to bring the conversation back to the point. “The Scrum Master also “Leads and coaches the organization in its Scrum adoption, causes change that increases the productivity of the Scrum Teams, coaches the development team in self-organization and cross-functionality’ *, and so forth. Those are high expectations for a developer, or anyone for that matter. Was your plan that they should be able to do these things with a two day class?”

“No. In agile it’s about learning. Each of the Scrum Masters would learn how to deal with people and learn how to play their Scrum Master roles.  But they are not learning fast, and some don’t seem to be able to learn, or want to learn. And I’ve had three tell me they don’t want the position anymore. And the others on the team see that happen and they don’t want to step in. And I think we are discovering that learning soft skills is not as easy as learning a new programming language or hardware platform.”

“It seems to me as though the Scrum Master job description was written as an inducement for organizations to bring in experienced, qualified consultants. I recall one of the tenets says the Scrum Master ‘coaches the Development Team in organizational environments in which Scrum is not yet full adopted and understood,’ and ‘Helps employees and stakeholders understand and enact Scrum and empirical product development’. So why don’t you just bring on the consultants?” Asked Brian.

“No can do.  I think we oversold the simplicity of the Scrum concept to Carl and Vince. And they won’t pay for consultants. They say the self-organizing teams should be able to handle it themselves. And they were willing to allow for a ramp-up time and the classes. And they expect that since the developers are able to talk directly to the business now that they should be able to do the Scrum Master roles as well. So, no consultants.”

“Yes,” agreed Brian. “It would seem contradictory to the concept of simplicity to have to bring in a high paid consultant to get things started. But what about the project managers?”

“Ken didn’t want any of them around. He wasn’t sure they could successfully drop their authority around the team. And even if they were able to stop managing and start coaching, the teams would still see them as project managers and that would make them ineffective. And, besides, Carl grabbed all the good project managers and assigned them to other projects in the organization and let the others go.”

Ann sat back and sipped her coffee. “Hmm.  OK. Sounds like a problem. What do you want us to do about it?  Offer suggestions?”

“Actually, I’m looking for advice, and maybe a little help.  One of the aspects of business analysts I have admired is their facilitation skills: they seem to be able to enable discussions and get people involved. And, like you two guys, you seem to be able to get things done when you’re on a project, especially outside the project boundaries, working with other projects and business areas.” Brian and Ann exchanged glances, both with raised eyebrows “And I am thinking that we might be able to co-opt some business analysts into being Scrum Masters. For example, Shelly. Shelly is able to make a meeting work well. I go into a meeting and have no idea why I am there. And even when there is an agenda, all it does is list the attendees and none of us know why we are there. But a meeting with Shelly always goes well. And when any of us walk out of a meeting that she attends we know exactly why we were in the meeting and always feel that we spent our time well. And, she, like, asks questions and gets the attendees to come to conclusions, even when the meeting isn’t hers.  And she seems always to be able to resolve conflict among the attendees if there is any, even among developers, and sometimes even before it starts.  And I’ve seen you two do this as well.”

“Well,” replied Ann.  “That could be arranged. We can send a few of our remaining available business analysts to Scrum Master classes and they can be Scrum Masters for your teams.”  Ann hid her delight at having this solution drop into her lap. 

Brian on the other hand had another question. “Scott, you seemed to be totally against business analysts.  And now you are singing our praises. What gives?”

“I am not singing the praises of all business analysts.  I’ve been in meetings with the users and your typical business analyst. And I’m there in the meeting for technical support and half the time I just sit there and daydream or wish I could open my laptop and do some coding. And the business analyst just sits there and takes notes. And whoever it is says that they are there to get the requirements and then records what the users tell them. Sometimes I have to ask questions when the users ask for something outrageous. And the BA takes everything down, you know?  And it all ends up in the requirements document. And the BA tells us, ‘it’s what the customer wants.’ I mean, we could do that, and we’d spend more time asking questions  And then later we find out that it’s not quite what the customer wanted because the user forgot to mention something or didn’t state it clearly. And the BA complains about the customer changing their mind or never knowing what they want.  And, I mean, we could do it, you know?  And, even if we did the same thing, which I doubt, at least we’d be getting the straight scoop, and getting it earlier. And the business analyst just does not add value to the exchange.  Present company excepted, of course.”

“Of course.” Said both Brian and Ann together.

So it was agreed. Shelly and Juan and a couple of others would start work as Scrum Masters applying their business analyst facilitation skills to ‘facilitating Scrum events as requested or needed’ *. They could use their influence, negotiation, mediation, and conflict resolution skills to support the teams and the projects as Scrum Masters. Scott and Ann would schedule them into Certified Scrum Master classes as soon as possible.  Scott agreed that both Brian and Ann would make excellent Scrum Masters, just as they might make excellent Product Owners, but they had been business analysts too long and the imprimatur of their role and their reputations in the organization would act against them in being successful as servant leaders, just as the former project managers would have run into difficulty. “And besides, there’s Ken standing in the way”, concluded Scott.

“Well, that’s it,” breathed Ann as they left the cafeteria. “Looks like we did it. That’s everyone accounted for. ”

“Except us,” said Brian hoisting his backpack on his shoulder.  “However, that is all the meetings, right?  Everyone who was looking for us found us.”

“Not everyone.” Ann was afraid to say the name. Just then Sandra, Verna’s Personal Assistant, rounded the corner and headed straight for them with Ken at her elbow. Ken looked like he remembered why he had been looking for them.

Was Ken in Cahoots with Verna?  Had he swung Verna over to the New Order of Agile Development?  Would this be the end of Rico?  And do we have to hear Scott say ‘and’ one more time? And where is Cahoots, anyway?  Tune in for the season finale where we find out what happens to the last two stalwart business analysts in the organization and finally meet Verna although like the Sopranos, the screen may go blank when we do.

* Quoted from Schwaber & Sutherland, “The Scrum Guide, the Definitive Guide to Scrum: the Rules of the Game”, published by Scrum.org, July 2011

Don’t forget to leave your comments below.