Agile approaches to projects have been touted by many organizations across the globe. IT shops frustrated over expensive projects falling well shy of their goals have been desperate for change. These anxious organizations race into trying Agile as a solution to their woes.
The general migration usually involves paying high-priced consultants to help re-tool these concerned organizations. Banners are raised, groups re-distributed, larger amounts of staff time get used up in “short” stand up meetings which are intended theoretically for discussing the work being done. Then months later, these organizations are disillusioned over expensive projects still falling well shy of their goals, leaving the organizations perplexed and bewildered. Adding insult to injury, when these organizations listen to their staff, which they often do not, then these organizations are informed that for all of the supposed efforts, time, and money expended, Agile has really not happened and thus failed to accomplish what was expected.
Reasons for failing to establish Agile techniques across an IT group are, like the demon name, Legion. Among those reasons for failure one of the more curious often mirrors how the organization chooses to relate to failure itself. Within an Agile framework there is a concept of failing fast and then recovering to move on to success. But in far too many organizations failure is a concept whose name must never be spoken. Before Agile, failing projects had management standing up for them; explaining to users that the user community did not understand what was being asked of IT and that the insufficient solution was what users, obviously, should have been expecting. A tap dance was performed for assuring users that what they thought they wanted was coming, later, and users should have understood that from the beginning. Left is right, up is down, at any cost users needed to be convinced all was well - even when things were seriously wrong. For IT, such reactions were simply a coping mechanism for survival. Sadly, those techniques do not hide things for very long. Those missteps and failures were why organizations ended up desperately searching for a new approach.
The inability to acknowledge failure can become a cultural norm within an organization. Such a force can derail Agile efforts. This everything-is-success perspective can pervert things. When users provide feedback about the latest deliverable not being what they want, an Agile team should accept that response, gather detailed information, and then use that newly acquired knowledge to correct the object under development. Agile techniques focus on delivering smaller pieces at a fast pace, so that failure of a single small unit is meant to be a small thing. The IT management needs to view these small deliverables as what they are. If instead, users are talked down to about the solution really being what they want, or that the users do not appreciate how things must evolve, the only result is disengaged users. And disengaged users are exactly the opposite of what Agile approaches are trying to accomplish.
Accept failure. Failure happens far more frequently than most organizations are comfortable admitting. Although failure isn’t the best thing, within Agile it can be the second best. Organizations wishing to go Agile need to back off from the usual flinch response of hiding failures. It is the fear of punishment that drives employing all the cover-ups, word-parsing, and other evasive tactics. These shifty techniques are often the main cause behind business having bad thoughts about their IT partners. Look at each failure as an opportunity to improve both your IT deliverables and your understanding with the user community. These circumstances are indeed opportunities and should be embraced as such.