Recently I was at one of CIO Connect’s workshops. We run these under the Chatham House rule, so I’m not going to betray any confidences. The discussion was about pace and agility and we had three very good speakers.
Working at pace and being agile from an IT perspective is nothing new. Indeed it dates back to the era before the introduction of formal methodologies and before ERP. Those latter things were, in some respects, a reaction – perhaps over reaction – to the way things were done back then.
I was working alongside people at their desk in the mid 80’s (a very “agile” approach) when PCs were the new exciting thing. As a mainframe person this was new and different for me and for my business colleagues too, and there were a few wrong turns. However, with my position inside IT, and yet outside of the mainframe development teams I had a freedom to work differently. Using what were innovative tools at the time but now seem very old fashioned, plus making the case to the mainframe technical people to release the full power of the 3270 emulators to download data not just act like a dumb terminal, we created systems which joined data together in ways never before done. It was an iterative process, and it developed rapidly until we were ready to use it for real. As the dealerships became aware that we were linking warranty information with spare parts orders, the volumes or warranty orders reduced dramatically and we saved many times the cost of the PCs and the development time.
It’s a long time ago, and IT has forgotten some of those things. They were swept away as a consequence of high profile failures. The time had come to define the right way to do things, and it was formal. I felt at the time that the consultancies who were selling in big, complex methodologies, and the training that went with them were trying to level the playing field in their favour – in-house IT had an inherent advantage – agility and understanding of the business. However the trade off could be poor quality. The pendulum swung too far towards formality and “quality”, and producing massive documents which we pretended were “deliverables” just switched everybody off – technical people hated writing them, users didn’t really read them, but had to sign them off before the next phase would being, thus starting a new cycle of misunderstandings and frustrations between IT and the business.
The next cycle resulted – ERP systems and packaged software generally came about because of frustration with that slow formal approach – what we call “waterfall” these days. Today standardised processes no longer fit a customer centric world, and so the perspective is changing again. One comment made in the workshop was “I won’t risk my business by using waterfall methods.”
Life goes through cycles. Pace and agility are the new watch words. Melded with quality and delivered through reliable core systems, auditable data and processes, this is an exciting way for IT to become responsive to fast changing business needed.
But we’ve been here before.