Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this? (more…)

Berteig Consulting with the help of some partners is now offering a new service called The Agile Clinic. This is not a typical coaching or training session. The entire clinic has a duration of just one day. During this day there are short 30 or 60 minute appointments made by managers, executives, and staff with two experienced agile coaches. These coaches listen to problems presented to them, consult, discover, facilitate, diagnose, and offer solutions. These appointments are designed to be intense and high-impact sessions. Visit www.agileclinic.com to see how this service can add great value and provide fantastic results to your company with a small time cost.

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses - if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices List (OpenOffice format - 68KB)

I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.

(more…)

There’s a great discussion on the Extreme Programming Yahoo! group where a whole bunch of folks list their blogs out. If you aren’t part of the group, you should probably join it (it focuses on technical practices, and there’s lots of other good agile stuff there too). The discussion starts with a message from James Carr where he asks who else here blogs?

It’s probably still cool to jump in with your own blog link if you have an agile-focused blog (I’m sure Scrum, Lean and other agile methods would be welcome even though it’s an extreme programming list!)

Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.  These Patterns of Agile Adoptions are described as three sets of contrasting options:

1. Start Small vs. Go All In
2. Technical Practices First vs. Iterations First
3. Stealth Mode vs. Public Display

J. B. Rainsberger has written an excellent article about the usefulness of planning velocity (and the places where it is not useful as well). I highly recommend reading it, particularly if you are a manager or a project manager.

This course offers ScrumMaster Certification in Toronto. The training is hands on, interactive and highly effective. By the end of the course participants will receive a professional certification in Agile Software Project Management. The dates of the course are January 16 - 18, 2008.

Click here to sign up!

The complete winter and spring course list is available here.

Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:

Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.

Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.

Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.

Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.

Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.

These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.

What are some of the other benefits of agile?

Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn’s presentation on User Stories… but his book (User Stories Applied : For Agile Software Development) is excellent

The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!’s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.

(more…)