Heather McLean

Thoughts on agile methodologies and leadership.

Archive for January, 2010

Participation, success, and failure

without comments

Successful software projects require participation and commitment from both the stakeholders and the development team. All too often, business owners like to brainstorm a list of requirements, which is typically an unprioritized jumble of “must-haves” and “nice-to-haves” with no direction, then throw those over the wall to the IT department to implement in a vacuum. Without ongoing feedback to determine priorities and success, any team dealing with this situation is bound to fail. Sadly, most teams accept this state without argument, since that’s “just how things are” in the IT world.

True success requires an ongoing conversation between business and IT at the very least. In an ideal scenario, we can break down the traditional barriers between business and IT that have been erected in most organizations and quash the “us versus them” attitude. This typically means having a full-time product owner on the team who can provide direction and timely decisions regarding the product. It’s actually quite disheartening to see how many teams try to plow through a project without this crucial guidance. Is it any wonder that the customers are often disappointed with the end result?

What demoralizes the team even more at this point is that they are often blamed for not fulfilling or understanding the requirements they were given, and the stakeholders are seen as inculpable for the failure since they are certain that they provided all that was needed. This is simply not true; no matter how good your requirements, design documents, and project plans are, nothing is a substitute for ongoing, active participation with the people who are actually delivering the software.

I believe that most of this stems from the misguided notion of running IT as a business—in other words, an internal vendor completely separate from the rest of the organization. This furthers the disconnect between the stakeholders and the product team and reinforces the artificial barriers I mentioned earlier. Also, the notion of “chargebacks” pushes the stakeholders to treat IT as they would an external vendor: with little trust and without direct participation. To fix this, IT must be integrated with the rest of the business in such a way as to be part of the team rather than a separate entity unto itself. Likewise, they must be given a healthy budget to do both maintenance and growth, just as if they were any other division of the company, rather than relying on chargebacks to fuel projects.

Written by Heather

January 20th, 2010 at 10:46 am

Posted in Agile