Why?

I have worked on several agile projects and found they went really well. We talked to the customers, found out what they wanted at each stage (and even let them change their mind sometimes), delivered frequently, and proved it all worked with a fine body of tests.

These projects were clearly successful – so maybe agile methodologies were the answer. I did have one niggling concern, though. I noticed it was always the best people we put onto these projects – not just in terms of their programming abilities, but also in the analytical ability of working out with customers what the requirements were (albeit only in small scale increments).

These developers, then, had somehow gained the requirements gathering skills seen in analysts of old – they weren't drawing lots of code-level diagrams, nor were they simply writing down what the customer said. Rather, they were doing real analysis of their interactions with customers.

I often wondered what would have happened if the folks involved were not so highly skilled in their analysis abilities. Eventually, I actually found the answer (at least in a single project which shall remain nameless to protect the guilty). A customer asked a team with which I was working to develop some business software over two years. We were to deliver it incrementally – taking an agile approach – with deliverables every month or two. For each increment, the team negotiated requirements just-in-time with business folks, gave demonstrations to the customer, developed lots of tests to prove the software worked properly, and was given the thumbs up at every stage that we were doing a great job.

Then, after two years (and about 15 releases) we were told "that isn't what we wanted at all".

Well, what a knock to the head that was. How could we have been “doing a great job” throughout the whole project, and then have delivered the wrong thing at the end? We had been "fully agile" we had customer involvement and approval at every step. It didn't add up.

It took me a while, but eventually I realised that we were taking customer "thumbs up" as a sign that we were doing the right thing, whereas the customer was taking our own frequent deliverables as a sign that the project has a heart beat rather than stalling, and hence was in no need of interference. As one business person later said to me “I am am too old to understand all this – we leave it to you younger technical guys”. Nobody was questioning whether we were actually building the right system. All the little pieces were correct, but the overall system was completely wrong.

Eventually, for this and many other reasons, the company hired a new very senior manager to oversee most of the business operations. He turned out to be just what was needed: somebody with the authority and insight to keep asking "is this strategically correct"? That is, he remained very much focused on continually asking not "can we make a computer system that meets tactical obligations?" but more importantly "what are the strategic business needs towards which our computer systems should contribute?"

His questions were quite simple, but they caused a major shake-up. The two year agile project was frozen (a euphemism for canceled). The project started again, but this time with a small group of very experienced people from both the business side and the technical side, continually driving requirements decisions from strategic business needs. That is, not just asking "What and How?" but also "Why?"

I see this as the real heart of the problem in many of the projects in which I have been involved. We were forever trying to get people to pin down the "what, and how?" requirements of the computer systems in a specifications that we could then translate into code. This is not analysis, this is transcription.

Analysis – the part developers rarely have the background and (perhaps more importantly) the authority to do – is the art of asking "Why?" all the time.