scrum: early reflections and iterations

Production / Wednesday, February 4th, 2015

No process is perfect, and it is the producer’s role to find out what works for her or his team and modify the process (or overhaul it) to help the team best.  We implemented the Agile methodology Scrum a couple of weeks ago, and I’ve already found things that I’ve done wrong and things that just did not click with my team.

In preparing my presentation on implementing Scrum in my team for Chuck Hoover’s Production and Leadership class yesterday, I found myself reflecting on the changes I’ve made to Scrum to better fit my team since we started.  Here are three of them:

1) Evolution of Scrum board

When I first set up the Scrum board there was a row at the bottom labelled “Other/Personal” for team members’ personal tasks such as elective homework or personal projects.  Other producers had told me that they didn’t mind having their teammates put personal tasks on the Scrum board so they know what takes up their time.  However, I felt that my teammates would focus on putting things up that weren’t project related, and moving them through the Scrum board during daily Scrum.  This led to clutter on the Scrum board and wasted teammates’ time during daily Scrum as these tasks contained information that others did not need to know.  There were also fewer hours allocated to project tasks.

Setting the “only project tasks go on the Scrum board” rule has been much more effective for team accountability and progress.  Now, our Scrum board is a clear representation of project progress without the excess clutter, teammates remain professional and only discuss project tasks during daily Scrum, and no one’s time is wasted.  Also (maybe psychologically so), more tasks are being written and more hours are being allocated to project work.

2) Scrum tasks as deliverables

In the early days of Scrum, we were lenient with our task writing.  It was common to see tasks like “research related games” and “design constellations game”.  Although these were important tasks, they did not specify a deliverable, so when marked as done, there was no way to hold the team member accountable or to see and critique his or her progress.

Now, we are working at putting in tasks with specific deliverables on them, such as “research 20 related games and present findings to team in a document” or “provide design document with constellations game details”.  Although these make our tasks on those tiny sticky notes lengthier, I think it’s important so we can follow up with team members and hold each other accountable for what we say we are going to do.  It can be tough to find and specify a deliverable for each task, but we are working on it.

3) Retrospectives and sprint planning

I’d done one retrospective and was unsure about how to measure our progress at solving the problems that arose.  Chuck mentioned doing this at future retrospectives so I will try that.  In addition, my team was more likely to put sticky notes up about good and bad things than the solutions, so we’re going to have to do more thoughtful reflections or change the format next week to ensure that the retrospective is not just a reflection and that it can be used to help improve our process.

Sprint planning was difficult the first time as well, since none of us were sure about our capabilities as individuals or a team.  Hour estimates were all over the place, but I feel this could get better with practice.  Additionally, it was tougher than I expected to come up with tasks for user stories.  A strategy that I found to work better than asking “what tasks can you think of to do for this user story?” and each person writing their own task down, is to ask the question “what tasks need to get done to make this user story come true?” and writing down all the tasks, then assigning them to team members.  This can help ensure that fewer surprise tasks appear mid-sprint, which was a problem we encountered.  To help combat our problem that too few hours were pulled for each person, I think ensuring each teammate has a certain number of hours in tasks for the sprint (such as 20+) would be useful.

My presentation on setting up Scrum for my team and what I’ve learned from it can be found below.

20150203_Assn2Agile_0120150203_Assn2Agile_02 20150203_Assn2Agile_03 20150203_Assn2Agile_04 20150203_Assn2Agile_05 20150203_Assn2Agile_06 20150203_Assn2Agile_07 20150203_Assn2Agile_08 20150203_Assn2Agile_09 20150203_Assn2Agile_10 20150203_Assn2Agile_1120150203_Assn2Agile_12 20150203_Assn2Agile_13 20150203_Assn2Agile_14 20150203_Assn2Agile_15 20150203_Assn2Agile_16 20150203_Assn2Agile_17 20150203_Assn2Agile_18 20150203_Assn2Agile_19 20150203_Assn2Agile_20 20150203_Assn2Agile_21