Karmængine

So. Recently we’ve tried to make some changes to the way in which our team implements scrum. They came out as a result of a) me learning from the yahoo group and reading plenty of documentation on scrum, and primarily due to b) the scrum master getting certified by attending some CSM training.

We were managing quite well with our interpretation of Scrum, but as it turns out, if we weren’t following all the principals, we weren’t doing Scrum.

Here’s what we changed, and why:

1. Retrospectives. They had essentially halted for the last few sprints, and in any case were not conducted correctly. In the past, we would gather around on Friday, feeling either angry with the P.O. (me) because developers were working into the AM to finish the sprint, or, developers would turn up full of jokes, laziness, and pats-on-backs for getting all the work done on time.

We would sit and chat. The SM tried to instill a sense of order into the meeting, he would ask specific questions and take notes. But in the end, it was really just a relaxing little unwind session and we didn’t get a lot out of it. It did give the developers a chance to throttle the P.O., however, and they did so, shouting abuse about changing requirements and unplanned tasks being added to the sprint.

Two things were wrong with this scenario. Firslty, it is the team itself who should be committing to delivering a certain bunch of stories, not the P.O. ‘telling’ the team what to do. A BIG difference.

Secondly, there’s a purpose to these meetings, and it’s not just to discuss where to go for beer after work.

So, we’ve prepared ourselves for proper retrospective meetings, following guidelines generally accepted by the Scrum world, and expect a result from the meeting. We’ve also altered the mindset of the team to put them in the driving seat, in terms of selecting how much work can be achieved during the sprint.

As for unplanned tasks – well, there are no unplanned tasks. They should be discussed if neccessary and something should be kicked out of sprint if required. The team should be deciding this, based on the P.O. providing updated information of priority.

2. Empowering the developer during preparation meetings. The main point here is – the developers, together with the tester, enter into a kind of ‘contract’ with the P.O., to declare which stories will be delivered at the end of the sprint. This is the way it should work. We were doing it the other way, with the P.O. forcing the developers to commit to a number of tasks, and it should be said, it was usually a long list of tasks.

3. Estimating using story points. Story points – what are they? Why do we need them? The developers were eager to try something new but had a difficult time wrapping their heads around the idea of not estimating in terms of hours but in terms of story points. I used to calculate the amount of hours the team can work during the sprint, get the team to estimate the hours to complete each task, and then say ‘right, this is how much work you’ll get done’, and the sprint backlog was born.

Now, I am just creating stories with user test cases in the backlog and giving them importance factors. The Team is estimating story points based on average stories, and then giving an overall, but confident ‘feel’ (after a lot of technical discussion) about which stories can be in a shippable state by the end of the sprint. Then the stories are added.

4. Adding an ‘Is done when’ field to Trac. We use Trac, or, since new changes were implemented, Agilo, which is built on Trac. The only real acceptance tests we used to have is a ‘How to demo’ field, which would give instruction on how the work done in the ticket can be shown to other people. This was not right at all. Development without testing is like tossing seeds off a cliff and hoping your grandkids will have a fruit tree. No testing = no result.

I’ve added the ‘Is done when’ concept which I’m sure some of you probably use. It’s an english language description of acceptance tests for example, a value of this field could be “An adminstrator can log in, navigate to the accounts page, select a user account, and delete it by clicking on the ‘delete account’ button.” So far this field has had a big impact, as the introduction of any user-level test descriptions should.

5. Visualizing the sprint with a pinboard. We used to be entirely Trac based, meaning developers had to log in, and swim around in Trac to understand clearly what was going on during the sprint. Stand-up meetings didn’t help.

To combat this I have introduced a pinboard into the meeting room, where stories and tasks are pinned on, and moved between statuses before ending up in the ‘closed’ column. This lets the developers see very quickly how much work is left, how much needs to be tested, and generally how on-target the sprint is.

I’ve also put a ‘bug board’ up, which should be empty but never is. Here, developers see bugs which I want fixed immediately. They can discuss them after the stand-up meeting, and come back to me if they think they won’t manage to complete them as well as the sprint stories.

6. Devoted time specifically for bug fixing. We have also given developers a day each to spend on fixing bugs. Roughly thirty hours for the sprint. By setting aside this time, I hope that broken tickets and new bugs will not survive in the backlog long.

With all these changes I feel we’re more ‘Scrumlike’ and I’m hoping this means a better product delivery.