wiki:Agile LCBRU

Version 2 (modified by Nick Holden, 11 years ago) ( diff )

--

Agile LCBRU

Starting in January 2014, the LCBRU informatics team set out to become agile.

How it started…

Nick sent an email...

Hi everyone

Richard and I had a chat this week about our development processes, and we kind of agreed that we wanted to be more agile.

Partly this is something I've had in the back of my mind for a while, but never acted upon. Partly it's the result of reviewing (for my appraisal) the progress we made in 2013 (which was OK, and significant in many areas, but with a massive and still growing backlog of things I've promised people and not yet delivered). And partly it's the result of having attended a very inspiring talk last week from someone who is a project manager who has been practising agile development for several years and is very enthusiastic about the changes it made in their working practices.

If you're not familiar with what agile means in the context of software development, the definitive 'agile manifesto' is pretty brief:

 Manifesto for Agile Software Development

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 interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

That seems to me to pretty accurately sum up how we as the LCBRU technical team want to relate to the researchers, nurses and other colleagues who use our software and data. So becoming agile should fit well into our overall objectives. Although agile was created in software development, people have successfully implemented its culture and processes into other areas of business management. Anywhere there are teams of people working to deliver solutions to problems can probably benefit from being agile.

There are lots of aspects to being agile, but the key things are probably around making ourselves plan collectively for each period of work, with a succession of short (two or three week) development cycles, with achievable objectives set for each one. Currently we are each 'doing our own thing' to a greater or lesser degree, and the things which are a high priority for one of us may not seem so important to other members of the team. And we sometimes tackle things which are 'urgent' more quickly than those which are 'important'. Agile processes might help us to tell the difference between the two.

It's important that we remember that agile development is more about a particular culture than it is about a particular planning tool or process. Becoming agile would involve a number of changes - to how we think, to how we plan work, to how we function together as a team, and to how we relate to the people around us who give us work to do - our 'customers', to be stark about it. Some of those changes will be easy and quick, and very visible (I'm intending to start work today on a 'task board' that we can use as a Big Visual Chart to remind ourselves - and show others - what tasks we are dealing with at any particular time, and how far we've got), other changes might be more subtle and take a while for us to get used to them. Over time, we will change our culture to be 'agile'.

The agile manifesto above, and the 12 principles of agile development are online (of course) at http://agilemanifesto.org/

There are lots of very good websites by agile developers providing resources to learn from. Some of my favourites are:

http://martinfowler.com/agile.html http://www.mountaingoatsoftware.com/agile http://www.scrumalliance.org/ http://guide.agilealliance.org/

The overall intention behind seeking for us to become agile is to become more responsive, better able to implement feature requests and tools that BRU staff need to do their work. Rather than having very long 'plans' which rapidly become out of date, agile uses a short development cycle, setting objectives for a couple of weeks at a time, seeking to deliver on those objectives and then reviewing the needs of the users in order to decide what to prioritise for the next cycle.

One change we will introduce straight away is to have a very brief daily meeting, standing up in the office (so that we are inspired to be brief and focussed) looking at the 'task board'. Each of us will describe the work we've done since the previous day's meeting, the work we plan to do that coming day, and any obstacles that are in our way. The idea being that we can see more easily how each person's work fits into the attempts to meet the objectives, and if there are obstacles, we can more easily recognise where someone else in the team can help out in overcoming them. This should be a big improvement over the three-hour long monthly meetings.

We should meet together soon to discuss this idea of becoming more agile, so we can evaluate which aspects of agile working benefit us the most, and which we might not want to follow. But hopefully we can make the whole thing a positive experience also. I'm absolutely committed to this being a positive experience for all of us, and for the people we work with / near. I know change can be threatening, but an agile methodology is only working properly if people in the team feel valued, motivated and positive about their work.

There's a lot of jargon associated with agile methods - there's quite a good, comprehensive glossary at http://www.solutionsiq.com/resources/agile-glossary/ if you want to have a look.

I'm excited about this, and think it will help us become more effective and more productive. I hope you're excited by it too. If you're not sure about any of it, please ask. We'll probably screw some of it up, and the point isn't to be perfect at agile methodology anyway, the point is to find out if doing things differently helps us to be more productive and have more fun at the same time.

I'll create a new page on the trac site for our 'journey to agile' and we can document our experiences there.

Nick

Note: See TracWiki for help on using the wiki.