Succeeding with Agile Development – Part II

In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.

Agile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part II – Fundamentals

Start out simple and iterate; establish the fundamentals of the structure and process and, as each concept solidifies, introduce more sophistication.

Establish a rhythm for the team

1. Decide on a sprint duration based on your appetite for risk. I recommend 2 weeks since most teams are well-equipped to collectively determine what work can be completed in a 2 week period. Remember, the greater your sprint interval, the greater the margin for error.

2. Schedule recurring Sprint Planning, Task Breakdown, Sprint Review and Sprint Retrospective meetings

   1. The Sprint Planning meeting is held on the first day of the sprint and is focused on the team committing to delivering a subset of the prioritized backlog. Invitees should include the cross-functional development team and the Product Owner. Note: If you need to start early to get a jump on the week, bring in bagels or donuts and coffee – your team will thank you! (and they will be more likely to show up on time!)

   2. Task Breakdown should follow Sprint Planning and, done well, can take several hours. Take the time – it will pay off. I like to tell my teams that “even if we spend the first day of the sprint doing nothing more than planning and the last day doing nothing but wrapping up the sprint, the intervening 8 days will be so massively productive it will be worth it”. In fact, most teams find they have completed Task Breakdown by mid afternoon and are starting work on the highest priority stories by the end of the first day.

   3. Schedule a recurring 30 minute Sprint Review where the team demos all completed stories. I recommend inviting as broad an audience as possible to the Sprint Review since it demonstrates momentum and provides a forum for the team to celebrate what they’ve accomplished. Hold the Sprint Review at the same time on the last day of every sprint.

   4. The Sprint Retrospective follows the Sprint Review on the last day of the sprint and is an opportunity for the team to reflect on the prior sprint and identify opportunities for process improvement in the next sprint. It’s important that these meetings are focused on non judgmental idea sharing. I recommend writing down all suggestions in 3 categories: Start, Stop and Continue. Once all ideas are exhausted, have the team vote on the ‘top 3’ they will adopt for the next sprint. Document the Retrospective and review the prior ‘Top 3’ at each Retrospective to see a) if the team followed its own direction and b) if it helped improve the outcome of the sprint.

3. Designate a time for the daily standup meetings. Hold the meetings at the same time every day (ideally at the physical scrum board), keep them to 15 minutes or less and be ruthless in tabling design discussions or tangential conversations. Every member of the team should answer 3 simple questions (remind them that they are updating one another, not the Scrummaster):

   1. What did you work on yesterday?

   2. What are you planning to work on today?

   3. Do you have any impediments? (Note: it’s the Scrummasters responsibility to capture and address impediments to maintain the team’s productivity)

Facilitate collaboration

In order to maximize the performance of your team, make it easy for them to collaborate. Require everyone to be in the office during ‘core hours’ (that is, hours when the entire team is physically in the office and able to collaborate.) I suggest core hours of 9:30am-5:30pm and allow for people to adapt their exact travel around commute hours.

If a team member(s) is offsite, use a Google Hangout or Skype for the Daily Standup so that they can see and be seen.

Define common criteria for ‘done’

Make sure that stories are not moved to ‘done’ unless all the criteria are met. For example:

• Code checked in

• Unit tests checked in and running

• QA tests documented in the test management tool

• QA complete and acceptance criteria met

• Product owner has confirmed that the implementation meets the requirements

Steer for Success

Every Sprint begins with high expectations and, if everything goes to plan, all the stories will be completed on time and life will be wonderful. Of course, that’s not always the case. What’s important is ending the sprint with some subset of the stories ALL the way across the board to ‘Done’. This likely requires some ‘steering’ to accomplish.

Since there are often external forces at play (illness, escalated bugs that have to be fixed, etc.) make sure the teams work on the stories in priority order. As the sprint progresses, begin to query the team if the remaining stories are still on track to be completed. If the team feels strongly that a story needs to be dropped, work with the Product Owner to move the story to the backlog and/or identify a smaller story that can be completed. Strongly discourage the team from opening stories that may not be completed by the end of the sprint. The team’s goal is to deliver a potentially shippable product increment – and incomplete code will compromise this by creating code or QA debt (and associated risk)  that will have to be paid down in a future sprint.

Learn and adapt but stick to the principles

Every team is different. Be willing to listen to and incorporate the team’s ideas and suggestions for improvement that emerge during the Sprint Retrospectives – providing you are not compromising the core principles of the process.

…and most importantly, CELEBRATE often!

Look for opportunities to reinforce the benefits of the process; acknowledge when tasks are moved on the board, celebrate when stories are closed, and send the team home early on the last day of the sprint. After all, if they’ve completed all the committed stories, they are ‘done’ and have nothing to work on…until the next Sprint Planning!