In part one of Going Agile,I talked about how we introduced Agile to our development team. This next post will look at the events that led to our first iteration planning meeting.

During the weeks that led up to Iteration 1, there was much work that went on as a team, and much that each team member did individually. As the Product Owner, my biggest task was to create a backlog. Sure, I knew what the main new features were going to be, but I still needed to capture this, and add other oft-requested features. I scoured every correspondence I had with customers, sales, support, development, and so on to gather this information.

After everything was said and done, I had a pretty massive backlog… a pretty massive, unprioritized backlog. At this point, I really didn’t know any good techniques for backlog prioritization (that would change after attending the CPO training with Mountain Goat Software). This training was not going to happen for a few months, but something needed to be done… so I did what any good Product Manager does…I used the ‘wet finger in the air’ technique. Now, my ‘estimations’ were based on a number of concrete data points and some not-so-concrete assumptions and anecdotal evidence, so they weren’t totally of the ‘wild-assed guess’ ilk. After a few more days I had my backlog read for the team.

While the backlog creation was going on, a number of team meetings were occurring. Two of the more important meetings involved creating rules for the team and preparing our definition of “Done” . I highly recommend spending some time up front on both of these activities.

Creating the team rules was a great exercise, because it was the first time the team sat down as a collective and decided what the rules would be. Many of the rules were not groundbreaking…things such as everyone’s opinion is equal, treat everyone with respect, don’t be late for meetings, and when and where daily Scrums were going to happen.

The best result from this meeting centered on the team’s communication methods. Everyone was already using email, so that was covered. Instant messaging was rolled out to the team, and everyone was to use it. Of course face-to-face discussions were encouraged the most, but there needed to be some way to let people know you didn’t want to be disturbed (unless something was urgent). Everyone created a Do Not Disturb sign, and when it was posted, it was to be respected. Sometimes people just need to focus on the task at hand, rather than constantly being disrupted. We came out of that meeting with a clear set of easy-to-understand team rules, and we posted these rules in our team conference room for all to see. Note… rules can and will change over time.

Next was coming up with our definition of Done. The team sat down for a couple of hours to determine what should/should not be included. Looking back, we thought we were cavaliers and were blazing new trails with the definition we came up with…in reality, we put together a definition that was pretty much in line with the ‘industry norm’. One thing that we did not include initially was code reviews…that is, for a story to be considered done, the code had to be reviewed by at least one other developer (who was not associated with that piece of code). During our Iteration 1 retrospective, we modified our definition of Done, and code reviews became part of it. In fact, this definition of Done may go through many, ahem, iterations before becoming finalized.

Finally, we needed to get our ‘room’ set up and have all the necessary supplies on hand. Our team decided to use a wall board with color-coded cards for the tasks. Green cards were for development tasks, red cards were bugs, blue cards were for testing tasks, and yellow cards were for documentation tasks. Now we just needed a board to pin these tasks to. We didn’t want to spend a small fortune on a big pin-board, so we got creative and used carpet under padding. (You can get a huge piece of this at any DIY store for next to nothing and it works like a charm.) We fastened it to the wall, put on some masking tape borders and labels, and we had ourselves a Scrum board.

So with our prioritized backlog, team rules, definition of Done, and Scrum room all set, we were now armed and dangerous, and ready for our first iteration planning meeting…TO BE CONTINUED.

The first instalment in my ‘Going Agile’ series will reflect on the earliest days that led up to our development team becoming an Agile development team. Before I get into this too deep, I should first set the stage a little. This organization is a medium sized ($500M in revenue) software company, with no other teams using Agile techniques. We were going to be the first. The product was well established, having been on the market for about 5 years, and traditional development methods were fairly effective from a delivery and quality perspective. The team comprised of about 12 members, which included all developers, testers, documentation, the Scrum Master, and myself as the Product Owner.

The first meeting ever held with the whole team was intended to introduce Agile (Scrum) to them and get their buy in…we did not want to ram it down their throats and say we are doing this. At the time we were doing this, the concept of an Agile Coach was pretty much non-existent, so we were on our own. Our Scrum Master had been on some training, and thought for this meeting it would be good to try an exercise with the team to illustrate how Agile could work. So without any preamble or mention of Agile, everyone in the room was instructed to pick a partner, and then the goal of the exercise was explained. The goal was to navigate your team member around the room as many times as possible in 1 minute. Seemed pretty easy, until we told them about the twist…the team member that was walking around the room was to be blind folded. To add to the fun, our Scrum Master played the role of a roadblock, stepping in front of the blind folded people as they tried to circle the room, requiring new instructions to be shouted out to navigate around him. Once the clock started the chaos broke out, as 6 different people were simultaneously shouting out instructions trying to navigate their team member around the room, and around the roadblock. By the end of the 60 seconds we tallied total trips around the room, and came up with a number in the 30’s.

The 2^nd part of the exercise was quite a bit simpler, and merely had all team members walk around the room (no blind folds), and make their own decisions to navigate around the room and the ‘roadblock’. I’m sure you can imagine how much calmer the room was, and by the end of the 60 seconds we again tallied our results. This time we were well over 120.

So what was the purpose of this exercise, and how did it relate to Agile? Basically it illustrated the power of a self-managing team, and how the productivity of such a team can be magnitudes better when team members are given the ability to make decisions on their own, in real-time. After the exercise, we then introduced the idea of the team adopting Agile, what it is, how it could work, etc. In my opinion, doing this exercise first (and doing it without ever mentioning the term Agile) did more than a week’s worth of powerpoint sessions on why Agile is the way to go. The team was very receptive to the idea (at least most members, more on that in another blog), which set the stage for a series of follow on meetings to further flesh out what was really involved, and what needed to be done to prepare for our first Iteration. The next instalment in this series will delve into that preparation.

After attending Agile 2009 in Chicago, and speaking with so many people about their experiences with Agile, I thought it might be an interesting opportunity for me to do the same. So with that as my inspiration, I’ll be putting together a blog series that will cover a number of topics ranging from introducing Agile to your team, through to the release, with a number of other interesting subjects in between.

The series is in no way an attempt to tell you how to do things, but rather is intended to share experiences that I have had…perhaps you will read them and say to yourself, “I’m glad we’re not the only ones who went through that!”

The series kicks off next week discussing our team’s early days with Agile. This will introduce you to some of the key players in the team, how Agile was introduced internally, the training we went through, and so on. Other topics I have planned for this series include the 1^st Sprint preparation and planning, Retrospectives, team communication, developer issues/concerns, and finally the product Release.

Hopefully these blogs will strike a familiar note with you or give you something new to think about. In the meantime, if you have a particular topic you would like to see discussed, feel free to email me at todd.landry@klocwork.com, or find me on Twitter at http://twitter.com/todd_landry.

Agile Product Management and a lively talk about modern software development by Alistair Cockburn were the themes of the day. The day started off with a hotel breakfast buffet at 6:30. One thing I rarely miss when I travel is a good breakfast to start the day.

My speaking opportunity was, um, unique. Basically a bunch of stages set up around all the food. Oh, and also starting at 7:45 AM. I was able to rush through my presentation and still answer a few questions.

Next was the keynote speaker, Alistair Cockburn. He arrived in dramatic fashion with a bag pipe player leading him onto to the stage, then quickly started reciting a famous passage from Shakespeare’s Julius Ceasar, changing key words from the original play to a more “Agile” flavour. Quite entertaining really. He then proceeded to talk about the main pillars of Agile, interjecting personal experiences and anecdotes. Everyone seemed quite engaged with his talk and gave him a great ovation when he was finished.

We attended the Product Manager/Product Owner Dilemma session presented by Rich Mironov. Very entertaining presenter who identified the key differences between Product Owners and Product Managers. Key takeaways for me were 1) that the overlap between the Agile community and Product Management was very small; 2) Agile development is a big part of business agility; and 3) the Product Owner role adds 40-60% more work than the traditional PM role. Overall a good presentation that concluded with a spirited Q&A discussion.

Watch for our Day 3 summary tomorrow. Be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

Good start to the Agile 2009 show… seems bigger than last year and well organized so far.

Interesting, we’re seeing lots of people from safety-critical shops – medical devices, telecom, military & aerospace, etc. Anecdotally seems like a big change from last year. Todd attended an Agile in safety critical talk that was a good general overview of why Agile is better than traditional development methods for these shops, but lacked specifics on how, why, etc. There’s an FDA & Agile presentation later in the week which will present an actual medical device case study – that should offer more specifics on how to reconcile the process-heavy, documentation-centric approach to a typical regulated environment with Agile.

We also attended Effective Code Reviews in Agile Teams.  Good overview from the Spartez team.  Originally thought this might be vendor specific (Mark’s blog also touched on this) as Spartez does lots of work for Atlassian Crucible but overall it was a good overview even though all the demos were with Crucible.  Despite that, they kept it vendor neutral and described the challenges of adopting code reviews and the keys to success. They reviewed a bunch of common code review misconceptions and pitfalls.  Namely that people see this as a frantic bug hunt and that it will find all bugs in your code.  Also many developers see this as a “big brother” tool where metrics including every comment will be tracked. For managers, they warned not to expect a clear picture that code reviews have saved you x amount of time.  Well that would be nice. ;)  In terms of how this fits in an Agile context there is definitely one clear message, everyone can join/review/invite/modify a code review.  It’s all about the team (of course!) and about learning, not blaming. They see code reviews not as a tool-centric activity but basically a way to enhance communication or emphasize individuals and interactions, to use an Agile Manifesto term.

Be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

The exhibit hall was also quite busy, lots of good discussions with attendees.