Coaching
by Liz Sedley
Recommended Reading
Agile Team Review (part 3)
Slack
If everyone is scheduled to work on high priority tasks 100% of the time the schedule will be very fragile, as the slightest variation will have a knock on effect to everything else.Some slack should be incorporated into the schedule to allow things to run smoothly. This is like a motorway, where everyone can only drive at the speed limit if it is less than 80% full.
There are different ways of introducing slack. It can be that some low priority tasks are scheduled, so that they can be pulled if necessary. Or time to learn, write internal tools, and clean up the code can be scheduled.
A technique which innovative companies like Google have is to schedule an ‘innovation’ day every fortnight or so. I like to have these day between iterations.
Code Reviews
It is good practice to review code when it is checked into source control. These reviews should only take a few minutes, as they should be done frequently. (Code should be checked in most days.)This is a very effective way to improve the code and to promote knowledge sharing. The person doing the review does not need to be a senior developer; these reviews work equally well if the reviewer is junior, as mostly the person presenting their code will spot their own mistakes when they explain it to someone else.
Introducing Test Driven Development
Initially doing TDD will slow development down – although once it is mastered development will be sped up.A good way to introduce it is to start off by doing it in easy situations where you can see how to do it, and then as your skill grows to gradually tackle harder and harder cases. Also do it first on stories which don’t have a close deadline, but where there is enough time to spend a bit longer on it.
The company’s key asset is the code base. Investing in the code base is crucial if you want to be able to continue to maintain the code over the long term.
Iteration Prioritization Meeting
Have a regular iteration prioritization meeting where the product owner can decide what items should and shouldn’t go on the backlog. Everyone who wants something done should come to this meeting and present their case. In this way everyone will understand why decisions have been made, and why some stuff isn’t getting done.Don’t let the backlog get too long. Only contain as many stories as can be completed in two to three months.
Visible Backlog
Making the backlog more visible (on a wall) will help ensure the company doesn’t commit to more work than it can deliver. It will also show why low priority stories never get implemented.As well as keeping the backlog on the wall, email it to stakeholders regularly.
Retrospectives
Retrospectives are a key feature of an Agile team. They are a standard way to improve process. Take action points in these meetings, and schedule them to be actioned in the next iteration.Try to run the meeting differently every time.