Skip to main content

Tag: Facilitation

Less Talk, More Walk

Analysts are thinking people and don’t always realize the power of the physical body to implement best BA behaviors. We sometimes believe that our thinking can walk us to requirements success; I propose a different, compatible approach – you can walk your way into better thinking.

Let your model do the talking:

Have you ever been a part of the meeting that never ends, the discussion that goes in circles, the misunderstanding that becomes the decision, and the ego clash that kills collaboration?

As a young BA I often tried to hold my own in these discussions, and always felt that I could see the way to resolution, if only they would listen to ME. In trying to talk others into the BA walk, the BA just becomes another loud voice in a chaotic room.

Nowadays when I hear a complex, ongoing discussion, I keep my mouth shut (OK, I try) and work hard outside the meetings to MODEL the issues. Just writing them down can help, because it simplifies REMEMBERING everything.

Even better is to characterize the discussion in BA terms (goals, objectives, business needs, capability gaps, strategic solutions approaches, and scope and business case. Showing these things in pictures AND words means that visual and textual cognition is covered.

What about “hands on” cognition?

Do walk-throughs where the group does the work:

No model helps if no one “reads” it. One of the funniest things you will ever see is a confused group suddenly presented with a “pretty” diagram. “Oh, I understand that better” they will say, often oohing and aahing UNTIL YOU ASK A QUESTION about the concepts in the diagram. If you watch closely you will see them look back at the diagram for answers, not having really looked at it closely before, and not having read any of the words on the picture.

When working in any group, walk them through the model, step by step, letting THEM explain it. This process will far exceed the ability of YOUR thinking to move people, will give them REAL involvement, and will position them to explain the concepts to others.

What about bad ideas wasting time – doesn’t the BA have to stop this?

Be the “yes” woman:

Anytime a facilitator (as a BA, you see yourself as a facilitator instead of a decidadator, yes?) tries to stifle an idea before it is worked out by the group, the idea can become “locked” in the mind of the proposers.

A classic example is Roe v. Wade – most states were (slowly) moving towards freedom of choice (no letters or comments – this is NOT advocacy – prove you can read by finishing the paragraph) for women, recognizing that childbirth was a serious commitment and physical risk for women. When the Supreme Court stepped in and interrupted the state-by-state debate, the debate became locked in place, to this day.

Compare Roe v. Wade with the recent Supreme Court decision to let the state courts and legislatures keep working on the gay marriage issue. If we get to the point where 50 states have all decided that equal opportunity actually matters, THEN IT WILL MATTER, and the court will have let the country decide.

Whatever your political opinions, if you say “yes” to stakeholder ideas, and THEN MODEL, the strength or weakness of the ideas becomes visible and easier to understand. The group is then able to make good decisions OR shoot themselves in the foot ON PURPOSE, with the best information available, since no ideas are discouraged.

Stop telling everyone about your knowing – seek the facts:

We all know what’s going on, until we look. Anytime there is a disagreement about facts, it is a sign the facts aren’t know. Stop promoting your opinion, and recruit help in finding the facts.

Facts are harder work than opinion. You can add value to the group by being willing to admit what is known AND what is NOT known. Much of the info might even be in the current system – get IT involved.

Drive requirements from process, not data (nor interface, which is slow listing of data):

Ever seen the system full of data that no one can use? Some reporting systems are like that – you can choose ANYTHING to include in your report, with NO CLUE as to WHY you would ever care.

Data is STATIC – a list of data has NO BEHAVIOR – not even if listed on a GUI mockup. The behavior is process, and the only processes that count are the ones that get work done, NOT the ones that “draw screens”.

When work processes drive requirements, the requirements tend to lead to accomplishing the work of the organization.

If this is wanted, it is a big win. What if it isn’t wanted?

Don’t confuse your attitude with your stakeholder’s attitude:

As a change agent, BAs love change. Even stakeholders who want change don’t love change (mostly). Remember that the work you enjoy is painful for your stakeholders, and join them in the pain, even as you offer slivers of hope.

Explore with your stakeholders instead of talking at them, and you will BE the BA.

Be Patient:

One reason that you are a BA is because you are good at understanding and organizing ideas. Don’t be upset or impatient that it takes others longer – at best you become the “superhero” that delivers things faster than a group can, so the group can RIP ON THE WORK after the fact instead of before (expensive). At worst you will be so frustrated that you will not be welcome at all.

The walk to perform is to continually return to the highest-level descriptions, over and over, even as you drill into the next levels down. Repetition of the “main message” is not a waste of time but actually creates bonding at the common level of understanding (a good complement to this blog is “The Four Obsessions of an Extraordinary Executive” by John Lencioni).

When the top-level descriptions are better understood, the next level discussions are much more productive.

Take leadership (and other) training and give leadership (and other) training.

A BA who has nothing to learn also has nothing to teach. Stop it now. If you get a chance to teach, take it, it will open your eyes about what you REALLY know (not much) and what you can offer others (a lot).

Thanks for being a reader – the world is your oyster!

Don’t forget to leave your comments below.

Continuous Quality Management of Software Applications

mughdaMay19Today’s software applications are fundamentally different in nature as compared to what we have seen them till very recently. It is primarily in terms of how they are being developed, their complex architecture, variety of usage by end users, varying needs of users from the applications and its ability to sustain to big data needs. So it is of paramount importance that the applications are envisaged rightly for these needs and are ensured that it is getting rightly built throughout the life cycle phases of the same i.e. conceptualize to deployment. Continuous Application Quality Management (CAQM) is simple approach that will help all the software application teams to join hands and ensure the right application with right quality is delivered thought the life cycles. The testing team OR quality assurance team can play extremely important role in the same by providing right orchestration and collaboration of various independent teams of software development like BA, designer, architects, user experience team, QA, developers and many others. This article reveals the CAQM approach with some relevant tips and tricks of how to go about it.

CAQM is extremely powerful approach to ensure critical to quality requirements are gathered from right stakeholders and they are implemented well in an application.

What is “continuous application quality management i.e. CAQM”?

Every individual software system/application possesses unique set of quality requirements which are critical to that application. These quality requirements can be from functional perspective OR non-functional aspect as well. Most of the software projects pay attention to these quality requirements only at the time of system testing or performance testing. That is a reason that many a times software system which is functionally excellent fails to cater to the need of users as no one paid enough attention to these “critical to quality requirements” when the system was getting built. Even if there is adequate focus on to test these requirements during testing phase, it might be too late and too costly to fix the issues as cost of fixing a defect rises exponentially with each LC stage.

CAQM suggest that there should be focus on “critical to quality requirements” right from the beginning by various stakeholders involved in the application development. It also ensures that these parameters are monitored, measured through-out the life cycle of an application and corrective OR preventive actions are implemented at right time to get the application health on track.

Let me explain this concept with a simple day to day example. With this example, it would be very easy for you to relate the scenario with software application as well. Let’s say I have a mission in hand that in next 6 months I need to clear certain medical test of military entrance exams which has very stringent requirements on my health parameters. So first thing I will do is understand the “critical to quality” requirements of this entrance test i.e. the requirements in terms of health parameters like height, weight, BP, blood sugar levels, thyroid, B12 levels, vision etc. which will help me clear the test if they are in the best possible range. So I will identify the key parameters and its values that I should be attaining after 6 months. I visit my family doctor and discuss this. As he knows my medical history, he suggests 2 more parameters to track as they impact the thyroid levels. Then I conduct all the medical tests and measure the parameters. I create a plan like below in consultation with my doctor so as to reach to the target value of parameters. I also decide the frequency in which I need to measure the parameters on ongoing basis till the entrance exam date. So I create health assessment dashboard for all the parameters that are critical for me to be exactly same or better as that of target values like the one below. I have given it for couple of parameters and couple of intervals. But I need to maintain it for all parameters throughout the journey.

mugdha Table1 May20

I can also track all my parameters on a spider chart graph as shown in the diagram. It helps to get a quick understanding of where exactly I stand today and where do I need to reach.

mugdha May20

So as I have started right with identifying right health parameters, their expected target values, by consulting SMEs to understand what more should be focused. Then I am taking a stock of where am I on start of the journey so that I know how much ground is to be covered. I take necessary efforts and actions and measure the parameters on regular small intervals and take necessary course correction so as to ensure that I will achieve my targets. So with this approach likelihood of me clearing my military entrance test is more as compared to what I would have normally done. Normally one may not have gone with so much of a methodic approach and ensure regular frequency check -ups and possibly would have just checked the values before entrance tests. In such case, chances of me not clearing the tests are more as I have simply left it to my luck factor.

So essential take away from this approach is

  • Gather right requirements/parameters that are critical for our mission
  • Reach out to right set of stakeholders to understand these requirements from their perspective
  • Set target values to these parameters so that the final outcome will be the best
  • Periodically measure the values/health of the project
  • Consult subject matter experts to take corrective/preventive actions at that stage only instead of making it very late in the cycle
  • Implement action items and check its effectiveness in next interval results. If not effective, re-plan the same.

A very similar analogy can be drawn for software quality as well. Traditionally, for better software quality we just rely on system testing and performance testing just towards the end of life cycle and if something drastically wrong is found, it is almost impossible to go back and correct the same. We will still correct something and release application to production. But people may not use it because it is not serving the “critical to quality” needs of an end user.
Hence I will recommend the CAQM approach to address this issue and ensure right software is built and delivered.

CAQM is based on ISO 9126 concepts which define “Critical to Quality” requirements of any software. ISO 9126 defines various software characteristics like functionality, reliability etc. For each of the characteristics there are sub-characteristics associated like maturity and fault tolerance are sub-characteristics of reliability. For each of the sub-characteristics there are multiple metrics that can help evaluate that particular aspect of the same. One such sample metric is given below

  • TurnAround time is a metric defined under efficiency characteristics and time behavior sub-characteristic.
  • Definition: – What is the wait time the user experiences after issuing an instruction to start a group of related tasks and.
  • Formula: – T = Time at which user finished getting output results – time at which user finished placing request

A quick summary of ISO 9126 characteristics and sub-characteristics is given below for reference.

mugdha Table2 May20

But in case if your applications CTQ requirements are something other than the one mentioned in ISO 9126 model, you can include them for your application and track them.

How to implement CAQM in software development?

The below section depicts how CAQM can be implemented in a software project.

mugdha Table3 May20

Key success criteria

The key success criteria for implementing this approach is –

  • Collaborative approach – Typically the activities in CAQM demand that they need to be done in a collaborative fashion having various teams involved in as mentioned above. Every team needs to have a single vision i.e. best quality of application in optimal time to market and cost. They should be extremely open and flexible to accept the issues and problems that have occurred due to their contribution in the SDLC and should be ready to rework on it even if indicated by some other team.
  • Customer willing ness to invest extra– As these are some additional activities that are suggested on and above the basic SDLC phases activities, there should be willingness by client to spend extra money on the effort and time needed to perform these activities. The expected ROI on these investments is huge as compared to the investment made.

  • No cuts on any of the standard technical reviews of process artifacts at various life cycle stages – The approach suggested in CAQM is over and above the traditional life cycle appraisal and prevention activities. This does not recommend any cuts in the reviews/testing etc. which is part of the life cycle phases.

In absence of any one of the points below, the overall approach for CAQM will not be effective.

Conclusion

CAQM is an approach using which there can be constant focus on key health parameters of the application. Application health is monitored in multiple logical intervals and corrective/preventive actions can be taken up at right point in time.

This needs a collaborative approach for successful implementation. Though primarily it is based on ISO 9126 model, we can have any other critical to quality attributes which are specific to the application or client context. CAQM can be achieved in simple spreadsheet based tools that we can create to capture, track and create trend analysis of the data. If done in a right way and right spirit, it helps achieving great results in terms of application quality, productivity, cost and time to market.

References
1. ISO 9126 model

7 Steps to Kick-Start Your Strategic Planning Process

lannon Jan28Strategic planning is an exercise in gathering and documenting information about the past, present and future of your business. Strategic planning helps determine where you want to go over the next few years, how you are going to get there and how to recognize when you’ve arrived.

One of the more common strategic planning approaches is Basic Strategic Planning (BSP). BSP uses a triangle approach and seeks to align strategic agenda items with the tactical reality of the organization.

Starting from the top, BSP includes the following steps:

  1. Identify your mission statement. It is amazing how many organizations don’t take the time to develop this statement. A mission statement is foundational to all strategic planning work. An effective mission statement describes what the company does, provides insight into client value and captures the essence of your company.
  2. Create a vision of the future. A vision statement should look to the future. After all, you can’t get to where you want to go unless you know where you want to go. Think ahead to three to five years from now and write your story. What is it that your organization has achieved? Tighten that story into a clear crisp sentence and share it.
  3. Develop core values and guiding principles. Core values and guiding principles are foundational to your entire organization. Guiding principles are a set of accepted guidelines formed by the business that capture how your people act, work, make decisions, set priorities and conduct themselves. It is imperative to set and communicate core values and principles or else they will set themselves over time through employee habits.
  4. Create long-term goals and smart objectives. Goals are general statements outlining what you want to achieve to meet your mission and vision and address any issues you are facing. For each and every goal it is important to identify strategies to achieve them. Objectives should be SMART; that means specific, measurable, attainable, realistic, and time bound. It is important that you make a distinction between long-term goals and smart objectives for those goals.
  5. Establish an action roadmap with timelines. An action roadmap is a visual representation of your strategic planning items. It includes high-level agenda items, initiatives, champions and key elements. It includes the key areas that your organization will focus on in order to achieve its goals and objectives.
  6. Build a communication plan. Communication plans should not be complicated and should be shared within your organization. It is important that time is spent determining the best approach for getting people informed as to what is planned and ensuring that they know impacts of not achieving the objectives. Consider printed plans, maps, high-level visuals, town hall sessions, etc. It is all about communication. Be visual, be creative.
  7. Establish an implementation and monitoring plan. This is important to be successful. Organizations and teams fail because they don’t assign a top-notch resource to put together an implementation plan. Consider using a highly-skilled program manager or director to translate the strategic plan into tactical reality. Ensure that the rules of engagement are established and build a strong monitoring process that engages people in open dialogue centred around the actions that must be taken to be successful.

Strategic planning is an important part of every organization’s success. There are key elements that must go into strategic planning; if you do not have all the elements to start with, then you must start with the basic strategic planning process (BSP). Everything that you do as an organization will come from your strategic plan. This includes enhanced sales, improved business processes, inventory controls, or market advancement. The list of options is huge. We don’t plan to fail, we just fail to plan.

Don’t forget to leave your comments below.

Watch Out For Think-Holes

ferrer Oct1Answer to last month’s question: Change the “head of the fish” to balance benefit as well as cost. Example: “Why does internal service impact profitability?

Most of us have a pretty high opinion of our own thinking*. We are biased, but don’t see it that way. This makes complete sense. WE are ALIVE**. We are the latest survivors of billions of years of disaster, uncertainty, death and taxes***. We are the WINNERS! We must be doing something right. Right?

Right! As survivors, we have tremendous adaptations. Adaptations that got our ancestors away from lions and tigers and bears oh my!**** These adaptations are less useful than they used to be – see if you agree.

Fast thinking vs. slow thinking:

We have almost instantaneous abilities to recognize friends, spot strangers, see (and dodge) dangers, identify objects and their uses, feel body language, judge tone of voice and much, much more. The Nobel Prize winning economist Daniel Kahneman describes these abilities as System 1 thinking. 

Here is an example of System 1 thinking:

What is this picture?

ferrer Oct01

Here is an example of System 2 thinking:

If the average expenditure by a middle class consumer ($50K-$115K/year) at a SaveMoreBySpendingMore™ store is $18.25, and middle class consumers represent 94% of SMBSM customers in 2012, and our total customer visits per year in 2012 were 78,543,228, how much revenue came from middle class customers? *****

If the above seems excessive as an example, try this example of “slow” thinking (for most of us):

How much is (40 x 52) – 80?

Even though we “know” we can calculate the above fairly quickly, and we have a sense that the answer is not 17, or 15,000,000, we (I mean I, as my brilliant readers are not so limited) cannot calculate it as quickly as we can recognize a $100 bill.

The “thinkhole” here is the temptation to go with “first intuition” when it is not always the best approach. This can be appropriate (“Duck – here comes a rock!”), it can also be less (way less) than useful (“Let’s build a really cool space airplane just like the astronauts/pilots always wanted. That will be cheap, reliable and fun, just like flying jets.”). One way to characterize a BA is as a person who is willing to do the complex thinking for a larger group.

Anytime a complex decision is offered to a meeting, there is a real danger of the decision being made “quickly”, and almost surely “wrongly”. In such situations we must be ready with clear options and open facilitation to keep discussion (and follow up analysis) alive.

Some of you may recall the training video “Going to Abilene”, where a bunch of IBM trainees decide to go to Abilene after one of them tosses it out as an idea. They have a miserable, hot, dusty day and only get 1 hour in Abilene for their trouble. When they get back to training camp, they argue and place blame until they realize what happened. They went to Abilene because no one wanted to “contradict” their colleague or “put down” the idea. The colleague who suggested Abilene was quite clear. “Don’t blame me! It was just a thought. I didn’t think it was the greatest thought in the world, but when everyone went along I didn’t want to stand out!”

Solution: Do the slow thinking. Don’t force decisions. Simplify for the audience. 

Let’s look at some other thinkholes:

Aversion to Loss will prevent Desirable Strategies for Gain

Would you rather have a 100% chance at $1000, or a 90% chance at $1200 with a 10% chance of losing $50? Why? What if you get to play 10 times in a row? It is difficult to overcome fear of loss. The loss can be intangible – reputation, comfort, preference, etc. These fears can actually prevent our work as change agents. 

Solution: Do the “math” so all can see the tradeoffs, then duck . 

Preferring Apple Pie to Cherry, Cherry to Peach, Peach to Apple

Most individual pie eaters (not all) are consistent (their preferences are transitive, and Apple will beat Key Lime via Cherry), but most groups are not. Politics can illuminate this. In 2000, many democrats preferred Ralph Nader to John Kerry, and John Kerry to George Bush. By voting for Ralph Nader (their first choice), they got George Bush (their last choice). 

Those on the left that preferred Nader were NOT happy with Bush, and yet could not make the rational choice – to vote for Kerry instead. Groups can be “dumb”, even when individuals are smart. 

Solution: Show choices AND consequences, when it matters. 

Overestimation of rare effects

This shows up most often when use case “alternatives” spin out of control. We may be discussing retail transactions, and everyone agrees we should take cash, credit, debit, bitCoin, PayPal and checks. The debate breaks down when we start discussing barter, which is far more complicated (and rare, in commerce). There is no denying that barter happens, AND it may be a waste of time holding up decisions and consensus and progress to handle barter. 

Solution: Add it to the alternative paths, and schedule it for LATER.

Misunderstanding probability

This one I want to make money on. If I explain, I won’t make any money. I offer the following bet, without explanation, to anyone who wishes to take it (the law firm of Finch and Associates, LLC will hold the money and administer the bet, unless they don’t want to ):

I am willing to bet my $1 against your $1 that: If we pick 50 people at random, then at least two of them will share the same birthday (same month and day, though possibly a different year).

If that is not attractive we can make it my $5 against your $1 as long as we pick 70 people at random.

Any takers? Why or why not? I have lots more, open your wallets.

Solution: Which humble reader shall provide?

Thanks for reading, leave any thoughts, and have fun!

Don’t forget to leave your comments below.

* Not my humble readers, who know that they are WAY too smart to fall for this.

** Life is clearly biased in favoring existence over non-existence.

*** Us, and Naegleria fowleri, so don’t get too excited.

**** And humans. Next time you are nervous in public, now you know why.

***** Answer next month. No more scroo’n ‘round, on with Thinkholes!

It’s the End of the Business Analysis World as We Know it? Part 6

Being 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 6: Wherein Verna addresses the business analysts and their final fate is known while Brian searches for the right theme song.

Brian saw Ken and Sandra walking slowly toward them from the end of the corridor with measured pace. He and Ann were walking toward them with the same measured pace. The corridor had emptied out. Brian heard the whistling trill from the theme song to “The Good, The Bad, and the Ugly” echo in his head as they approached each other. He immediately thought that he was at a disadvantage since he still had his backpack slung over his shoulder. “I got my updated resume in my backpack, just in case,” Brian whispered to Ann as they walked. She nodded.

Then Ken and Sandra turned to their left down an intersecting hallway. Brian and Ann turned left seconds later to follow them. Still no words were spoken. It was the way of Verna. The whistling in Brian’s head was now replaced by the bubbly, somewhat inane tune, “We’re off to see the Wizard…” and he looked at the floor to see if there were yellow tiles. 

They turned left again and then right along passageways and halls that seemed to become narrower as they proceeded. Brian realized that he and Ann were in a sector of the Organization’s Headquarters that they had never been in before and didn’t even know existed. The theme song to :”The Twilight Zone” snaked into Brian’s brain replacing the jovial image of Oz with the dour visage of Rod Serling.

Finally they came to The Door. Sandra pressed a button and passed her badge over a green light and The Door opened. Inside was a large well lit antechamber with several desks with people busy doing things people do at desks, a couple of conversation areas and three doors leading to other offices. Brian wondered if he were going to get to pick which door Verna was behind. 

Sandra led them to the left hand door and opened it after knocking. When the door opened everyone behind the desks stood up at attention. Ann, Ken and Brian entered the room. Sandra did not. She closed the door behind them. This was Verna’s office. 

“Welcome, I’ve been expecting you,” came a disembodied voice that was strong and authoritative but seemed to carry with it a smile of understanding and empathy. The three looked around the large office, darkened by heavy drapes over the windows, and could not immediately see the source of the voice.

“Please, have a seat.” There were three chairs in front of the executive desk in the center of the room and an empty black executive swivel chair behind it. Then they saw Verna standing at the corner of the desk. 

When Brian saw Verna he realized why she was rarely seen around the organization. She was 4’9” in height and was barely visible behind the large desk. He imagined her sneaking unseen around the corridors of the organization, and the theme song to The Pink Panther crept into his head. Verna pulled herself into the executive chair and they could see her clearly. She had short page-boy length hair and was of indeterminate age although her face spoke of volumes of experience in the corporate political wars.

“First of all,” Verna said. “I want to let you know that I am completely in favor of the entire concept of agile: agile software development, agile management, agile organization. I have been in favor of it long before it was agile. Back in the day being agile as you describe it now was just business as usual. We in the corporate world have lost touch with our ability to respond, to be flexible, to take chances and risks, and to make things up as we go. Management has a few set backs or failures along the way and suddenly we are all worried about risk management and making sure that there is a paper trail we call documentation to absolve us of blame. We all had the agile spirit at least once, when we were start ups – as organizations or when we first started up in the business field. But as things went on we lost it. So, now if we have to call it agile and take a slap in the back of the head or a glass of cold water in the face to wake us up, then I’m all for it. And that includes all of the precepts, such as removing the business analyst from between the business person with the problem and the development team with the solution.”

This pronouncement deflated Brian and Ann. Brian let his backpack slide to the floor next to his chair. 

“You don’t need to pull your resume out of the backpack as yet, Mr. Allen,” said Verna with a smile. 

Brian looked up and over at Ann. His face said “how did she know that?” Her faced responded with “Lucky guess, maybe?” He noticed out of the corner of his eye that Ken was smiling in apparent victory.

“I am talking about removing requirements as we know them: This absurd process of creating long documents followed by lengthy confirmation processes and approvals by executives who don’t even read the bloody thing, and then making changes which also require confirmation and approval are absurd. We need to be more flexible, fluid and responsive, and requirements documents do not get us there. There is too much time spent in arguing about how a requirement is written and the meaning of the words in the document than in defining what is necessary to be done to solve the problem.”

Now Brian could see Ken’s grin growing wider. Ann was looking down and nodding. Brian found that there was nothing that Verna was saying that he could disagree with. He had felt for a long time that defining requirements was a small and sometimes trivial part of his job, but he had always assumed it was necessary. After all, what is a business analyst without requirements? The Business Analysis Body of Knowledge seemed to be all about requirements as the Project Management Body of Knowledge was all about structure and documentation. And he knew; he had his PMP although he wasn’t sure anymore why he had it. 

“But,” said Verna, interrupting Brian’s reverie, “That does not mean at all that we are considering eliminating the business analyst. The business analyst is vital to the success of this organization, more so than the technologists who develop the software solutions.” She aimed her last comment at Ken whose smile froze on his face and then fell into his lap. Ann looked up at Verna with a question on her face.

“Let me highlight the job you two have been doing for the organization. It hasn’t gone unnoticed,” Vern continued. “You have helped Marketing, especially Dmitri, many times over the past by ensuring that their initiatives mesh well with the rest of the organization and are aligned with our overall strategic goals. Marketing has a reputation for focusing only on what is necessary to achieve their goals without regard for the rest of the organization. And that is good. Without them we don’t go anywhere. But we need someone to provide an overall business view to what they are doing, and you have been doing that. 

“The information you assembled and the analysis you provided on our strategic build or buy situation is going to save us a lot of money and contribute significantly to the success of Backbone. There will be less coding that has to be done…sorry, Ken…which means that parts of the overall system will come up sooner than expected giving us significant competitive advantage and return. And we thank you for those efforts.”

“We were just doing our job,” muttered Ann, still bewildered at Verna’s comments.

“And that, my dear, is my point, you are doing your job,” responded Verna. “I also personally like the way you keep asking questions, even in the face of rampant enthusiasm, especially on the part of Marketing. You also challenge the technologists’ assumptions and the ‘no problem syndrome’. You apply upfront critical thinking which has saved this organization thousands in miscommunication and rework costs. I know anything “upfront’ is considered suspect by the agile authorities, but I tend to be old school and believe that any process that makes things work more efficiently is worthwhile no matter where it occurs or what you call it. And I particularly like the way you do it without a lot of paperwork, overhead or ceremony.

“You facilitate meetings and get problems addressed and solved. You effectively deal with conflicts, especially between IT and the business units and between the business units themselves. Unfortunately many of those conflicts are about how requirements are phrased, but we may have eliminated that source of conflict with this agile product development approach. You seem to be able to get the best out of people when you are around, helping them achieve their goals. You were instrumental in providing the information and argument that convinced Carl that his precious system needed to be replaced and not maintained. 

“You have taken the time to keep up to date not only on technology so you can understand the technologists, but also the business side so you understand business jargon. And I’ve noticed that you don’t spend time just translating one set of jargon to the other, but facilitate the interactions between the suits and the nerds so that each will become more familiar with the other’s domain. Very good. Of course, it has led to the current demand by Ken and his cronies that you be removed from the ‘middle’. So you unwittingly were part of your own demise in that regard. 

“I also noticed that people around the organization seem to call on you when they have problems and you are able to help them define what their real problems are and help them come up with solutions, even when those solutions do not involve software development or even IT at all.”

“But they work for IT,” Ken pointed out. “They should be defining IT solutions.”

Verna affixed a withering stare at Ken. He seemed to shrink in his chair until he seemed to be shorter than Verna. “They do not work for IT, sir. They work for the organization.” 

Brian and Ann shared glances. They never assumed anything else. 

“The bottom line is that business analysis is here to stay. What you do is the real backbone of the organization. You provide independent and objective information to the decision makers, define and solve business problems, improve business processes and make a multitude of other contributions..”

Ken appeared to have one more protest up his sleeve. “I was given the direction by Vince and others that we all have to be agile. The entire organization is going agile.”

“Yes, I believe that is true, and as I clearly stated, I am in agreement with everyone going agile. But these business analysts, for all intents and purposes, sir, are already agile. They are responsive, flexible, focus on the problems of the entire organization, collaborate at all times and facilitate collaboration wherever possible, and work to get the business customers with problems and the IT or other teams with solutions together to add value to the organization. How much more agile can you get, sir? I believe if you go back and look at your recent history, you will see that business analyst laid the groundwork for successful agile organizations. 

“I would say, Mr. Allen and Ms. Brady, that you are certainly agile as far as the organization is concerned, at least as agile as the developers working with Scrum. So, since IT has decreed that they don’t seem to have any use for you, replacing your requirements definition duties with the agile process, then what I want is that you work directly for me. You will remain business analysts. And your scope will be the entire organization. I envision an entire team of business analysts moving the organization strategically, tactically, and competitively forward”

There was a long pause as Brian and Ann let the directive sink in. 

“I have spoken,” commanded Verna, ending the meeting. \

Outside in the hallway, Ken nodded to them and bid them well and said that it was clear that he would be working with them on upcoming projects, including Backbone. He did not seem to bear any ill will. In fact, Brian almost sensed that Ken now welcomed their participation in the agile community as business analysts. But then, that remained to be seen.

As they stood in the lobby of Verna’s offices, Brian looked at Ann. “Do you know the way back?”

Ann replied, “I left the bread crumbs.”

“Looks like everyone is safe.”

“Yes, we did it. And we got to meet with Verna.” 

“Hey, did you notice? No strange silences and eerie feelings when you said her name.”

“Yes. I wonder if it’s just because we met her or because we now know her real stature. She’s small, you know?”

A disembodied voice came out of hidden speakers someplace near where they were standing in the lobby of Verna’s area. “I heard that, Ms. Brady.” It was unmistakably Verna. They looked at each other and scurried out of the area and through The Door. 
“How did…?” whispered Brian. Ann shrugged.

“Well for one thing,” said Brian, still keeping his voice soft as they moved down the hall. “This is going to be really challenging and very interesting.”

“Yes. And we love it that way. We are, after all, business analysts.”

Don’t forget to leave your comments below.