"Getting" the Business Means "Get In" the Business

It's always fun visiting the customers at their own workplaces. What takes an hour to describe can instantly be seen; the proverbial picture that's worth a thousand words. I was out at a customer site last week and noticed a very depressing ritual that I have seen many times before. Here's how it goes ...

1. The consultants are brought in to solve a problem;
2. The business users are excited that, finally, something is going to get done to fix the problem;
3. The problem is discussed, a couple of quick suggestions and concepts are described and the business users are enthusiastic about the possibilities;
4. The business users ask, "So, what are the next steps?"
5. The IT manager says, "Well, we need to gather the requirements."
6. The business users physically roll their eyes and slump back in their seats in anticipation of another snail-paced, IT boondoggle.

Here is a very, very important lesson every technology consultant needs to be mindful of: The biggest barrier to your success as a consultant is the technology organization you are there to help/support/augment.

This isn't about folks in IT not having ever learned how to read a balance sheet or other such easily learned knowledge. This also isn't about understanding the basics about how their employer actually makes money and who the customers are. This is about being able to put yourself into the shoes of the people who actually use and need the products and services you provide/build. This is remarkably easy to do.

The key to "getting" the business is to "get in" the business. In this particular case, I had spent a significant chunk of the day on the factory floor observing how people actually accomplished their tasks, complete with impediments, workarounds, frustrations and pride. No requirements document would ever be able to describe the environment and conditions under which the tasks needed to be completed. They would only describe what the user interface was supposed to do. Hopefully I will return in a few weeks where I will resume gathering requirements from the factory floor.

That's right, turn off your computer, put down your whiteboard markers, leave that sterile ivory tower and get onto the floor or out into the field!

Sale or Adoption

James McGovern talks about failing to sell A/agile in the enterprise. While close, I believe the sales process is not at fault, rather, it's that path to adoption. Also, along with everything else, it's all truly about alignment with the business goals and strategies.

I've recently had the benefit of seeing the life-cycle of almost a dozen agile software development projects over the past year, some ranging through multi-year efforts. I have seen the victories, the failures and the in-between. I started noting some contradictory behavior between customer needs and agile practices, especially the more dogmatic ones. However, I didn't have sufficient data to make any good correlations.

One particular incident involved Test-Driven Development (TDD). In this case the dogma stated that TDD must be done. However, it was truly placing the delivery schedule in jeopardy. Moreover, the deliverables only needed to be good enough. Needless to say, a large rift developed dividing the dogmatics and the customer. Thankfully, the customer's needs prevailed and TDD was tossed and the product was barely delivered in time. This is only one such incident but, clearly the whole concept wasn't working as advertised.

A couple of weeks ago, I stumbled across this paper about software process adoptions. 7 years ago, someone has already thought through this. Bringing back the TDD example, trying to apply a technique that emphasizes quality when the real strategy is innovation (where customers willingly trade quality for newness!) is completely counterproductive. That is, avoid prescriptive processes that require discipline when quality is not the business strategy. Clearly, no matter how hard we try to sell agile, we will fail. Why? There is no logical path for adoption.

Don't sell agile!

To quote a colleague, "Nobody buys Toyota trucks because of the TPS and lean manufacturing."

Technical Requirements

Simon Brown was kind enough to comment on my previous post and said,

"I'm trying to tackle the other (easier?) problem of when technical people don't even think about NFRs. First things first, we need technical people to understand why NFRs are important."

There's a very simple way to get technical people to understand why technical requirements are important. They must be clearly and logically linked to delivering a functional requirement. Go one step further and simply remove the distinction between functional requirements and technical requirements by stating how a functional requirement must be delivered in terms of quality-of-service or a service level agreement. An example:

"The customer must be able to securely submit the final order plus payment details and receive an acknowledgment via both email and a following web page in under 10 seconds."

Separating technical and functional requirements makes it all too easy to make the former into an afterthought.