You can’t get there with Scrum

A lot of business units and a lot of organizations today are obsessed with Agile. Even in departments where all development is outsourced. Even those that never build their own software and always rely on procurement to get what they need. They’re asking that of their vendors, their business analysts and even their business users.

Everyone is excited with Scrum and beating folks over the head with it…. And they expect marvelous results.

Unfortunately though, most of these companies will never get what they want. And here’s why.

Nineteen-page use cases

We were recently engaged with a client where IT has been notoriously slow and the CIO was getting a lot of heat from the business side. After digging a little deeper we found that roughly 60% of business requirements produced had never got into development, simply because development never got to them in time.

We looked at the development team and found out that they have in fact implemented Scrum and their output per iteration and their quality of code was good. At the same time, the business was complaining that these guys can’t even get one use case implemented.

We looked at a Use Case document and found some really long Use Cases. One of them took the BA 19 pages to explain what the system was supposed to do. And after digging a little deeper we also found some missing requirements!

So was the IT really the problem?

The broken pipe

Let’s ‘take a step back’ and look at the entire process. Let’s see what it takes for a business goal to materialize in a form of a working and effective software.

Dmitri Khanine

It all begins with an idea. Someone on a business side requests a change to an existing process, tool or an application. Business Analyst is then engages in a number of activities, filling in all of these important additional details, validating the requirements and making sure that implementing them will actually produce an effective solution.

You see, it’s almost always possible to validate with a high degree of accuracy whether the solution will actually meet business needs or it won’t…. before the first line of code is ever written.

And in the rest of the cases, you actually can validate the solution much, much sooner than it would take to fully deliver it.

Once the requirements and designs are complete, they’re handed over to development team. So will it help if we turn the knobs and look at your development team under a microscope? Will it make your end to end implementation that much better?

Turning the wrong knobs

It actually won’t as a lot of things is happening way before someone on development side will ever know about the new project!

In another client’s case it was taking 6 to (in some cases up to) a year to get the requirements ready and then up to 4 months to deliver a project.

So will it matter if you optimize the hell out of your development and deliver in 2 months instead of 4? What will it do to your time to market? And will getting user feedback in 14 months instead of 16 make a dramatic difference on your business decisions? (When you can get that feedback in just a week or two!)

You see, almost all Business Analysts are following the BABOK Guide, but how well and is there a metric? How good are your BAs?

Are they ‘downloading’ requirements and just writing down what a stakeholder is saying? Are they looking to understand the realities of the end user workspace, things like the attention span, noise levels and dealing with interruptions? Do they use prototypes and user testing for validating requirements or are they just relying on document walkthroughs and obtaining signatures for their validation?

Are you seeing confusion around the scope and direction or lack of project alignment with business needs? Are you seeing developers getting stalled looking for perfection and missing the mark or trying to anticipate business needs instead of getting the facts?

All of these are the early warning signs of serious requirements trouble.

Now, in most companies it’s always the business side that gets the blame for requirements issues, so no action is required on your side and you can continue to try to optimize and squeeze the last little bit of extra efficiency out of your development team… Or you can take a step back, look at the big picture and get a ‘plumber’ to fix that huge leaky pipe between your business and your development side – pipe where a lot of stuff gets piled up and even more stuff gets missing.

Am I describing your situation or you’re seeing something entirely different? Did Scrum alone get you where you wanted to go? Would love to hear your thoughts. Please lay them out in the comments area below.