Agile LCBRU
Tags: Project Management Category
Starting in January 2014, the LCBRU informatics team set out to become agile.
Task board, sprints, meetings, etc
We have set up a task board in the office, and will use scrum in three-week cycles of development, or 'sprints'.
Each sprint begins with a Sprint Planning Meeting, on the Monday that starts the sprint, to review the overall project backlog and agree stories and tasks to be brought into the sprint backlog. This meeting will be in two parts: firstly prioritising the backlog (a morning discussion to which key end users will be invited), and secondly estimating effort and agreeing the plan for the sprint (which will be just the four technical team people).
The user stories or requirements will be broken down into tasks - each task will be represented on the task board by a post-it note, and in the trac system by a ticket. Each sprint will be entered as a milestone in the trac system, so the tickets can be sorted by milestone, to get a record of which tasks were attempted in each sprint.
Each day during the sprint we will have a fifteen minute stand-up meeting, in the office, in front of the task board. We will review the progress since the previous day, each of us will report on our progress, on our plan for the day, and on any obstacles in our way. We will volunteer to pick up tasks, and begin to move them from 'To Do' to 'Done'.
At the conclusion of the sprint, on the Friday afternoon, two meetings will take place: a Sprint Review to review the work done / not done, and demonstrate new functionality to end users, and a Sprint Retrospective (with the technical team only) to review the sprint and agree any process improvements for subsequent sprints.
To help track progress during each sprint, the tasks will be checked against a 'burndown chart' showing for each day in the sprint how many tasks remain uncompleted. We are using a simplified burndown chart for the time being.
Following the first sprint, we have added two other visualisations on the main whiteboard in the office. One is a pain chart to list annoyances and blockages which we don't fix immediately. When they trigger repeated entries in the pain chart, we prioritise resolving them. The other is an improvement board where we list improvements in our own processes that we wish to make, and track implementation of the improvements.
The first sprint begins on Monday 27th January 2014. It will conclude on Friday 14th February 2014. The task list for the first sprint is available by doing a search of the trac ticket list, or just clicking this link: http://lcbru-trac.rcs.le.ac.uk/query?group=status&milestone=Sprint+1
25 tasks included in the sprint: 15 done, 10 not done. 95 units effort estimate: 56 completed, 39 not completed.
The second sprint begins on Tuesday 18th February and concludes on Friday 7th March.
24 tasks included in the sprint. 144.5 units effort estimate.
Resources
- Agile glossary: http://www.solutionsiq.com/resources/agile-glossary/
- Mountain Goat: http://www.mountaingoatsoftware.com/agile
- Agile Tools - Tom Perry's blog: http://agiletools.wordpress.com/
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
