Fashion is everywhere. Fashion introduces new things to us - and recycles the old! Fashion creates product and demand; it generates sales and profit; it breeds need. Even in Information Technology, we love fashion. It gives us the opportunity to create new notions and processes; it is a natural bedfellow with the rapid changes in technology that we are now seeing, inventing new ways to use those technologies and creating new ‘products’ from them.
Yet what we actually do in IT is the same as ever: we teach machines (computers, now of various favours including mobile phones) to take the data we give them and then manipulate and store that data for future processing (more manipulation) or reporting. Occasionally the data is used to control other things, like traffic lights or machinery - or even spaceships and cars!
Ensuring that we do a good job in building the systems that make those manipulations effective, IT professionals have always invented rules and processes around the development cycle in order to try and make the end product as good as it can be. As technology moves on and the pace with which development can be carried out quickens, the volume of changes and the speed with which results are needed both increase, and hence new models of development are needed.
And so we have seen a progression of methodologies like ‘waterfall’ through ‘rapid application development (RAD)’ and on to ‘Agile’, the current IT panacea for this decade it seems.
Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. (Wikipedia)
Like many ‘next great things’, Agile will only be as good as the people and organisations that adopt it However, we might be missing a trick here. Should ‘Agile’ not be a state of mind, a philosophy, rather than a methodology or series of formal IT processes? For one thing, if a development team is working in ‘an agile way’ but the rest of IT is not, or the culture of the business as a whole is slow and ponderous, will ‘Agile’ not inevitably fail to deliver as much as it might promise to?
Take the Wikipedia definition above. The “collaboration between self-organizing, cross-functional teams” requires everyone involved to be able to work in the same way. “Rapid and flexible response to change” needs to be in the DNA or culture of the whole organisation; what’s the point in producing IT systems quickly if their prospective users do not readily embrace change?
If we think of being ‘Agile’ as being “the answer” and that it relates just to IT software development, then we are deluding ourselves. ‘Agile’ needs to be part of the corporate culture.
Agile is a cultural philosophy as a result of which decisions, actions and business solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary and incremental progress, early delivery, continuous improvement and the elimination of waste (in all its forms), effective and prompt decision-making, and encourages a rapid and flexible response to change.
OK, I know this version isn’t perfect - but doesn’t it sound much more like the kind of business we would all like to work in?! Isn’t it more inclusive and relevant to all our staff, rather than that minor percentage employed in the rarified world of IT application development? Yes, it might increase risk a little; and yes, it will demand better delegation, more accountability and so forth. But in the end, those are probably good things - and any negatives should be outweighed by overall commercial benefits.
And I expect each of us can think of real, every-day examples of where being ‘Agile’ can bring true improvement - in bottom-line, morale, responsiveness etc.
Why not change the format and content of that monthly departmental meeting so that we can focus on just the critical points and get through it in an hour instead of the four hours it currently takes?
Why not reduce the number of people needed to take a decision to those who are really affected by it so that the decision is made more quickly? And why not make decisions when a) you have 80% of the data needed rather than search for the 100%, or b) when everyone knows what the ‘right’ answer is anyway?!
Why not redesign our organisations to facilitate teams whose sole purpose is rapid response or firefighting?
Why not cull the hundreds of documents and reports we produce and focus on the very few we actually need?
Why not, why not…
Agile as a software development methodology is all well and good, but until we broaden our thinking to embrace more than just IT, we will never get the full potential benefit of taking such a pragmatic approach.
*
About the author / copyright
Amazon page: http://www.amazon.co.uk/Ian-Gouge/e/B001K85PNI/ref=sr_ntt_srch_lnk_1?qid=1430724789&sr=8-1
Management blog: http://cioscrapbook.blogspot.co.uk
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.
No comments:
Post a Comment