Waterfall image

Waterfall Is the Wrong Enemy

I was reading The Inmates are Running the Asylum by Alan Cooper when I came across this passage in chapter 8:

“Some of their previous products were successes and some were failure, but the process they used to create them was the same. From this they deduced that the success or failure of a software product is due only to chance; software success is simply a crapshoot. The problem is reminiscent of physicians in the nineteenth century, before it was discovered that the anopheles mosquito carried malaria, who were unsure of the disease’s source. It was thought to float on the evening air, striking randomly, and one’s only defense against the often-deadly fever was luck. After the cause-and-effect relationship was discovered, the disease was quickly brought to heel.”

And reading this, I thought “That’s us! We have looked at our randomness and declared Waterfall to be the culprit. Agile is the cure!”

Only, I’m not sure we yet understand the problem. I have little faith agile alone can save us. I fear we have become students of nineteenth century doctors.

The Manifesto signers were right, but all too often we have looked beyond the principals they espoused and cried for process and tools. And in our search for what’s easy to digest, we have missed what is most important.

Waterfall image

The problem with waterfall was not too much documentation, but documentation over conversation and understanding. The problem was not in developing plans, but in blindly following plans that were developed with too little information. The problem is we like simple tools and easy-to-use processes, and we are following them without understanding when they work best.

It is difficult to look at ourselves, our skills and shortcomings, to honestly evaluate a team, and then to cast the same critical eye over our technical environment, our business partners, our corporate culture, a nascent understanding of the marketplace, and more to develop the right version of a process. It is easy to say “I will follow Scrum (or any version of Agile)” and fight for meeting the version you were taught in class. And because you still have to fight for your version against the reticent and resistant, it feels like a good fight.

But it is the wrong fight.

Let us commit to reviewing both the manifesto and the principles. Then let us commit to working on the foundations, rather than just a new process. Because if you’re only changing the process without understanding what you are changing and why, I’d rather you change the lighting and humidity.

Are You “Just One in a Crowd?”

just one of the crowdI was talking a friend about their employer,  Great Software Company (GSC) [names have been changed -ed]. GSC had a reputation for being a powerhouse in the software development field. They hired the best and set them at client problems with flair and gusto. My friend was lamenting they’ve lost their mojo, now they are “just one [company] in a crowd.” GSC is waiting for clients to recognize how great they are. Clients are looking for someone new to solve the problem of the day. And existing clients are often going someplace new rather than turning to their (formerly?) trusted parter, GSC.

Reputations are great tools for a company. A strong reputation, based on effective delivery of innovative solutions is great for a company. It’s also great when you own the problem and you are looking for solution provider. You can check your networks for a company that has the chops you need.

Unfortunately, reputations for most firms in software and high-tech are short lived. The fields are changing at such a rapid pace, very few reputations become “household names.” Whether large, mid-tier, or a boutique firm, it is a rarity to establish a reputations both wide- and deep-enough to impact the client if you are not currently solving the biggest problem they face.

I propose two causes for this. First, the rate of change. You may have been great in programming 4GL languages a decade ago, but who cares today? Website design has moved dramatically in the last three years. Are you ready to move to NoSQL databases? Is your team running with Continuous Integration? Have you heard about the teams looking for post-Agile coaching yet? If you do not have the latest skills, or at least paying attention to the related trends, your clients have every reason to look for another firm for solutions.

My second proposed cause is the ever-shifting audience. Not only is the technology changing quickly, but the people in and around technology are fast moving as well. Heck, it’s not just the people in technology, but the people you talk to every day. You cannot count on your client remembering how you solved their Tough Problem when they have had leadership changes, multiple staff shifts and promotions, or a department reorganization. As a company, you have to find a way to display your talent, your skills, your ability to solve the tough problems.


Now, reread the section above and imagine I am talking about you and your role, not GSC and software firms.

Are you “just one in a crowd?” Have you done anything to build a reputation for thorough analysis with the new people on your team? Does the new person in the Operations Department <insert department/customer/client you serve> think you exceed expectations? Are you wishing people would just “trust you” because you haven proven yourself before? If you find yourself wondering why you don’t have the respect you used to, then it’s time to look at what you can do to reassert yourself.

Business Analysts regularly get assigned to new problems and new teams. It’s easy to remember the basics of building a reputation when all or most of the faces around you are new. The situation is very different for long-running teams / projects. It is easy to forget the basics when only one name changes at a time, but it is no less important.

Take the time to make a good impression for everyone added and re-added to your project. Introduce yourself to newcomers, whether they are teammates or executives. Find the chance or make a window of opportunity to prove your skills and capabilities. Show you know how to deliver as a daily habit.

If you’ve built a solid reputation, then kudos! It’s the first step to a great career and interesting opportunities. But keep investing in it. Don’t stop and rest on what you’ve done because building a reputation is only part of the goal. Now go forth and show you are worthy of your laurels!

Take away: Determine how to get the attention of the right people instead of waiting for people to notice you.

Thanks to Global Citizen for the picture above.

Bloom's Taxonomy

Assessing Yourself with Bloom’s Taxonomy

Have you heard of Bloom’s Taxonomy? More importantly, have you thought about how you can use the taxonomy to give yourself a performance evaluation?


Benjamin Bloom led a team of educators in the 1950s to identify a taxonomy, or classification, of learning objectives. The committee broke the objectives into three distinct areas, Cognitive (knowledge, comprehension, and critical thinking), Affective (emotional response and empathy), and Psychomotor (physically manipulate body and tools / instruments). For more information, I refer you to Wikipedia and Don Clark‘s articles for more information.

Bloom's Taxonomy

For my part, I want you to focus on the Cognitive function. You can find a number of cool graphics displaying the domain with an online search, but for my part I want to focus on the following chart, taken from “Critical Thinking in the Management Classroom” (by Athanassiou, et al., full reference below.)

Cognitive Hierarchy, credit to Athanassiou et al.

When reading this, I translate it into BA practices:

  • The basics of our job start with Knowledge, learning about and defining our business’ domain, able to answer a developer’s questions about a given process.
  • We daily demonstrate Comprehension, translating business process needs into requirements, paraphrasing and summarizing the business needs into the language of our multiple audiences.
  • Application is where we start to prove ourselves, applying business expertise to answer questions and predict behaviors & outcomes.
  • It takes deeps business knowledge to do good Analysis, understanding not only business definitions, but seeing patterns, recognizing hidden meanings, understanding the context of information, systems, users, etc.
  • Synthesis is all about combining old ideas to create new ones, generalizing for given facts, integrating and designing.
  • Comparing and discriminating, assessing options, and verifying the value of different ideas is part of Evaluation.

Note: Bloom’s Taxonomy was revised in 2000, changing the names from nouns to verbs and changing the order of the last two items. The new list is: Remembering, Understanding, Applying, Analyzing, Evaluating, Creating. It is worth considering if BAs should in fact spend more effort on Evaluation / Evaluating and have less need for Synthesis / Creating.

I want to argue every BA needs to be great. Every BA needs to be able to perform at all of these levels. Every BA needs to be perfectly fluent in each of the Cognitive domain areas. But do they really need to? I am better at some than others. In fact, I am better at some higher levels than I am at some lower levels. Does this mean I’m a bad BA? I don’t think so.

Imagine you could have your pick of three BAs. All three are very good at Knowledge and Comprehension. The first BA is outstanding in Application, applying all the knowledge they have learned. The second BA loves Analysis, in particular digging into business operations and understanding how it relates to business rules. The third BA lives for Synthesis, integrating old ideas into something that seems new.

Now continue imaging and tell me which BA would you pick for a project that has to combine information from four different systems into a single report? Which BA should go to the project with the stable team, supporting the finance department with regular upgrades and system maintenance? Which BA should work on building out a new CRM system to track all of customer interactions?

As you can see, different projects have different needs, different cognitive levels. And as individuals, we are better at some tasks than others. So what does that mean?

It means we need to understand and play to our strengths. It also means we need to acknowledge our weaknesses and look for the best way to support our project and team when the project does not match our strengths. You can partner with others on your team if Synthesis isn’t your strong suit. You can push more decisions to the team if your Evaluation level is weak. You can still contribute to a successful project when it needs one of your weak areas, but only if you are paying attention and diligently shoring up this level.

Here’s a checklist to think about your contribution to your current project, modified from Athanassiou’s paper:

The Checklist

  1. ____  Did you summarize the concepts / goals / stories / requirements covered by your business partners? (Knowledge)
  2. ____  Did you demonstrate you understood what this project was about by comparing it or contrasting it with other projects, requirements, applications? (Comprehension)
  3. ____  Did you connect the ideas from this project to other projects, initiatives, business goals, competitor actions? (Application)
  4. ____  Did you examine the business goals and requirements so that you identified the theories, assumptions, fallacies, and ways of organizing their ideas? (Analysis)
  5. ____  Did you explore the goals and use this exploration to build a new understanding of the business or formulate new ideas or solutions? (Synthesis)
  6. ____  Do your actions demonstrate you critique ideas and solutions based on an understanding of overall business objectives rather than personal opinion? (Evaluation)

Athanassiou, Nicholas, Jeanne McNett, and Carol Harvey. (2003). Critical Thinking in the Management Classroom: Bloom’s Taxonomy as a Learning Tool. Journal of Management Education, 27(5), 533-555. Available here (@ $32! for 1 day of access)

Hat tip to Chris Boynick for referencing the above paper and giving me more context to start digging into Bloom’s Taxonomy.


Forrester: Where are you finding strong business analyst talent?

ApplicationI was recommended to check out the new Forrester Community (registration required) and on the front page there is an active question about BAs! Analyst Mary Gerush asked:

What are your best practices for either developing business analyst talent internally or finding external help?


I answered the question in the forum (as did @dwwright99), but I wanted to post my response here because this is something I am passionate about.


I have found strong talent can come from anywhere, but winnowing the field down to the person you should hire is a time-consuming process. Don’t get me wrong, I think you should take the time, but you need to know it is an investment of effort to find great candidates. I have spent 5 – 20 hours per week for 2 – 3 months to find a single hire in one market. It was a serious investment, but it paid off with a world-class team I could drop into any situation.

My preferred BA hiring process includes the following steps*. I like this order, but the middle steps can be moved around without significant consequence:

  1. Resume review, with a focus on a variety of experiences and a pattern of growth. I avoid candidates who have only recently been award the Business Analyst title after helping with a system upgrade. I expect to see 60-200 resumes per hire.
  2. Critical Thinking Skills assessment. This can be via paper, online, or a challenging problem face-to-face. I expect to lose at least 70% of candidates due to high expectations.
  3. In-depth interview. I prefer the Topgrading model by Bradford Smart, but Lominger can work. This should show the candidate has a history of continuous learning, relevant growth, and can achieve excellence in your environment. You should end-up with insights into their favorite work environments, what they think of past supervisors, and how they are best managed. If you take less than 90 – 120 minutes, you have not plumbed deep enough.
  4. Team interview. This includes 2-3 current employees. At least two BAs, the third may be from the business or IT, but must be familiar with working with a good BA.
  5. Skip-level interview. Meeting with the hiring manager’s supervisor. Optional.
  6. Discussion & Decision. This includes a rating of the BA in the areas below.

Here are the questions everyone should answer in the Discussion & Decision step:

  1. Does the candidate demonstrate the known competencies we desire?
  2. Is the candidate strong technically? [elicitation, documentation, understand our technology, etc.]
  3. Does the candidate have strong verbal communication skills? Are they strong enough at written communication?
  4. Are they a good fit? [in order: BA team, project team, Customer & IT]
  5. Should we hire them?

I believe the manager should have the final decision with the following exception: When the team unanimously agrees the person is not a good fit with the team, the candidate may not be hired. I generally treat the team as decision makers, at teams even arguing why a given candidate is good enough.

I do think it is important to always be adding new skills and capabilities to a Business Analysis team. Whether this is business rules, product management, understanding of data, facilitation techniques, ownership spirit, etc. every hire should add something new to the team. When this is followed correctly, it leads to continuous growth and expansion of capabilities. It also causes those early superstars to be eclipsed if they don’t keep up, but that is a different issue.


* I’ve left out any cultural fit or technical skills screening interviews, typically performed by a recruiting department. For the most part, I have found few screeners get to the level of insight I desire or add to the information I uncover during the in-depth interview. If I cannot use them to screen out a bad candidate, I don’t want to waste their time for these steps.


What’s your best practice? Please add your insight below.

If you liked this post about hiring great BAs, please share it using the links below.

5-years into a 20-year Process

I was commiserating with a former Requirements Engineer about having to write a Business Analysis Manifesto, discussing why the profession and skill set is not yet recognized for the value it can add. Then he asked a great question, “How do you think we’re doing?”

Pausing just a moment, I replied “I think Business Analysis is 5-years into a 20-year process.” We have made great strides in defining the role, competencies, technical skills, and expectations for a Business Analysis, but really, we are still at the beginning of the journey.

In my mind, we are in a struggle to remake the world. I am sure I watched too much TV as a kid, but I want BAs to emulate Oscar Goldman talking about Steve Austin, “We have the technology. We have the capability to build it better than it was before. Better…stronger…faster.” And have not reached our potential yet. [Some license taken in this quote]

Anyway, looking back over the last decade, I see a radical improvement in the average BA. We still have a long way to go, but we are so much better than we were before. When I started interviewing BAs I ran into many who were not ready for my teams. It was common to find a BA who…

  • … had never had a supervisor who understood their role, or gave them the right assistance and encouragement.
  • … had never been to related training or conference.
  • … had never read a book or blog post written for BAs.
  • … had invented most or all of their own tools and templates.
  • … were given the title because they were former super-users, helping with the last version upgrade, but didn’t understand the greater role or responsibilities.
  • … was a former developer, but never received the support and time to understand business needs and processes.
  • … and so on.

The expectations were so wrong, of course our profession was struggling! I used to draw the following diagram:

Expected versus Actual BA Skill Levels

You can see I thought we were terrible. And by “we,” I include myself in that chart. But the world of business analysis has drastically changed over the last few years.


Some factors in the change come from the much greater abundance of materials about our profession. You may not remember this, but BA blogs were big in the pre-fb, pre-twitter days and BAs globally started writing about their experiences. It was a heady time just to read the barrage of information being put out into the world.

And a bunch of BAs in Canada were so cold one winter day they said, “Hey, why don’t we form an organization dedicated to helping our profession.” In just 8 years, the International Institute of Business Analysis (IIBA) is now 20,000+ members strong, chapters in 61 countries, and working on volume 3.0 of the Business Analysis Book of Knowledge (BABOK). The amount of relevant knowledge codified by these volunteers is breathtaking.

Following these leading factors, conferences, books (that are available in various languages because of the effort taken by Dandenong translation company), and networking opportunities for the profession are much more prolific than they used to be.

Simultaneously, if not proceeding the above, companies of every size were living what we read in the Standish Group CHAOS reports. Projects were failing everywhere and it wasn’t too hard to figure out the need for requirements would be a significant help.

Now we know the problem with project failure is ongoing and much of corporate IT attention has turned to Scrum and Agile, but first they started hiring and building their Business Analysis capabilities.


Now, if you’ve read this far you understand my take on our recent history. But how does this translate into 5-years into a 20-year process? Of course, it’s just a guess–you never know where you are on the path to a singularity until it happens–but my guess is based on the following factors:

  1. I am once again explaining to corporations the role and value of BAs.
  2. I am surprised by the differences of opinions even among BAs, some of whom believe anyone can do this job and think we do *not* have responsibility for understanding the larger goals of the business.
  3. The basic understanding of competencies (ala Lominger) for BAs is rudimentary.
  4. The basic technical skills a BA should have are growing, but still spotty.
  5. I have found dramatic differences in expectations for our contribution based on corporation size, industry, SDLC, and even geography.
  6. Conversations with BA managers / directors and Center of Excellence leaders show me some of the ongoing conversations about our role and value are ongoing, been lost, and sometimes not yet started.
  7. Talking with authors and speakers shows me we are repeating the basic message many times over and seldom getting to meaty, difficult topics because the audience (which includes both BAs and almost always their working environment) is not ready for it.

I’m encouraged. We’ve made great progress; more progress than I dreamed possible six years ago, but despite some wins the journey has a long way to go.

Please subscribe or come back often to read as we make this journey. Together we will Be Amazing!

(My) BA Manifesto

I’ve been working, again, on defining and defending what a Business Analyst is and does. I mistakenly thought this was becoming self-evident and the battle was over, but it is obvious the war is ongoing. So, to guide my thinking as I re-engage in the battle, I wrote the following manifesto. Please review and comment, because