In the last six months, my team has undergone some very radical changes and has turned into a full blown Agile team. I'm very happy with our success and I consider this team to be the shining example in our company, at the moment.

Now, in keeping with the tradition of this team in changing at least one thing every few weeks, we are about to embark on a new journey in our project management processes: Lean Software Development.

Starting at 1pm, Central Time, today, my team will be kicking off the following processes:

• Kanban
• Release Per Feature
• Just In Time Retrospectives

I am going to be posting a series of entries on each of these specific items over the next few weeks, and will most likely keep this post updated as the index of entries for a while. So stay tuned for a whirlwind of opinionated posts on our next great experiment!

Table Of Contents For Adventures In Lean

Here are the articles that I have written or am writing for my Adventures In Lean series:

1. Kanban - Pulling Value From The Supplier - In this post, I am laying the foundation of what Kanban is along with a couple of other important terms that I will be using throughout the series
2. We're Going Kanban - Learning To Pull Value Through Our Development Process
3. Release Per Feature - Delivering Value As Soon As Possible
4. Just In Time Retrospectives - Fixing Problems As Problems Occur

There are likely to be other articles added to this list as well. Please check back now and then to see what has been added!

There's been a lot of recent talk about what is "done" in the Lean / Agile development communities, and the primary focus of these discussions has been focused on individual features or stories and the need to get them completely "done" (dev, test, acceptance test, documentation, delivered to customer) before they can be considered done. I wholeheartedly agree with this philosophy, to the point where I active introduce painful elements of software development to my team members, because the work must be done before we can deliver to the customer.

All that being said - I think we're missing out on some potential benefit by not applying "done" at various and different levels of our software development projects. For example, the concept of "done" can be applied to an iteration. What constitutes an iteration being "done"? It's certainly not just the time-box of 2 weeks, 1 month, or whatever our iteration length is defined as. However, that time box is still important. We don't want arbitrary lengths of iterations.

So how do we know when an iteration is completely "done" versus just being over? My initial thoughts revolve around a pass/fail checklist, similar to the swim lanes (or kanban board, if you want to call it that) that our stories go through. At this point, I would likely include the following:

• Iteration length passed
• All stories in iteration "done"
• Code reviewed (possibly part of story being "done")
• Software is in a stable, working state
• Software acceptance tested by customer (or customer representative / SME)
• Retrospective held

There's probably some additional items to include here - this is just my initial idea list.

Like the user story "done" criteria, an iteration cannot be considered "done" until all of the items in this list have been checked off. We don't give partial credit for a story making it to "in test", when there are 2 more columns to move through - the story is not done until it's completely "done". The same should apply to the iteration.

Why bother making an official "done" list for iterations? For the same simple reason we do this for user stories - transparency and visibility into bottlenecks and problems. It's easy for a team to ignore problems like broken software at the end of an iteration - "oh, it's just XYZ... i'll take care of that tomorrow" - when we don't have the same accountability as we do in our stories. By making the iteration a pass/fail set, we expose those problems for the world to see. This exposure is a great motivational tool - who wants to be caught with an un-"done" iteration because of a "simple" bug?

Do you and your team have an iteration "done" list? Do you even have a user story "done" list? It's all about exposing weakness and waste, then eliminating it and creating the official iteration "done" list is just one more step along the path. Don't stop there. What other processes - higher or lower level - can we standardize and improve?

In addition to our 'Code Review Challenge' that I discussed recently, we have been using another retrospective game - 'Name That Standard'.

The idea is fairly simple. At the beginning of any retrospective, we go around the room and ask each team member to list out a standard that we are using in our project. This can be any standard that anyone feels the team is using or needs to be using, including coding conventions, architectural patterns, business and project management processes, communication means, etc. The intention is similar to the intent of 'The Code Review Challenge' - socialization of the the system. Only in this case, we are applying the term 'the system' at a much higher level - our organizational and project management / implementation system as a whole.

Some thoughts on running 'Name That Standard':

• Require not only naming of the standard, but accurate description of the standard and an example of where it is used. Alternatively, you may want to list a brief description out on a projector or whiteboard and see who can name the standard being described.
  
• Encourage the team to think about the team as a whole, not just their area of responsibility.
  
• Encourage the team to list standards that they don't understand, so that the rest of the team can chime in with assistance and help the team member in question grow
  
• Don't just let people yell out standards. go around the room, one person at a time. we got a little chaotic at first, and it was hard to know who said what.
  
• Encourage people to ask questions like 'i thought we were using this standard, but i saw someone else doing that standard'
  
• Encourage the standards to become more and more low level and detailed, over time (over multiple iterations)
  
• Encourage the standards to evolve and change for the better, over time (over multiple iterations)

In our implementations of this game, we've managed to get a fairly good list of standards written down and also resolved some questions on what standards we actually are using. For example, we had 3 dynamic mocking frameworks in our code base - Rhino Mocks, Moq, and a home grown one that we lovingly called 'BrandoMocks' (named for our team member, Brandon, who wrote it for fun one night). The end result of that discussion was to throw out Moq and BrandoMocks, adopting Rhino Mocks as our standard for this project.

Having done 'Name That Standard' in two consecutive iteration retrospectives, I think I can say that it has been very successful. The team as a whole is becoming more and more aware of the standards that we are using, and the individual members are beginning to contribute more and more to the standards.

With each passing iteration, and each new technique for creating collective ownership and socializing the system, I see the team coming together and really forming a team vs. a bunch of individual developers working on the same system.