Development of World Cup software shows success of balancing Agility and Discipline
by Prof Barry Dwolatzky
Since my visit to the FIFA World Cup “IT Control Centre” (ITCC) last week [see elsewhere on this blog], I’ve thought a lot about the effectiveness of Agile Software Development.
Nine years ago (Feb 2001) a group of prominent software engineers came together and issued the now famous “Agile Manifesto”. In the Manifesto they said that they had “come to value
- individuals and interactions over process and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan.”
They stressed that while they saw “value in the items on the right, they valued items on the left more.”
In 2007 the Indian IT company, Mahindra Satyam, were appointed to develop an Event Management System (EMS) for the 2010 FIFA World Cup. Their challenge in developing this web-based system from scratch was that the customer (i.e. FIFA and its event company, Match) did not have stable and clearly articulated requirements. Satyam decided to adopt an agile development approach.
It is interesting to relate the little I know about the development of the FIFA EMS to the values listed in the Agile Manifesto:
- Let us start with the 4th item in the Manifesto – “responding to change over following a plan”. Given the lack of stable requirements and the nature of the system being developed this made a great deal of sense. After all, what information would a “plan” be based on? As requirements changed the development team would need to re-plan. In fact Mahindra Satyam developed the system in very short 2-week iterations. After each iteration the system could be demonstrated and the next iteration planned.
- The 3rd item in the Manifesto – “customer collaboration over contract negotiation” – certainly seems to have applied to this project. The system was developed in close collaboration with the customer (FIFA and Match) and the technology partners MTN and Telkom. There certainly seems to have been strong collaboration and interaction.
- I’m not able to judge how much items 1 and 2 in the Manifesto were applied, but I certainly get the sense from my brief discussion with senior Mahindra Satyam staff that process and tools were not heavily emphasised and that there was a strong focus on delivering working software rather than documentation.
My conclusion therefore is that the EMS was developed using an agile development approach. It was also clear that the project was a success. As the World Cup draws to a close we have certainly not heard any negative reports about the IT systems at the heart of managing this huge event.
The EMS is therefore a living example of a very successful agile development project.
But wait … what do I know about Mahindra Satyam? In 2008, when it was still called Satyam, I led a delegation of software engineers on a study tour to India. One of the highlights of the trip was a visit to a Satyam “Delivery Centre” in Bangalore. From top to bottom we witnessed a strong belief in process maturity. Satyam is a CMMI maturity level 5 company. Other process models such as ISO 9000, People CMM, ITIL and others were also followed.
With this in mind it is clear to me that the success of the FIFA EMS is due both to the mature process culture at Mahindra Satyam and the ability to apply an agile approach when appropriate. There is an interesting book called “Balancing Agility and Discipline” by Barry Boehm and Richard Turner (Addison Wesley, 2004). There is also a technical report called “CMMI or Agile: Why not embrace both!” by Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandra Shrum ( available at www.sei.cmu.edu/reports/08tn003.pdf) Both of these publications stress the importance of using Agile and Process, rather than choosing one or the other.
Take a moment to re-read the last sentence in the Agile Manifesto:
“while there is value in the items on the right, we value items on the left more.”
The drafters of the Manifesto obviously also saw the need for balance.
I believe that the FIFA EMS demonstrates the success of this “balanced” approach rather than simply attributing it to Agile. This is a crucial message to South African software developers who place a great deal of emphasis on Agile Development – yes Agile is good, but discipline and process are also important.
Process is good once people embrace it. But there’s also a danger of working fo the process instead of making a process work for you. Some companies when implementing process they focus too much on the principles more than what they would like to achieve with the process. As a result too much time is spent trying to follow the process and less time on the actual software development.
Sometimes it does add value to spend more time on the process as this might improve the quality.
Do you agree Prof?
I find it hard to believe that FIFA and MATCH could not clearly articulate their requirements. Did they not do this 4 years ago, (and 4 years before that and …)? I bet that any IT person experienced in transactional systems would be able to come up with at least 90% of the final product requirements.
In my experience the 4th item in the Manifesto is used frequently to impose a pure agile approach. I fear that the “value in the items on the right” is understated in the manifesto, as it comes across as “uncool”.
A perfectly developed application that delivers functionally all that it should, is of no use to the end-user if they cannot access it.
All of the good development practices were destroyed when end-users (ticket sales reps for over the counter sales and online-ticket-seekers) could not get access to the application. As part of the development process a proper performance test should have been performed. A good application performance management tool should also have been used to monitor the application and fix issues as they arise. The system were down for days, which implies that they had little insight into why the application were not performing.
In my opinion, an agile process should include flexibility into the following areas EQUALLY.
–Functionality (The changing requirements of what the system should do)
–Architecture (does the architecture that it will be hosted on still make sense with the new functionality? This should include both the hardware/OS and decisions like application tiers, middleware etc.)
–Performance (Will this application still perform when we add the new functionality, and is the code of good enough quality to do this?)
KR
Anton