Saturday, October 30, 2010

Real World Agile - Week Two - The Retrospective

In my last post, I wrote about our first week of using Agile planning and delivery techniques to better deliver value to our customers quicker. I mentioned a few of the things we started doing, a few we chose to forgo and where we met successes and challenges. One of the key disciplines that we did this iteration that we didn't do last time was the retrospective.

The retrospective is the time the team spends examining the last iteration, release or project to find what is working well, what are areas of improvement. The retrospective exposes strengths and weakness in the team's processes, interpersonal dynamics, technologies and out of it comes a continuous improvement plan. This week was my first official retrospective and in the spirit of retrospectives, I thought I'd do a retrospective on the retrospective.

The Process
Before I dive in to the specifics of our retrospective, I want to share the process that I'm trying to follow for our meetings. Much of the process comes Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

It's actually a very simple progression:
  1. Set the stage
  2. Gather data
  3. Analyze the data
  4. Decide what to do
  5. Close the retrospective
This is how brains are wired to make decisions, so it makes sense that the meeting would be structured this way. However, I found that it isn't quite as easy as it looks. We're problem solvers and we want to jump right into solving and deciding without the thorough data gathering and analysis needed.

This is where the book is really helpful for me. At least half the book is dedicated to activities a retrospective leader can use in each portion of the retrospective. The activities provide focus and keep the meeting both on topic and progressing toward its desired end. This is not easy to do and it is both an art and a skill. I'm hoping to improve as a leader the more I practice - having ideas and inspiration helps.

Our Focus
Since we had just come from Agile training, I wanted to focus on getting better at what we had learned and find the areas where we could reinforce our strengths and improve on our weaknesses. I was surprised at how well this set our agenda and direction for the coming weeks and led to some concrete improvement experiments which are already paying off.

Setting the Stage
In a retrospective, it's important to get everyone engaged early as the input of all team members is vital for success. This is particularly challenging for us as we have a member of the team, Erwin, who is not co-located and must participate via web conferencing.

After introducing the meeting's focus and going over the agenda, I asked each team member to share their thoughts from the Agile training or, for Erwin, his thoughts on our first iteration. This led to a frank discussion of the training which was valuable for me, especially since their experiences were much different than mine. We spent about ten minutes on this activity.

Gathering the Data
Once we finished the stage setting exercise, it was time to move into data gathering. It is counterintuitive, but most of the meeting is spent in the data gathering and analysis portions. Since our focus was our implementation of Agile, I had the team list every Agile practice they could think of. This seemed like a fairly non-threatening activity that allowed us to throw a bunch of terms and phrases on the board and also pull out what things most "stuck" from our training. This took five or ten minutes before we ran out of things to add.

Areas of Improvement:
  • I should have limited the activity to five minutes and time-boxed it. This keeps things moving along and helps compel people to contribute because of artificial urgency.
  • I should introduce each activity and its purpose. Team members need to know why they are doing something and what the intended outcome is.
This activity was foundational for the next one, which was to vote on those terms on the board (actually a list in a Word document we were sharing online) that were most important to focus on for the week. Everyone had four votes to use as they desired - four on everything, one spread across four items or any combination they wanted. My goal was to identify those areas most important to the team and begin to narrow down where our improvement would be focused for the week.

I placed asterisks next to each item a person voted for until we had all voted. We now had several ideas with one or more vote. Looking at the list we noticed that we had about five items with two or more votes, so we decided to take those as our focal areas. This activity took about five minutes.

Areas of Improvement:
  • Ideally I would use sticky dots on a flip chart or marker on a board, but having a remote member makes this challenging. The phone works but it would be better to find creative ways of engaging everyone.
Analyzing the Data
Now we had some data to look at and I wanted to go deeper so that we could find which area would give us the most value as a focus of improvement. We took our five items and put them on the board in a radar graph which looked like the spokes of a wheel. I asked each team member rate the items from zero to ten in two areas: how are we doing in this area and how important is this area to our success for the coming week. Everyone placed a green dot on the spokes for the former and a red dot on the latter. Obviously, Erwin couldn't do this, so he put a colored number next to each item in the shared Word document. This took about five minutes.

Looking at the board, it was clear that two areas were most prominent: communication and defining "done done". I asked the team which item we should focus on first and we all agreed that communication should be first. I then moved on to my next activity which was designed to give us improvement actions for the next iteration. This was a rookie mistake.

Areas of Improvement:
  • I used the radar graph to move us into the decision-making activity. This kept the meeting moving toward its intended conclusion, but missed an opportunity to go deeper on the topic of communication. I should have spent time asking questions about why communication was most prominent, where were we falling short and communication techniques were working. This would have been useful in exposing healthy or harmful team dynamics, areas where the team felt we were lacking and given us a much stronger improvement plan.
  • Be sure to take time to go deep and really analyze the data. There is a healthy balance between keeping the meeting moving and making it truly valuable. Don't sacrifice the latter for the former.
Deciding What To Do
The next activity was a brainstorming activity. I liked this one because I could easily time box it, it could be done individually and out of it we could gather an actionable list of items. I set a few ground rules (aim for quantity, don't filter, don't judge, be wild and creative), gave everyone ten minutes and told them to write as many ideas about communication as they could. Ten minutes seemed long, but I wanted to give people time to think and write (or type).

At the end of the ten minutes I gathered up all the ideas on a shared spreadsheet so we could look at them and begin filtering. I didn't anticipate how difficult it would be to come up with filters, but the team did a great job coming up with a few such as: provides value to team and is no (or little) work (e.g. simple to implement).

It was difficult to filter our list but in the end after a discussion we came up with four things we could do this week to improve communication: use IM (we're mostly an email shop), look into better co-location of team members, a weekly informal lunch and end-of-day check-outs. After two days, I can say we've implemented two of the four (IM and check-outs) and it has definitely improved communication. This activity took about twenty minutes.

Areas of Improvement
  • The brainstorming and filtering activity needed to be better focused. Introduce what we're doing, why we're doing and what we hope to get out of it
  • Brainstorming activities need to be focused. I should have said "brainstorm ways we can improve communication". It was implicit, but should have been explicit
Closing the Retrospective
Closing is important. It allows the team to commit to the decisions made, celebrate accomplishments and do a mini-retrospective on the retrospective. That last item was very important for me. I am fortunate to have members on the team candid enough to let me know what can be improved and some of the notes above came out of those comments.

Retrospectives are hard. They are hard to do well and hard work for the participants. For a first go I felt this went very well, but there are obviously areas of improvement to be made. I think practice and feedback will improve the retrospectives as we continue to do them. This applies both to me as a leader and participants. The real value of the retrospective, however, isn't in the meeting itself but the results it achieves. I'm looking forward to the continuous improvement that comes out of this regular meeting.

Saturday, October 23, 2010

Real World Agile - Week One

Two weeks ago, I had the privilege to participate in an Agile Planning and Delivery training with James Shore and Diana Larsen. This week we had the chance to put that training into practice. While the training was very hands-on and interactive (we actually did four iterations and built working software the last three days), it was also in an artificial environment. In the real world, things didn't quite fit into the neat patterns we practiced in class. Here's I present what we did, what we didn't do, what worked and what needs improvement after week one.

TL;DR Version
  • Task Board and Test Driven Development (TDD) are Very Good Things.
  • Software tracking tools, not as useful as a rolling white board and post-it notes.
  • Early practice shows promise and we'll continue to build on what we've learned.

Our Early Attempts

There's a lot more to Agile than the ceremonies and tools - or maybe a lot less. In the past we focused on story planning, iterations and a software tool to help us keep track of what was going on, but all we were really doing was cramming a waterfall methodology into one week sprints. Needless to say, that didn't work. We didn't gain much from daily stand up meetings, putting all the stories, tasks and estimations into a tracking tool or having a scrum master. We still ended up trying to cram too much scope into too little time with the added complexity of a new methodology run by an inexperienced coach. It could have gone better.

What We Did This Time

Fewer Stories So Could Confidently Commit
One of the key points that I brought away from our training was to deliver value with each story. Even if the value is small, it's still an incremental gain for our customers. Rather than plan a project up front and stuff all the stories into iterations several weeks into the future, plan the week's stories and only commit what can actually get done.

That last point is worth reiterating - only commit to what can actually get done. Completing stories energizes the team and gives us a real sense of accomplishment toward our end goal. We had previously guessed wrongly and over-committed and got farther and farther behind with our stories. This week, we took a look at all the possible stories, prioritized them and only committed to a handful (no more than 6-10 is a good rule). The rest went into the backlog.

What we knew intuitively, but failed to account for in our previous attempts was a buffer for technical debt, regular support and maintenance of other software and administrative overhead (meetings, email, interruptions, etc.). This time we left plenty of buffer and committed to paying down technical debt if there was buffer time we could use.

Test Driven Development (TDD)
I had previously advocated Test Driven Development to the team, but it was new, seemingly complicated and I wasn't very good at it myself. I was familiar with the concept and had done it myself, but didn't do a good job at explaining the technique or the value to the team. Luckily the training spent a fair amount of time on this concept with real-world examples and practice. And as fortune would have it, this week an excellent online meetup, "Test Driven Development Demystified", occurred and we could all listen in to help reinforce our learning. With that baseline established, we are committing to TDD as a regular practice for our coding.

One challenge we face with TDD is that we have piles of legacy code. We chose not to try to do any retro-testing of legacy code, but rather write unit tests for all new code and test old code as we end up working with it. Part of paying down our technical debt will be refactoring old code with tests, but only as the system and time demands. Our rule is "make the code better than it was before". Small improvements add up and eventually we will be fully covered.

What We Didn't Do
We are committing to one day a week (we chose Wednesday) as our demonstration, retrospective and planning day but since we only had three days before base-lining our iteration schedule we chose to skip the demonstrations this week. Next week will be a different story.

For the same reasons we didn't do any demonstrations, we skipped a formal retrospective. Instead, we chose to talk about what we learned in the training and commit to a few key concepts (TDD and story planing being the most prominent). We also used this time to estimate stories and add stories them to our task board.

Use a Software Tracking Tool
Speaking of a task board, we chose to skip a software tracking tool for our iteration planning and use sticky notes and a rolling white board instead. The board is visible to everyone in a communal area and it's very nice to interact with something tangible for planning and doing stories and tasks. The board did eventually get translated into the software tool, but that is only because we have a developer who isn't co-located and we need a way of sharing the task board across time zones.

What Worked

The Task Board
Of all the things that are really working this week, the physical task board has to be the winner. Prominently displayed stories and tasks (completed and in progress) is a great reminder of what we're working on and what we got accomplished. Planning using the board was also much nicer as we could move stories around in priority order and drop them into the iteration much quicker than fumbling with a software tool. This is definitely a keeper and I'm actually excited about planning next week's stories.

Daily Stand Ups

We went back to a five minute stand up - one minute per team member. We can check in, get a level set for the day and move into planning and clearing road blocks immediately afterward. We are using Scrum's "did, doing, impediments, confidence" questions which is working for us. When it becomes tedious or boring, we'll switch it up to something that works for us.

Areas of Improvement

We're all practicing TDD now, but I didn't feel I was able to really get in and write the tests I wanted to for the week. I saw plenty of room for refactoring, but a couple of in-progress stories that had hard deadlines meant I only had time to do some incremental improvements to code, rather than create fully tested objects. That being said, we spent a lot of time learning the process and tools, so it wasn't a failure, just an area for improvement.

Our planning was a bit rushed this week. Impending deadlines and being short-handed due to illness and planned PTO meant we had to crash through our planning session. We were missing our primary product owner since he was at a conference, so we did the best we could with the people we had. Like TDD, not a total failure but I'm confident we will be better next week.

Agile in a classroom and Agile in the real world are two different animals. In the classroom there aren't meetings, email and support calls to take and everything works (almost) according to the book. As a way of building software, it's incredibly useful, but we're going to have to slowly incorporate all the best practices as we're able to absorb them. I would say the first week was a huge success at small improvements - each of which will add up to better efficiency, better code and better value for our customers. It might just take a few months to get there.

Additional Resources
Test Driven Development
  • MXUnit - This is a unit testing framework for ColdFusion. If you do CF, I highly recommend it.
  • James Shore's Let's Play TDD - Jim goes through an actual Java software project from scratch using TDD. You get to see it built up warts and all. It's incredibly useful to see it in action.
  • Test Driven Development Demystified - this online meetup was an excellent one hour presentation on TDD and Katas. Like the Let's Play, a demonstration of TDD happened live (it's now recorded and available).
    Slides and Code
There are a ton of resources on Agile out there. Here are a couple to get you started.
What Do You Think?
Do you have a question or comment about Agile? Have you tried it or are currently doing it? I'd love to hear your experiences and what worked and didn't work for you. I'd also like to know if you have additional resources I should add to my list. Thanks!