If you put a key in the lock and it doesn’t turn easily then it’s probably the wrong key or the lock is bust. If you’re running an Agile software development team and it’s not going smoothly then in some way you’re probably not Agile, because Agile is easy.
Take the steps:
- Sit down with some business folk and based on their vision and strategy decide on some tactical stuff to do with software.
- Write the tactical stuff down in simple terminology that anyone can understand, kinda like a story. Call it a “Story“.
- Get together with a group of analytical people who like pizza and coke, to break the Story down into a series of actionable tasks. Call them “Tasks” and attach them in some kind of obvious way to the Story that spawned them.
- Put the Story and tasks into a list. Anything in the list that is not scheduled to be tackled in the next work cycle should be marked as being in a status “Backlog“.
- Work with the business to identify which of the Stories (and accompanying tasks) should get done first, while being mindful that you only want to work in short spells to get things built quickly, in case there were any misunderstandings or omissions in the stated requirements. Be smart in this process and know that some things will depend on other things being done first, or they in turn can’t be done.
- Make sure that the list of things you are going to do has some visible deliverable. If the business users can’t see what they’re going to get they can’t tell the development team if it’s not what they wanted. There is always a gap between what was wanted and what was asked for, Agile is about recognising, minimising and bridging this gap.
- Mark the Stories and tasks that you plan to do in the next available time slot as being in a status that is no longer the backlog. You’re going to try to get through this subset of the backlog quickly so use a status called “Sprint”. Before you start, group the list of Stories and Tasks together, give them a common tracking identifier called a Sprint Id, and call this grouped list of impending work the Roadmap.
- The team (one or more) start working their way through the Sprint tasks. You can track their progress through the Roadmap using either a Burndown or a Burnup chart. Take your pick, the Internet is chock full of samples of these charts and any half-decent Agile tracking tool will have them built in.
- Meet daily with the business folk to share:
- What you did yesterday (take completed items by Sprint off the Roadmap and put them on an identically structured list called the Changelog. The Roadmap and Changelog differ only in that one represents work you are doing or will do and the other is work you’ve done). By examining past Changelogs you can calculate your team’s Velocity – the rate at which you typically close out tasks.
- What you’re doing today/to the end of the Sprint – the remainder of the Roadmap.
- What blockers have been encountered/anticipated. Don’t file these, fix them!
- If necessary, accept changes as your development process brings enlightenment to all concerned. Nobody’s perfect, nobody has the gift of foresight.
- When you’re done building and testing, show the business folk what the team have built for them and ask if that was what they wanted. Don’t cry if (when) they say “no”, just plan to bridge the gap in the next work cycle.
- Before you start the next cycle get everyone together to identify if there are ways you could improve, based on what you learnt in the previous cycle. This is called a Sprint Retrospective.
- Repeat from point 1 because you know things now that you didn’t know when you started and as a result you may have things that are outstanding, out-of-scope, newly introduced, of different priority etc.
If this isn’t going easily for you then you should stop, get everyone together, go through this really simple list or something like it, and work out why you’re trying to jam the wrong key in the lock.