Making Agile methods mainstream
Have you thought of all the things that you might need to consider when adopting Agile methodology?
Most organisations that are using Agile methods started doing so because someone in IT thought it was a good idea. They tried it, and it spread.
That is to say, it was/is an emergent strategy. The problem with emergent strategies is that they tend not to take much account of the impact they’re having on the rest of the strategy, and the business. This is usually because those adopting the new strategy, don’t have any influence or responsibility for strategy or the business.
Prior to the use of Agile methods, there wasn’t a time when the majority of IT projects were regarded as successful in terms of time, cost and quality (fortunately, these are not the final arbiters of success). Unfortunately, a recent Agile survey* indicates that things haven’t really improved.
What has changed, though, is the list of reasons for lack of success. These focus on the failure of management to adapt to become Agile. While that may sound a little like blaming someone else (or, indeed, anyone else), it does have some merit. If we identify what’s different in Agile, and so a candidate for a management response.
Firstly, the cycle time of Agile development is much shorter.
This demands that project governance must be able to respond in a similar timescale. Instead of having a monthly project board meeting to review progress, review the outputs of the recent iteration, decide whether a further iteration is required, if so, approve the priorities.
If the Agile development is part of a programme, there won’t be time for both project and programme board reviews. When there is more than one level of governance, Agile demands that you go straight to the highest level required for the constraints. Without stopping at any intermediate levels. You need to cut out the middle man.
Secondly, the amount of business knowledge demanded by Agile on a day-to-day basis, is much higher. This is because requirements are being identified, fleshed out and validated as the work proceeds. It means that the availability of expertise in operations must be higher. There needs to be a ‘go to’ person available to the project as well as to operational staff.
Thirdly, development teams need to be small and stable. It may be harder for Agile teams to ‘gel’, but they’ll be much more effective when they do. This has some serious consequences for how the organisation structures its portfolio of work and how individual projects are structured. It also implies that the practice of raiding existing projects for resources is highly counter-productive.
What are your thoughts? We’d love to hear how you have been adopting Agile in your organisation. Continue the conversation via our chat box.
