As I’m presenting at a conference on Agile software development (wiki entry) I’ve been reviewing a number of my recent projects using this development methodology to help you understand the challenges that you may face in using Agile in your businesses.
Do your customers understand Agile?
One of the benefits of Agile – as the name suggests – is that the project can respond more rapidly to business change. Unlike traditional sequential or waterfall developments that are run in a “requirements – design – build – deliver”, Agile embraces change in each round of development in a highly adaptive way. The bad news is that your internal customers may take it as an opportunity to design process “on the fly”, or even to design and implement significant organisational change on the back of an Agile software project!
Now, I’m NOT saying that Agile techniques can’t be used for organisational development. Quite the opposite in fact – so long as you have your employees on board such that rapid and perhaps repeated change isn’t a demotivator for them, it’s quite possible to use multiple iterations to develop an organisation in an organic, yet well aligned way.
What I believe is important in the main target areas of software and solution development is that certain key elements must be in place to let Agile do its thing. These are:
- Enterprise architecture – or at least a clear strategy, roadmap or well-articulated vision
- IT strategy
- IT architecture, at least to a level that enables decision making within the agile team without constant referral upwards at every decision point
- IT governance to ensure that architectural compliance is adhered to, and checked at the right points in the project iterations
- Well defined processes in the customer organisation, or an acceptance that process development is part of the Agile project (in which case strong change leadership is essential in that organisation)
- A realistic goal for the next few iterations of the project, and an end goal if one exists
Get these in place and you have a good chance of success. Miss any out and the predominant work (and therefore cost) will be in managing the relationship with your customer and designing process, while the risk of constant technology rework is there to sap your project of momentum as it fails to match the real “on the ground” process.
Working with a geographically or culturally diverse team
It’s important to train your teams in Agile development, since a lack of understanding of the different structure of an Agile project will confuse people who have worked in more traditional Watefall projects. They may complain about changing requirements, moving targets, and generally put up barriers to the very journey of discovery that makes Agile so effectve.
This is exacerbated when you have multiple cultures (business and geographical), as working practises differ across business sectors and countries. Taking the time to explain why the business needs an Agile approach is time well spent.
Managing geographical diversity is another challenge. Even video conferencing, daily conference calls and email can’t replace a group of colleagues in the same office. There isn’t a single answer to this problem, but having effective and well trained team leaders in each location can help, as can having an exchange programme to have team members swap locations for periods of time, improving understanding and acting as a communication conduit between the teams. The other big help is putting middleware at the core of your architecture and ensuring that your middleware team is represented on every Agile project you run, as that decouples some of the dependencies between technologies, and therefore the teams that manage them.
More in my next post…