The First Month
It’s been 1 month since I started the new job. In the spirit of Improve your scrum implementation in one week, I thought I’d reflect on what I think I have achieved in my first month. Did I take any of my own advice? Read on to find out 🙂
I didn’t do much in week one, except observe. I was very conscious of coming in as the new broom and changing everything. I was aware I might throw out some of the good stuff they already had in place if I did. I wanted to first understand what they had, and only then make changes.
I spent some time chatting to a few people one on one to get their point of view on things. I tried very hard (and wasn’t always successful) not to share my opinions too early. I didn’t want to influence what I was observing. I did make lots of notes and lists. I noted down all the things I though could be potential improvements. I knew that I wouldn’t implement everything immediately, and that after a while I would lose that fresh perspective I had in week one. So I made an idea backlog, and jotted down anything I though might be a good idea.
I also tried to see where the pain points were. What were the things that needed addressing first, and what could wait. Conscious that people only have so much capacity for change I had to make sure I changed only necessary things initially, and things that would help the teams, not things that annoyed me.
There were a lot of changes happening in the company already, which were outside of my control. A large number of contracts were coming to an end which mean the teams would reshuffle, a major release was due out 2 weeks after I started, and a new support process needed to exist given that the current support team were all people who’s contracts were ending. Also the ScrumMaster and chief architect had resigned and were leaving within 2 weeks.
I dealt with the necessary change first. Here are the major areas I tackled in the first month.
Team composition and size
No one was certain what was happening after 28 July when the release went out and teams changed. I tackled that first. The idea had been to scale down to 2 teams, however when I looked at the number of people I felt 3 teams would be a better fit to keep the teams smaller (5 or 6 people each). This also required the least amount of change from the previous teams only 4 people changed teams. Also with the chief architect leaving, we took a decision to have the other architects join the teams rather than working outside the teams, this would ensure that they had a better idea of what was changing on the product on a day to day basis.
The team released a version 2 weeks after I started. This was a great opportunity to do a release retrospective, and an opportunity for me to see how they all felt about their current process. I booked a 4 hour slot the day after the release. The session went really well, people had an opportunity to vent, and came up with some really good ways they could improve. It was great to see a team conscious of what their problems are, just needing a little support to push back to the business to give them the space to do things properly. At the end of the four hours we had a list of 8 things they were going to do in the next sprint. 3 were tasks that they would do, and 5 were different ways of working.
One of the mayor pain points that came out in the retrospective was a ‘hardening’ phase they did at the end of each release, which was essentially a time to fix bugs that got deferred during the normal sprints. The feeling from the team was loud and clear that they knew this was wrong. So we adopted a principle: We would ban the phrase “Let’s move it to hardening”. We would fix bugs when they were found or agree they would never be fixed. The story would not be done if there was a bug outstanding, even if the bug wasn’t related to that story. Interestingly, just having the team know there would be no hardening anymore made them more careful about quality each sprint.
Definition of Done
The Product Owner had previously combined the acceptance criteria for the story (when the Product Owner would consider it done) and the definition of done (when the team would consider it done). This made the definition of done something the Product Owner controlled. We agreed to change this. The PO should not be concerned with the process the team use to write software. So we had a one hour session with all the teams and brainstormed a definition of done. It includes ensuring FIT tests are created for any new functionality, code is checked in and all tests are passing on ci, feature has been reviewed by the PO, code has been reviewed, documentation is updated, all bugs found are fixed. Each team has this on their boards, and when a story is done, we go through the definition of done line by line to confirm everyone agrees it was all done.
Story Point Burndowns and one story at a time
Another change was to introduce story point burndowns. We did these in conjunction with the task burndowns to see what people preferred. We also focused on finishing one story before starting the next. Just making this conscious choice meant that things that usually all waited until the last day for the sprint like PO review and documentation updates, happened much earlier. In fact most of the documentation was updated before the coding was done, since the documentation was the interface specification. Needless to say the documenter is delighted:) He used to always be the last person working, and often missed the next sprint’s planning meeting because he was finishing off last minute doc changes.
Fixing the heartbeat
Previously the teams had run 15 working day sprints. This usually amounted to 3 weeks, but if there was a public holiday, then the sprint boundary day moved. Also because there were 5 teams, the sprints were staggered as the POs couldn’t do planning with all the teams on one day. The problem with this is that nobody ever knew when there sprint ended. I think we are conditioned to think about schedules by day of the week, not durations. Do you go to gym every 2nd day, or do you go on Mon, Wed and Fri? My preference is to fix the start day of the sprint, and if there is a public holiday, the sprint is one day shorter. It really doesn’t impact velocity anymore than people being sick during the sprint, so over 3 sprints it averages out.
I decided to end sprints on Monday’s, and start new sprints on Tuesdays. On Monday’s we do a sprint review with the business, and a retrospective, and on Tuesday’s we do sprint planning for all the teams. Because we now have only 3 teams we can do planning in one day. Also the team decided to try 2 week sprints so that they would have more opportunity to inspect and adapt if things were going wrong in a release. Every 2nd Tuesday which is not sprint planning, we do a backlog grooming session with the whole team.
Support process and JIRA cleanout
I also assessed the support situation and current defects. I spent alot of time understanding how to configure JIRA (and what was possible), the current frustrations of the business around support, and the cycle time and number of defects in the queue. I put together a simplified process and ran the business stakeholders through it, and got their input. We also agreed to have a nominated developer from each team on support at any one time, rather than forming a separate support team. Next we setup a Kanban board for support to deal with the tickets. Then I had to rationalise the number of tickets we had. There were over 600 tickets in various queues in JIRA. So I applied a few bulk rules.
- If it had been open for more than 6 months I closed it as won’t fix.
- If it was a minor or trivial issue I closed it as won’t fix.
- If it was linked to another issue I closed it as duplicate.
- If it was assigned to the person who opened it because it couldn’t be reproduced I closed it and asked them to reopen if they could reproduce it.
I closed more than 70% of our issues in this way, and none of them have been reopened but customers yet.
I sensed a certain amount of apathy and lack of motivation in some of the team members, probably from being pushed a little to hard. So I sent my boss the Dan Pink video on motivation, and got agreement to run a Fedex day once per release. We had our first one after the July release. The coolest demo was one of the guys who had written something to call our application from his Android phone. I think the idea was a great success, and we will be doing more in the future.
Finally I realised the need for a learning culture. I setup 1 hour learning sessions on a Friday afternoon. It’s a time most people aren’t too focused anyway, so it’s a good time to do something different. I setup a schedule on the wiki for people to sign up for topics. Our first session was given by one of the developers on how Hudson works. I gave the second session on estimation techniques. When I went to check the schedule to sign up for another session on the benefits of limiting work in progress, I had to take a slot in October, because all the rest were filled up!
So how did I do against my own list:
- Fix your heartbeat – done and even reduced the sprint length to 2 weeks 🙂
- Define Done – done and being enforced daily
- Cleanup your task board – not necessary, the teams were already pretty good about this. I did buy them vinyl table and neon post-it notes so their boards can be a bit prettier.
- Make your backlog visible – not done, this still needs some work. I have alot of work to do with the business stakeholders and Product Owners. Fortunately the Product Owners are very keen to learn. In hindsight I realise this can be a difficult area to address.
- Plan to learn – done, learning sessions in place and going well so far. Plus I’ve started sharing articles with the team on relevant topics.
So 4 out of 5 is not bad.