Evergreen Work
There is a concept in Agile of ‘evergreen’ work – work that the team owns and which should be picked up after committed stories have been completed. A characteristic of this work is that it tends not to be time-sensitive, can often be viewed as team ‘overhead’ and has no Customer Value (i.e. the PO wouldn’t prioritize it). We’ve been doing some of this anyway – mostly as Dev tasks that are thrown in occasionally, or if someone just ‘does’ something – automation through Redgate recently as an example. A problem with having this work done in such an ad hoc manner is that
- The work is hidden from everyone
- It doesn’t get done in priority order
- Larger efforts that would impact more than one person – i.e, refactoring that would required Dev and QA – don’t get done
- Larger projects – such as creating a robust Test Framework that Cobra Kaj did last month as part of ART – would / have never got done
After discussing this concept today, we came up with a small process to manage these tasks/projects. Having a defined process allows us to track and improve the process over time, and to be ‘conscious’ of what we are doing.
- A backlog would be built out, with ideas coming from the Retrospectives, or Suggestion box
- Grooming/refinement of the Backlog would occur periodically – mostly during the Retrospectives, as part of the ‘Continuous Improvement Action Items’ a team might set for itself.
- Where appropriate, champions or owners would be ‘assigned’
- The team would manage the backlog through a paper card wall in the Team Room. As a result, this work would continue to hidden to most – but would be highly visible to the team itself.
- This work is never managed by ‘iteration’ – it just gets done when it gets done.
- Occasionally work would be identified that crossed the rather fuzzy line between Evergreen and designated work. At that point proper cards would be produced in our tracking system, and the Business would assign the priority so that the work could be picked up formally as Commitments within the iteration.
There may be another category of work – e.g: deployment script building, bug triage etc which forms another type of overhead on the team. I’m not sure right now whether we care about formalizing the process more around those. I want to see how the team gets on with this new concept of Evergreens first.
Important but not Urgent
Last week we again discussed the idea of evergreens. After some stubbling around as i tried to convey what I meant, one of the team members encapsulated my various ramblings as “ahhhh!…you mean ‘Important, but not Urgent’!”. Yes indeed – that is exactly what I mean!.
We are now reviewing what if any, evergreens were worked on during the week at the rtro, and have organized a prioritized list of projects that qualify. Our current list looks like this:
- Upgrading the development environment to Visual Studio 2012
- Moving the QA environment into a different domain
- …
