Tuesday, 25 November 2014

The Illusion of Agile - Are You Truly Agile?

Do you work in a truly agile organisation or is it just your department, or maybe only your immediate project that is displaying agile tendencies? If you answer with either of the latter two options then you are probably nowhere near as agile as you think you are and you are almost certainly nowhere near as agile as you would like to be or have the potential to be.

I first got involved with agile development back in the mid/late 1990s. Those were the days before the Agile Manifesto (2001) and I don’t even remember using the word agile back then (except in a non-IT context).  Back then we called it Rapid Application Development, and my exposure to this type of development was through the Dynamic Systems Development Method (DSDM). But for the purposes of this post I'll use the term agile for convenience.
At that time the organisation I was working for was at something of a crossroads. Our application portfolio for credit management systems had been unassailable in market leadership term in both functionality and quality. But competitors were beginning to snap at our heels, and the user interface was starting to look jaded, and execution performance and speeds were lagging. And even more importantly the overall architecture of the portfolio was creaking so badly that many more changes would be likely to cause fractures and breaks.
Microsoft was in the final throws of releasing the first 64-bit version of Windows and object and component engineering methods had now stabilised to such an extent that they could realistically be used in a commercial environment. After some careful consideration we decided to redesign and rewrite the entire portfolio to align to the 64-bit platform, and take full advantage of OO and CBD techniques. We also made the decision to move to a rapid application development environment.

I had been put on point to define the method and processes for the new development and was then tasked to act as the project manager for an initial pilot. I was helped considerably by an external consultant who was a leading expert in this field and who was working for our tool supplier at the time. We adapted DSDM and integrated the OO and CBD into an overall development framework and took a small group of senior developers with us on the journey. We also made sure that we had the support and backing of our key business managers, and the whole team was trained appropriately according to their roles.

To cut a potentially long story short, we were not Agile. Although we successfully reduced the lead time for our pilot project from several months to three weeks, we then had something of a set-back. I had to take a couple of critical weeks off work after an accident.  During these two weeks, ourinitial timebox, the lead developer moved the goalposts by deciding to trash all the code libraries and components we had purchased and rewrite them in-house from scratch. On my return, the project was in meltdown - not a single line of code had been written to meet the business requirements, and the estimated time to complete the library code was now twice as long as we had scheduled for the entire project. It was immediately clear that I was going to be the fall guy for this cock-up so I fell on my sword and quit before I could be axed (I already felt like I'd been stabbed in the back!).

[As an aside, I put my hand up to being part of the problem as well as part of the solution. This was the first large change project I'd had responsibility for, and I knew little (nothing?) about proper process management or management of change (and nor did any of my managers and leaders!). Clearly not everyone was on board, perhaps the reasons for the change were not suitably articulated or communicated, and perhaps some people felt left out of the process, despite trying to make it as inclusive as possible. I felt abandonned and pretty hard done by at the time - but the lessons I learned were invaluable, and it turned out to be the start of a whole new direction for my career!]

At the start of the last paragraph I stated we were not Agile. We had an illusion of agility. We had an agile method and some agile tools. We most clearly did not have a shared vision of what agile meant to us, and we absolutely did not have a shared agile mindset. In hindsight I am fairly certain that the pilot would have failed even if we'd stuck to the original plan and used the bought in code and components. People had embraced the idea of doing things faster, but they didn't recognise that by doing things faster, certain other behaviours had to be left behind. For developers it was writing home grown code for everything (and being in complete control), for managers it was the comfort of status meetings and status reports and dictating the work to be done(and being in complete control), and for business owners it was the ability to be removed from the day to day development work (and having to take responsibility and accountability for making decisions on the spot).

With the power of hindsight I'm sure that sooner or later the pilot project would have got caught up in corporate bureacracy - like mandatory training, overtime bans, re-organisations, office moves and the like, because it was only a small group of people who were going agile. And there's the rub. No matter how agile you are, or even your team may be - there are likely to be a whole bunch of people who are still caught up in the bad old ways of command and control, and they will almost certainly put a spanner in your agile world. There might even be some people within your team who don't really get it, and you'll have to find ways to deal with them - but that's a matter for another post.

So, next time you ask yourself whether you are truly agile, think very carefully. Agile is different things to different people, but it is not a method or a set of tools or even a group of people who are trained in agile concepts and methods. Agile is about doing things differently, and the only way you can do things differently and succeed is by having everyone on board and on the same page. If there is a single group that impacts on your work who isn't bought into what you are trying to achieve then I don't believe that you can even begin to consider yourself truly agile.

Print this post

1 comment:

  1. Yes..it have lot of benefit.In agile model, we have an option for add requirement during project development compared to other model.In weekly or monthly,client must interact with project team.you have a more database.i would like to say Stakeholder-plus is an extensively analyzed and developed software application to handle bulk volume of data with added features to communicate for key projects.Stakeholder-plus is wonderful Management tool which is a valuable investment with key drivers for an organization which support for 24 hours to meet the corporate goals.