I first learnt about Agile when I attended a Code Retreat at UCL(University College London) whereby we were put in pairs to practice Extreme Programming using TDD (Test-Driven Development). The retreat was code-oriented in nature and although it helped us understand the importance of working in pairs while practicing TDD it didn’t reflect the concept of Agile in a detailed way. It was mainly focused on the Testing part of the Agile process. However, the Lego XP Game event held at King’s College London, organized by the Graduate Developer Community and ran by ThoughtWorks, really pushed beyond the surface and helped me understand how Agile works in both principle and practice.
To avoid going the Wikipedia-style of providing you with a boring definition of Agile, I’m going to instead run you through the Lego XP Game event which at the end should give you a pretty good image of what Agile is all about.
The Lego XP Game event started with an arrangement of groups of six to seven people which acted as Agile teams. We were around five groups in the room. Each group had a ThoughtWorks employee who acted as a client for that group. Then we were introduced to some of the Agile concepts and the different stages that take place in an Agile methodology. The challenge was to build a bird for the client using Lego. As part of the game, we were initially given a large set of Lego figures which would later be used to build our lame bird. The game consisted of three iterations. Each iteration consisted of five steps:
- Task Evaluation,
- Task Allocation,
- and Retrospection.
In each step we had around three minutes except for the developmet phase where we had around five minutes. When an iteration would start, the client would give as a set of tasks, or commonly known as stories, such as: Build the head of the bird, Give the bird wings, Give the bird 4 legs, etc. Each task had a business value from 100 – 500 with 500 being the highest value. The first step of each iteration was to evaluate the task in terms of its difficulty with a ranking score of 1, 2 or 3, with 3 being the most difficult to build. In the first iteration, we started evaluating the tasks given by the client, by giving each task a score from 1 to 3. Once that was done, we moved to our second stage of task allocation and prioritization where we had to decide which task to do and in what priority, according to their given score and business value. Once that step was completed we would give back the tasks that weren’t selected and proceeded to the next phase, that of development. I would say that this phase was the most exciting part of the whole iteration and also the one where we made most of the fundamental mistakes. We didn’t pay much attention to the client who was sitting there all the time, watching us as we scrambled all the Lego figures, and wondering “why the hell aren’t they communicating with me! They’re doing it all wrong.”.
Of course, we couldn’t read the client’s mind until we demonstrated the work of the first iteration to the client and recieved a lot of negative feedback. In the retrospection phase we discussed about the things that we did and the things that we didn’t do. Then we analyzed our actions and discussed on ways to improve them in the next iteration. During this time we also learnt that communication with the client is key to a successful Agile team. Another important factor in a successful Agile team is task allocation among team members. If tasks are not clearly assigned to each team member then problems will arise during the development phase and eventually will lead to deploying a product that is half-finished or is completely out of sync with the client’s requirements in the first place. In our next iterations we basically improved upon the forementioned factors and had a continous difficult time with our client as she was a little bit confusing at times in the sense that she didn’t know what she really wanted us to do. She would ask us to build part B and later would say that she meant part A. Therefore, another issue to bare in mind here is that the client doesn’t always know what she wants, as the picture below depicts:
Agile is increasingly getting adopted in many small software houses and big corporations alike. It is as such an approach to software development. It can be compared to other sofware development methodologies like the Waterfall model, Spiral Model, RUP (Rational Unified Process), etc. For instance, in the Waterfall model, you would go through the following stages in a linear sequence: Analysis, Design, Implementation, Testing, Deployment, and Maintenance. This model is effective when requirements are stable, the technology is well known, and almost everything is deterministic. Although, this may sound very good to your ears, it is very hard to find a project that comes with those characteristics. On the other hand, Agile is a rapid and incremental delivery of software. A project that is processed using Agile will evolve consistently with the client’s requirements. Agile focuses a lot on business value, software quality, simplicity, collaboration, feedback, commitment, and visibility. By building on these values one allows the requirements and design to evolve as the project evolves, can increase the ability to respond to changing business priorities and dependencies, and ultimately lead to better control of quality and work loads. This is probably much better explained in the Agile manifesto which goes like the following:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, while there is a value in the items on the right, we value the items on the left more.”
In a real world Agile project, you would expect the following phases: Planning, Design, Test, Code, and Release. These phases would be repeated in many iterations.
In planning, usually the client defines and provides the requirements for the project in the form of stories. The XP team assigns a cost to each story. Then in the Design phase the team defines an implementation guidance for the stories and continously designs and refactors the software by improving its internal structure while keeping the external behaviour intact. The next step would usually be the actual software implementation which is preceeded by first defining a set of test cases for the required functionalities. Hence, a TDD(Test-Driven development) approach. In the testing phase, the XP team would define Unit tests before any code is written. The tests are then run to ensure that our software fails, which prompts the developer to fix those fails through actual coding. The tests are re-run until they are passed and the whole cycle repeats again. At the very end of each iteration a working piece of software is released to the client. The client can then run some specificed acceptance tests which focus on the overall system features and functionality that are visible and reviewable by the client. Here’s a picture that encapsulates the Agile XP process:
I would like to thank the Graduate Developer Community and ThoughtWorks for organizing this fantastic event. If you live in London and you are a passionate developer then you should definitely follow the GDC and attend their meetups. You will have the chance to talk with some of the brightest minds in technology in London, and learn about some of the best Open Source technologies. Hope that by reading this article on Agile XP you will have a decent understanding of what Agile is all about.
You’re welcome to comment and ask any questions you may have.