Agile and Scrum from the Trenches – Part 1

I work as a development manager for a nicely sized project team (approx 13 team members, including myself).  To be more precise, I am the Scrum Master for the project.

We have not been using Scrum and Agile for a long time.  We are a little more than a year into our transition from waterfall to agile.

The transitional road has not been without its bumps, twists & bends, and occasional detours, but I think we are on the right track and working our way towards a more agile and productive team.

I plan to write a series of short posts to help myself and hopefully others reflect on our mis-steps and successes.  What worked for us may not necessarily work for you;  Nor to I want to give you the false impression that we are completely agile and following Scrum to the letter, because we have some gaps here and there.  Some gaps we are trying to close, and some gaps I am not sure we will even bother to address.  Our ultimate goal is to become more agile with each iteration, and continually find ways to improve our process, improve our team and the product at the same time.

This is tiny snapshot of where the project was more than a year ago:

  • Requirements (what requirements?) were typically conversations or just an email with some description of what somebody wanted.  This was not necessarily a horrible thing, as it allowed the developers, business analyst and project manager/business owner to be creative and discuss the requirements as we went.  However the lack of documentation did cause problems along the way.
  • Our release schedule was our iteration schedule (a release roughly every 3-4 months or so).  A rough plan was devised at the beginning of a release cycle, most of the time.
  • Status meetings.  The team would meet roughly once a week or so, sometimes less frequent, with the project manager to go over each task status.  A lot of unknowns and large tasks resulted in a lot of “I am still working on it” from week to week.

Currently:

  • We are still on a 3 month release cycle (as required by the business), but we work in 30 day iterations (or Sprints).
  • Status meetings went away and replaced with a more natural quick “team discussion” called a Daily Scrum.  Here is where my team deviates a bit from the Scrum rules:  we answer the required 3 statements/questions 1) What did I do yesterday? (or before the meeting) 2) What do I plan on working on today? (or after the meeting) and 3) What impediments are preventing me from getting my work done?  Instead, each team member still goes through all three items, but more freestyle – just normal talking to the team.  Sometimes they take more time and get deeper in the details (rather than parking lot the discussion), but that is a conscious choice the team made, and it does not seem to be disrupting the flow or speed of the Daily Scrum too much.  As the team does not sit in a single room together, this is one of the way they mediate that and have a quick open discussion.
  • Detailed requirements are being drafted, but as Use Cases.  We will likely start moving towards User Stories and using Story Points for estimating the product backlog.  Our BA attempts to focus on Use Cases a sprint ahead of the team, but this is not always the case, and the team will still work together to understand the requirements as they go.
  • Review meetings:  The team demonstrates functionality and what they worked on during the sprint to our Product Owner.  This is a good place to get additional feedback on the overall direction, vision and change requests of the product from the Product Owner – which would make their way into the Product Backlog.
  • Retrospective meetings: Arguably the most important meeting for the team from a cohesive, self-managing, happy and productive team standpoint.  This meeting has gotten noticeably more important, more detailed and more productive as we go.  The team is starting to notice more items that get in the way of them being productive – and are doing a better job in bringing these items up and discussing them with the team.  We try to tackle as many items, at least one, each sprint so we can always feel like we are changing something for the better – and so that the team feels that they are in control.  These discussions also occur at times during the Daily Scrum or anytime during the sprint.  We bring them back up during the retrospective so we can discuss and document it.  Depending on the item, we may try to address it during our sprint (if it is small enough, and makes sense to address it immediately rather than wait, and does not have a negative impact on what the team already committed to).

Both lists a actually much longer, but it should serve as an idea of the progress we are making.  The short of it is I think the team, and the Product Owner, is starting to see a lot of positives from the transition to be more agile.  The team is much more motivated and happy, and the productivity and product quality is continuously improving over time.  There is a lot of ground left to cover, and it may take us a while to get there, but this was definitely the correct direction to take from the fork in the road.

I will follow up with more stories, and links to useful articles and sites that I found to be helpful.

Leave a Reply

%d bloggers like this: