With the Soccer World Cup getting into full swing, my current team talk of little else. We have a sweepstake going and I have Poland. The winner will receive £100. Given the level of excitement the team has for the World Cup I decided to tap into that for their retrospective last week. The format worked really well, and the team loved the competition element. If your team is football crazy, try it out with them too. Continue reading “The World Cup Retrospective”
Every now and then every ScrumMaster or Agile Coach meets a team that doesn’t show any of the Scrum values in their day to day interactions. This can be frustrating to the agilist, but to the team it can be psychologically harmful and have a severe impact upon their performance. Taking a lead from professional coaching, I believe that the answer to this problem in the team exists within the team itself. I set to work creating a retrospective that would help this team create a charter that they own and buy into. Continue reading “The Journey to Creating a Team Charter”
I’ve been watching my team for a couple of sprints now, and I’ve generated some questions around how they groom stories. When stories are brought into sprint they are typically between 25% and 50% of the team’s average velocity. The ideal is that every story is around 6% to 10% of the average velocity. The Team and Product Owner have been telling that they cannot be made smaller. I didn’t believe this and so decided to explore a story that the Team claimed to be ready for the next sprint.
When I was a developer, I understood in theory that retrospectives were a good things and were there to help the team improve over time. The thing was, that isn’t how it worked in practice. Our ScrumMaster ran the same retro every time. He would walk in, draw three columns on a flip chart, and labelled them Positive, Negative, and Delta. The team would then sit quietly and write up the same things on stickies that we had written last time. Our ScrumMaster would then quickly read out the good things, let us spend half an hour whinging at each other about the negatives, and finally we would agree to change all the things that we hadn’t changed before. When I decided to become a ScrumMaster, I promised myself that I would never put a team through that.
Our team is comprised primarily of relatively new staters, with all but one being here between four months and four weeks. One developer (let’s call him Jack) has been here much longer and is very familiar with the product. As I’m sure we’ve all seen in this scenario the team has developed a level of reliance upon Jack that was understandable to start with, but needs tackling to avoid problems in the future. Continue reading “Addressing Team Reliance Upon One”
This week is my first week with the team I’m going to be working with for the next few months. I started on the last day of sprint 28, which was also my predecessor’s last day. This week we setup sprint 29 and I broke the golden rule of not changing anything in the first sprint. Continue reading “New Team, New Sprint, Tidier Board”