On Agile, IT-Business Alignment, Martin Fowler and The Yawning Crevasse of Doom

I took some notes from a great keynote at QCon recently (which was really excellent by the way, more later), but never polished them up. So much for live-blogging…

For those of you that don’t know him Martin Fowler is a bona fide agile rock star – a practitioner steeped in practical lessons to improve development and business alignment.  His partner in crime in the QCon keynote was Dan North (currently building out a theory of behaviour-driven development). The double act was hardly Laurel and Hardy slick, but both guys gave great insights about effective software development cultures and worked well together. Hopefully I have captured some of these insights here. If you’re in a hurry just read the bold.

So what was the keynote about? The Yawning Crevasse of Doom, signifying the gap between software development and business.

“The biggest problem we have in software is communications between the business people and the developers.” Amen, brother.

“We are used to seeing and hearing about big IT failures, but often the communication gap is in small things, delivering things that aren’t very useful.” Tell it, Martin!

Why Ferries Don’t Cut It

Fowler gave a suggestion for addressing the crevasse, based on two different ways of looking at the world – if you want to cross something you can use a ferry or a bridge.

Often we use intermediaries when we try and encourage a dialogue between different communities, such as the much-talked about (and seldom found) “business analyst”.

The analyst plays the role of ferry, carrying traffic from one side of the divide of the other. “Because of course, you never want business people to talk to developers… because they are hairy, smelly, and talk technical babble.”  😉

But argues Fowler “Any profession has jargon”. What is more –  

“Ferries don’t provide much bandwidth.”

A bridge, on the other hand, “offers direct communication between business and technical people. It allows rubbing together of different skills.”

And besides, said Fowler, if you’re going to cross a crevasse “its easier with a bridge than a ferry…”

Proximity, Serendipity and the Java Printing “Requirement”

Fowler then told a story that explains exactly why it makes sense to have techies talk directly to business people, but also points to the variance between “requirements” and real value, between requirements set in concrete, and those that really map to business needs.

The business person was adamant they needed new software, because the Java-based system they had ordered didn’t offer the right level of printer support. The techie who came to the office was intrigued to know why printer support was so important.

The user explained .. “Well, we need to be able to get a print out from that system there so that we can then input the data into that system over there.”

Developer then says… “Ummm. are you sure you need better printer support? We could just build a script to move the data from one system to another.”

“You can do that???” asked the user, surprised…

So much for “requirements”. And the moral of the story?  “A new requirement can come from a conversation.”

Agility meets NLP

Then Dan North took the reins, and introduced a useful concept, seemingly from leftfield – that is, Neuro linguistic programming (NLP). He explained that users and techies tended to program themselves to deliver poor outcomes.

The business person has this in mind. “You won’t deliver what we want. Even after months of negotiations.”

Techies meanwhile are thinking: “We know better than you, so we’ll overwhelm you with technical details.”

One way to overcome this barrier is to make design decisions later in the process – rather than thinking through every potential scenario and developing accordingly, only set things in stone once they are needed. “We dont need to make the decision now. make it when we need to. Its easier.”

So how can the two communities communicate more effectively? Bring. Teams. Together.

DN: i start thinking about the business analyst as bridge-builder

MF- Its about caring about whether the whole thing works. and motivation… if you have direct contact with the people that will use the system thats a hell of a lot more fulfilling.

DN: Who here has been on a project they know is doomed? (About half the room put their hands up. I expected more). 

MF – “Get two [equities] traders to come and do their job sitting in the same place as the developers. The traders start to realise the developers were caring about what they were doing.”

Seeing highly motivated people in action tends to rub off on other people, even if they are motivated by different things.

Summary Points, DSL and Object Theory

Point 1 – Prefer bridges over ferries

Point 2 – Understand how programming languages affect communication. Try to make the language as readable by the business expert as possible (Fowler didn’t use the phrase “view source”, but its v applicable). Even if the business person doesn’t fully understand the computer language, they can kind of see how it fits together, and more importantly feel a spark of recognition: “Oh – that takes some data from my invoice!”

Fowler believes in Domain-driven design, and the corrolorary domain specific languages (DSL), because he beleives they are more effective in spanning the crevasse. “Create a ubiquitous language, where he names of the classes and how they are combined matches the business conversation”.

“Its why i like objects. People can have an understanding of what’s going on.”

“I dont assume business people will sit down and program in them but whats important is they can look through rules and review them and say ‘that’s not right’ is very valuable.”

Sounds a bit like thingamy doesn’t it? Perhaps Martin should be talking to Sig.

Fowler explained that his theories are based on real practical experience.  “I have been involved in building a data model across the UK National Health Service. But models are better if they are local, it’s better than to try and build a single model, which is too complex or too abstract. Contextual is the more straightforward and effective way to go.”

Point 3 – Fowler also suggested rather than build a single data model a better idea was to pass data on, using “classic iterative planning.”  Doing  so means that demos and prototypes can use real data, as opposed to mocked data, which again makes development much more real and compelling to business people.” [Regulatory Demands for anonymised data notwithstanding of course.]

Potshots at SOA

MF: “The problem with SOA is it means lot of different things to different people. In many organisations it means we’re hopeless and overweight as an IT department. but we’ll reorganise and become more effective. What does the business hear, in that case? A Peanuts-style “whah whah whah whah whah whah”. That area of SOA leaves me v cold and v worried.”

DN: Better to focus on stories, lets use information in tiny nuggets…

MF: At Thoughtworks the whole idea of useability is written into the process. Human beings are squishy, random and so on. From that comes the idea of “lo-fi prototyping… dont make it look too polished or they will say roll it out now.” Nailed. 

Dan also suggested software could learn from the production process behdind the movie industry – film all the scenes on the island at the same time. Dont keep going back to film a new scene at a location you’ve already been to.

MF – the best requirements come after the feature is put into production. Are people doing funky stuff with the application? How can we help them do more of that?

On Done

Two words- enough and done. “i thought we were done”. “we did enough.” 

Testing offers a shared language for “done”. Put tests in place and then done becomes much easier to deal with.

From test-driven, to behaviour-driven, development. Enabling a shared understanding of “done” – what is good enough, in both parties terms?

Get the IT people out into the business (druidstreet?)

The quickest way to destroy your own feedback loops it to offshore your helpdesk. (now that’s a sentiment i know James will agree with).

 

 

disclaimers: I chaired a track at QCon but was not paid to do so.