On March 3, 2010, the Federal Bureau of Investigation killed its biggest and most ambitious modernisation project — the one that was supposed to prevent another 9/11 but that had devolved into one of the biggest software debacles of all time. For more than a decade the FBI had been trying to update its computer system, and it looked as if they would fail. Again. And now it was his baby.
In the last few months I made short interviews with employees of large enterprises about their experience using agile in their projects. With the ones who had a bad experience, I dived into a deeper conversation to learn more about it. There were 2 common things they shared in their complaints “We are too corporate to work agile” or “We have business critical applications, agile is risky for us”. I knew neither of them could be the reasons of failure but their projects did really fail and they got back to waterfall, I had to find out why.
Is your company the most corporate enterprise in the world?
First of all I had to convince these people that their claims about being corporate or business critical projects are not the real causes. Let’s take corporate structures first. Bank of America, JP Morgan and Goldman Sachs are only a few examples from the corporate world that use agile for software development projects. They wrote the book of being corporate, with their employees wearing suits even if they are working as the cable guys in the data centre. If they prefer agile and have success with agile, then being a large enterprise with complicated corporate structure can not be the reason of failure.
Do you think your mobile application is more critical than FBI or Department of Defence projects?
Let’s discuss the business critical applications. Can you not use agile practices for business critical applications? Absolutely you can. US Department of Defence started using agile in 2014 and they are pretty happy about it. They say they started producing two times more than they could before. It has been more than 2 years since their kick-off in agile and they still use agile which means non of their defence projects failed because of agile. FBI is yet another example of having business critical operations. The software they use affects lives, and I mean live or die, not lifestyle. It is not even business critical, but it is life critical! They failed in their “large scale” transitioning project for a long time. Then, they achieved success in software projects with agile, why can’t you?
So what are the reasons behind the failure?
Unhappy stakeholder, frustrated scrum team, failure in delivering results, dispute between departments… a total corporate nightmare. After realising the fact that we are not still there to reach the real reasons of failure, now we have to find out why they failed because the failure is real and obvious.
SCRUM is light-weight but not zero-weight
The first thing I realised that they have been taking consultation from inadequate people who doesn’t have enough practical knowledge of SCRUM. SCRUM is light-weight which makes practical experience really matter more. Inexperience brings the lack of self confidence which results in panic in times of trouble. The consultants they have been working on started mixing the corporate processes of the company with SCRUM artifacts and events. The reasoning they make is that SCRUM is flexible and light-weight. However it is not zero-weight, of course there are things that you HAVE TO do to make SCRUM work. If you need continuous work from someone, this person has to be in SCRUM team, has to attend the ceremonies. If you say that you can work with him by mixing waterfall and SCRUM, call it a hybrid and try to implement it in that company then of course you will fail. When I interviewed the consultant about why he worked that way and ruined SCRUM, his answer was “they told me that this person has to work in different projects”. This is not something peculiar and most of the enterprises trying to transition to agile suffers from this. This is why field experience is important for SCRUM implementation. In my short experience of 7 years in implementing SCRUM, I saw that you can have a person work in max 2 different SCRUM teams. So, yes you can have that person work for different projects and let me tell you, this person is usually a designer or a tester. But more than 2 is a physical impossibility because that person has to attend the daily stand-ups, plannings,reviews, grooming sessions… So why did not the consultant offer this? Because he did not face this problem before and the easiest solution to provide was to get along with company’s standards. In the end it is the agile which failed, not him. However in reality, it is the consultant who failed, not agile.
Agile is easy to learn, difficult to implement
I remember the first time I met SCRUM. I learned it from an expert software engineer who worked in UK for several years. After implementing SCRUM for a month with him, I considered myself as an agile expert because it was so easy to learn the rules. However, the more companies I implemented agile, the more problems I faced, I realised that it takes years and many different organisations to have an expertise.
Take away for enterprises who failed in SCRUM , your answer lies in SCRUM;
Retrospective and Inspection
I had a very similar problem with one of my clients. They were implementing SCRUM and happy with it but had minor problems within their processes. They did not blame and leave agile for that but tried to fix it. What we did was exactly what SCRUM suggested, incremental delivery. For months, continuously, we checked what went wrong with the process, found out the reasons behind and made a small correction. Targeting one problem at a time, for example; the lack of communication with designers…
After some time everything was better, but of course not perfect. The take away for me was; you absolutely need
continuous inspection and retrospective within your process and organisation
because the world you compete is dynamic, your organisation is dynamic and most importantly your people are dynamic.
Twitter: Can Hüzmeli
LinkedIn: https://www.linkedin.com/in/canhuzmeli
References
Scrum: The Art of Doing Twice the Work in Half the Time