Agile Builds Trust with Fast Feedback

Agile development builds trust by giving people systems they can work with and respond to in short periods of time

Agile development has been effective in building trust between business and IT because it delivers results in short iterations and gives business people the chance to use and respond to what IT delivers. The long lead times inherent in the waterfall development approach were and still are the source of much distrust. Traditional waterfall approaches create a gap of anywhere from three months to two years between when business people can say what they want and when they actually get to see what IT has built.

Waiting all that time while IT builds the new system reduces the chances that business people will like whatever IT delivers. That’s because the world will change during that time and new requirements will come up that could not be foreseen. Elaborate procedures have been created for gathering requirements and documenting what business people want, but they only serve to deepen the distrust between the two sides. Handoffs and signings of massive requirement documents do not solve the problem for either side. They require business people to try to predict future needs so they ask for everything they can imagine, and the resulting complexity overwhelms IT capabilities to deliver such a complex system on time or on budget. Everybody loses (and IT usually gets blamed).

[ I do lively presentations on this and related topics - ]

Agile Development Stops the Downward Spiral of Distrust

Agile development addresses this problem by iterative delivery of system functionality to meet requirements that people know they need today. Because people aren’t asked to think of everything they could ever want, the number of requirements is much more manageable. And even within existing requirements, some requirements are always more important than others so if IT can deliver on those requirements right away (in 30 day cycles for instance), then business people get more value more quickly and the process builds mutual trust based on fast feedback and shared success.

At the 10 Years of the Agile Manifesto conference this month a group of experienced and thoughtful IT pros talked about how they have seen agile techniques rebuild trust between IT and business. The transcript of this conversation is shown below (and you can also see the VIDEO OF THIS CONVERSATION on YouTube).

Todd and Russ

Philippe Kruchten – It [Agile] stopped this way down into more and more distrust which we were compensating [for] by massive amounts of intermediate useless…

Ryan Martens – Big handoff things…

Philippe - …massive amounts of prescriptive process, [and now we are] into less of that; more direct communication and a building of trust between various parties. Initially just inside the team, which is already quite a good step, and now with some of the external stakeholders. That has changed; that’s one of the big impacts of the agile stuff beyond JUnit and Rally, VersionOne kind of tools and burn down charts…

Ryan – I don’t know if I could substantiate it as much as you can substantiate the other ones, but there sure seems to be more of an emphasis towards shipping and getting feedback and adjusting to that feedback, there is the just ship it…

David Anderson – I think that’s fair…

Philippe – That’s what builds trust.

Ryan – Yes

Philippe – When we have feedback and we act on that feedback combined with a little bit of respect and listening and all the good stuff there. Because before that we said, “I’ve done my job,” and passed the document down the line, you know, and sign off and all that.

Russ Rufer – Driving it too was that a lot of software that motivated agile, ah like, things just weren’t getting delivered. There was an effort; it got through analysis; it got through design, you know, like it maybe fell down somewhere in coding or testing and maybe never even went out the door. And, you know, we’re all hoping that maybe fast feedback loops and shipping things early and getting feedback has led to some successful fail-fasts and to maybe some things getting out the door in time to have some impact without maybe the whole kitchen sink built in, and yet, like no one really wants to look at something and say, “Oh I see how much more successful this is than, you know, we probably would have failed if we had done it some other way.” And like it’s hard to compare what you’ve done against a possible future.

1 2 Page 1
Page 1 of 2
FREE Download: Get the Spring 2019 digital issue of CIO magazine!