This past Tuesday at AgileCville we had a series of lightning talks on «Agile for Newbies.»  The meeting went very well, and I’ll provide a brief recap of it here.

Thanks go to RallySoftware, who sponsored the meeting this month and provided pizza, and also provided their Iteration Planning guides as handouts.  Their guides were a perfect freebie for our audience of 29 local IT and business professionals, about half of whom are new to agile methods.

Seven local Agile pros gave an overview of various agile topics in a «lightning talk» format.  Each speaker had 10 minutes, and then a few minutes after that for Q&A.  So it was a pretty fast paced meeting (2 hours total), and we packed a lot of information in.

Here are some of my notes on each lightning talk:

A Newbie’s questions about agile, John Berryman

John was very kind to offer himself as a sacrificial «Newbie» at the beginning of the meeting, and he gave a short talk on why he was interested in Agile, and the various rumors and preconceptions that he has about Agile based on the hype.  He has just recently started some work on a scrum team and loves the pair programming aspects, but still raised many excellent questions.

Agile Processes and Team Roles, Arin Sime

I spoke next, and I tried to provide a foundation for the subsequent lightning talks.  After a quick reminder of why traditional methods fail, I described a typical agile process flow based on the following steps:

1. Backlog preparation
2. Iteration planning
3. Daily Iterations of Test/Develop/Integrate/Commit, and Daily Standups
4. Demo/Review
5. Retrospectives

Next I quickly discussed the differences between two main flavors of Agile:  Scrum and Kanban.  My recommendation is that if your software development can be easily grouped together into releases, then you should look at Scrum first.  If your team is focused more on maintenance issues, or something where «flow» is more important than releases, you should start with Kanban.  But either are excellent methods if you have built a good team and have strong customer input.

How to write good user stories, John Feminella

John then spoke about how to write user stories.  He discussed the «As a .. I want to … so that» format of user stories, and why agile encourages this format of user-focused stories.  John also introduced everyone to the INVEST acronym for traits of a well-written user story (I’ve added in my summaries of each principle, which may not match exactly what John said):

• Independent:  Stories should be independent of one another as much as possible, so that a developer can commit to finishing that story in a single iteration.
• Negotiable:  Stories should not include all of the details, to encourage conversation with the customer.
• Valuable:  The customer needs to care about this, or why are you doing it?
• Estimable:  The story must be small enough and well enough understood to estimate
• Small:  If you can’t complete the story in less than a single iteration, it’s too big.
• Testable:  The story must be specific enough that you can write a test which verifies it.

John also described a number of «smells» of bad user stories, which was very humorous and useful.  Here are some of the smells he discussed which I jotted down:

• Everybody is a «user»
• Your user is really just one loud person
• No one knows what the user really needs
• «Text bomb», where the user story is so long that it won’t fit on a single index card

Agile Estimation/Planning, Simon Cockayne

Simon reinforced the basics of an agile process, and how the estimation and planning process fits in with that flow.  He gave an excellent overview of planning and estimation techniques, including story points and why agile emphasizes relative estimation.

It’s hard for us to estimate things in man-hours and provide any degree of accuracy, but it’s much easier for people to estimate relatively, such as saying «This task is twice as much work as that one.»  Simon also discussed how story points are commonly estimated in Fibonacci sequences (ie 0,1,3,5,8,13,…).  The reason for this is so that we spend our time efficiently when debating estimates.  There’s no value in team members debating if something is 13 or 14 points, since the margin of error in estimation is too high anyways.  However, understanding if a story is 8 or 13 points and fitting it in those buckets is much more meaningful.

Simon also highly recommended the planningpoker.com website and Mike Cohn’s book on Agile Estimation and Planning (also one of my favorite books).

Simon offered many words of wisdom, but one I made particular note of is to «Give customers what they want before they don’t want it anymore.»  Agile helps us to deliver value while it is still valuable to the customer.

When to Pair Program, Seth Liddy

Seth joked that he didn’t realize the AgileCville meeting was this week, and so he had no slides prepared.  But his «off the cuff» discussion of when to pair program was very interesting to the group.  He pair programs all the time and sees tremendous benefits.

Seth noted that teams may initially experience a slight decrease in velocity when starting to pair program, but not very much.  However, your team will definitely gain drastic improvements in quality.

Pair programming is great for sharing knowledge among team members, and prevents the «lottery ticket» problem (when a team member unexpectedly leaves and takes exclusive knowledge with them).  Pairing up also helps the team to reinforce eXtreme Programming (XP) practices such as Test Driven Development and Continuous Integration.  You are less likely to cut corners when pairing with someone and you are both watching each other’s work.

Agile Testing, Steve Donahue

Steve Donahue did a very nice job of describing the role of testing in agile teams.  He referenced Lisa Crispin’s book on «Agile Testing», and highly recommended it.  He emphasized the importance of working in small chunks, and focusing initial automation efforts on your current work in order to keep the effort manageable.

Steve discussed the Agile Testing Quadrants from Lisa’s book, which helps testers to know where to focus their efforts for different testing goals.  He also discussed the different layers of test automation, from Mike Cohn’s blog.  The UI layer is on the top of the pyramid, followed by service tests and then unit tests at the base of the pyramid.  Most time should be spent writing unit tests which cover as much functionality as possible, because these are the easiest tests to write and the least brittle.  Less time should be spent on UI layer testing due to the extra effort and cost involved for tests that are inherently brittle.  Steve recommended only using UI testing for «happy paths.»

Retrospectives, Richard Brewster

Richard brought it all home for us with a discussion of the role and importance of Agile Retrospectives.  Retrospectives are one of the most powerful techniques in agile methods, because they require the team to reflect on both successes and failures, and find ways to adapt and improve their processes and software to continuously improve.

Retrospectives are also one of the most frequently neglected parts of agile processes, perhaps because they can deal with our feelings and team conflicts that people would rather avoid.  And so they are often forgotten.

As if to demonstrate this point, Richard unfortunately did not have much time for Q&A since we were already at 8pm by this point and needed to close up the meeting.  In our tight schedule for the meeting, not enough time was left for the discussion of retrospectives.  Just like most agile teams are so anxious to get into the next iteration that they skip the hour or two necessary for a retrospective!  Richard was a good sport about the time constraints and did a great job anyways.

Richard pointed out that retrospectives are how teams can effectively self-manage, which is a key value of good agile teams.  The retrospective allows you to reflect, figure out how to decide what improvements to make, and also to regularly enforce that you are making the discussed improvements.  A retrospective should be held at the end of every iteration.  Attendance for all team members should be mandatory, and participation in the actual discussion should be encouraged.  Richard also pointed out that for teams to effectively self manage, managers must empower the team to act on the changes they come up with in retrospectives.

Thanks to all who attended and spoke!

In addition to a compelling set of topics and speakers with hands on experience, those who attended also asked a lot of great questions.  Thanks to everyone who attended!  We will make «Agile for Newbies» a regular mainstay of our annual AgileCville calendar.  We will probably also repeat the lightning talk format in future meetings, though perhaps with fewer lightning talks per meeting in order to allow more time for Q&A.

Our next meeting is July 19th, and if you’re not on our mailing list already, check us out at AgileCville.org!