autotelic, autistic, assonance-hole©.

Zen & The Art of (Agile) Business Analysis

I begin this piece by admitting that I am decidedly piqued at what is happening to the analysis profession of late; I admit as well that I’m slowly slipping into that bracket where a tendency to be nostalgic is definitely in the mix and, perhaps, coloring my view more than I realize (or should allow). In short, it often seems to me that the attempt to accelerate the speed of business and technology development forgets that there are certain aspects of “the process” that cannot be effectively accelerated. Frankly, attempts to do so notoriously result in unintended outcomes, gaps, poor or incomplete implementation, and rework (i.e., cost and a degree of failure to meet business or market expectation).

The amusing part is, you can take any given executive or business person aside as an individual, have a conversation about things, and they will freely admit that the points I’ll be outlining below not only are “common sense”, but good practice as well as solid business method. Yet, these same beings, in the midst of a program or project, will freely disregard or even lambast the very points they so readily agreed with, almost as if some terrible amnesia has lain waste to their mind.

There are truly only four salient points to any analysis, even as the level of granularity needed as well as the way one represents them can and will vary from effort to effort:

  1. What is the issue we want to solve?
  2. What do we think is the best solution, given the time, money, and resources at hand?
  3. How will we know we’ve solved the issue?
  4. How will we prove this to others?

You’d think it a simple thing to manage, right? Particularly when all you need to do is clearly set the answers forth, have everyone acknowledge that they (a) understand them, (b) agree with them, and (c) support moving forward. So why does it seem that it becomes more and more difficult to achieve?

My professional (and personal) perspective is that many of us have fallen into the trap of thinking that it’s possible to fully understand an issue by talking about it and documenting that conversation at the highest level; that it is possible to adequately estimate time, money, and resources based or determine “the best solution” by working with high level assumptions (both of need and of risk); that it is reasonable to presume that “solved” equates to “we delivered something at the agreed upon time and for the agreed upon cost”; that “proof” is best verified by the collective aforementioned.

I see this detrimental pattern increasingly within business, but nowhere more overtly than in companies who abuse Scrum/Agile methods in an attempt to avoid the simple reality that there is no “fast path” through analysis.

Don’t get me wrong, I adore Agile as a development method. It’s simple. It’s elegant. And, when used correctly, it’s an efficiency generator the likes of which technology has not before seen.

Sadly, it is frequently used any way but correctly. A few of the many abuses I’ve encountered in my career include things like:

  • Insisting that you don’t need a BRD because you’re writing stories.
  • Determining that you don’t need architectural design documentation because you intend to write system stories that will cover it all.
  • Deciding that prototyping isn’t needed because you’ll demonstrate every sprint, so it’s a waste of time.
  • Proclaiming that success criteria in a story cannot be detailed because this violates Agile practice.
  • Saying that epics and stories exist so that diagrams and flows do not need to exist.
  • Asserting that traceability is not needed except between test sets/cases and epics/stories.
  • Mandating that “large” stories (i.e., sized at 60% or more of a given sprint’s effort) are perfectly alright, and three or even four week sprints are acceptable.
  • Bypassing integration testing because “That’s what User Acceptance Testing is for…” (Yes, someone actually said this.)

I really could go on (and on!), but you get the point, I hope.

Like any other method, Agile is a tool. It’s designed to be a flexible tool, but it does have a baseline of acceptable practice because all such systems must have this in order to be enforceable, governable, and most importantly, repeatable at the same level of cost, time, success, and quality.

An Agile analyst’s primary tenet is that you have to be working at the appropriate level of granularity in defining your stories so that you can reap the benefits of rapid iteration. How, precisely, does one attain the appropriate level of granularity when no one has bothered to agree on what that is (and most are busy arguing that ANY granularity is a waste of time)?

I have a number of colleagues who bemoan failed Scrum/Agile implementations and the inevitable return to the Waterfall that results. But when I ask them about Agile, they consistently repeat the various statements of misuse and are seemingly unable to recognize the correlation between those choices and the outcome.

When I am mentoring or educating others, be it as a “value add” or for hire, those four questions are the foundation of any conversation I engage and their importance is the first and foremost understanding needed to grasp how to effectively use Agile (or, frankly, any system of expressing needs and plans).

Interestingly, the concepts contained in those four questions are far older than Scrum/Agile or Waterfall. I’m sure you’ll recognize this if you consider them outside the context of technology and development for more than a moment. In fact, you’ll recognize them as a pattern of both thinking and achieving that underpins any endeavor a human may engage. I point this out because here, in my mind, those four little questions encapsulate a pattern within humanity at large that everyone knows… even if they usually don’t think about it quite as much as their friendly neighborhood analyst.

In fact, I invite you to play with those four questions and see for yourself. Feel free to change “issue” to whatever word or phrase best fits and have at it. I think you’ll find the very fact that I’m pointing at in this post;  humans are two things by intrinsic nature: Pattern Recognition Machines and Process Engineers.

Zen & The Art of Business Analysis, at the end of the day, is nothing more than understanding this so fully and well that you can naturally apply it to anything with which you engage.