Lightning talk: Agile Development
Graham Klyne, software designer, programmer and developer from Oxford extols the virtues of agile development
methods from a personal view - and explains why it is just like narrow boating.
I lead a small research group and we undertake a range of academic activity from software to evaluation and publication and dissemination. The starting point for our use of Agile was that, coming from a commercial background and then coming into a university, it seemed to me to be particularly appropriate for an environment where the outcomes are necessarily a bit uncertain.
We bid for a JISC project with the clear intent that it would be Agile. We wanted to apply semantic web technologies to help researchers with their project. From the outset the three of us attended a week-long training course on Agile and that meant that we came out of it with a common view and language and set of ideas. Getting everyone involved in some kind of training is really valuable.
What is Agile?
Agile tends to value individuals and interactions over processes and tools. It also values working software over extensive documentation. It values responding to change over following a plan. From a personal perspective, what we do is user-led and directed by what our users say they want. We spend a lot of time communicating. We value code over comprehensive documentation. We perform development incrementally. We retrospect.
To be user-led we have to have real users as a starting point. It’s far easier to elicit requirements from a real user if you have a working system in place. It’s vital to build trust and respect within a team and it has to be maintained. It’s important to keep the flow of communication going at many levels. Hour by hour we have questions that bounce around the team and also a daily stand up so we understand what each other is doing. A daily stand up is a meeting where we are all required to stand up in order to keep it short. Ours run for about 15 minutes. It forms a natural break in the work. Communication should not just be electronic. Index cards can be more helpful than computer screens sometimes.
Building on a working system - favouring code over documentation - it helps to start with something really simple. If it’s simple and it works you can put it in front of the customer and ask them what they want. Build up in small steps, tiny steps, even though it can be hard as a developer to avoid trying to cram in more and then sort it out. Minimise the periods during the development cycle when you don’t have working code. Small steps mean that you only have short periods when you don’t have a working system.
Retrospection: the one indispensable feature of Agile. Stop, look, review and adjust. It’s a team activity. Over time it becomes automatic and we spend less time changing the way things we do things but we still review what we’ve done.
Test-led development is a practice often associated with Agile and it does have a good relationship but is not necessarily essential. Test cases are very useful for people working on standards. Can cut through an awful lot of sterile debate. Also, if you’re using other people’s software and almost all the code I’ve written is test cases and configuration files and in that scenario test cases are even more important. Also valuable in open source.
Refactoring: it’s easier than you think it might be. Keep the refactoring well separated from the additional functions.
Card planning: lay them on the table for user stories and tasks. Helps everyone to be confident that they are getting their input on the table. Then the process of deciding which is most important goes on. Hard to do in any other way.
Although our progress had not been meteoric, it has been consistent with no backsliding. It’s like narrowboating - you travel very slowly and don’t feel like you’re getting anywhere but by the end of the week you realise that you’re a long way from where you started. Agile also provides that sense of continuous progress.
The whole approach mitigates the risk of failure as you always have something that works even if you don’t achieve all that you set out to achieve.
Example from the floor, Matthew: what worked well in a commercial company I was working for where we practiced extreme coding and used agile principles was: no code ownership (bound by strict rules), test-based development, rules about simplicity, never refactoring until you have to, stand up meetings, whiteboard designs, iterations so could find out when you’d messed something up almost immediately, everything had to have unit tests, there has to be a lot of trust in the system (you have to know that someone is not going to break your code)
Graham: building trust is central.
Paul Walk: what about refactoring
Matthew: I like to keep things as simple as possible - I don’t mean a rubbish hack but reuse as much as you can. Do what you can with the least overhead as possible. Refactoring is much easier to do once you know what you’re doing.
Paul: I don’t have a lot of experience with Agile but I used to do a lot of development, open source etc. Refactoring I used a lot and we would use refactoring for a lot of different purposes. Especially towards the end of the project when realise that hard to document is sensibly for others to reuse so would go back and refactor with the view to make the interface more logical, not so much about redundancy. It varies from development environment to environment. Java developers are always trying to make it reusable and it can be a real impediment to getting the job done - a fear of commitment, starting a job and building a framework and then needing to have it finished in Python! That aspect of refactoring - saying my components are going to be reused by other people - I wonder if that’s simpler with Agile.
Paul: what are we teaching people in university now?
Delegate: When I graduated last year I was still having design patterns drummed into me…
Graham: the emphasis on communication between team members is the fact that skills get passed around much more easily around the group. I learnt a lot from someone in my team who came in with lots of new ideas. In an Agile team those ideas can percolate more easily.
Delegate: is there a problem with coming up with easy code just because it’s expedient to get the job done when it might be better to make that decision at the beginning rather than risk having to go back and refactor?
Graham: trad school of thought is that the longer you leave a design change the more expensive it becomes but the contrary view is that much of the design planning you do upfront is never actually needed and that the cost of going back if necessary is dwarfed by the costs of such extensive upfront planning.