Monday, August 25, 2008

Lean Software Development

While working in London for TrafficBroker I had the opportunity to try out Fred George's Lean process. To date, it's absolutely my favorite way to deliver software.

Stories
Stories truly are placeholders for a conversation. They are short sentences such as "The system should process pending orders when inventory is available". If you want to work on the story you (and your pair) go find the business person who wants the feature and you talk to them until you understand what needs to be built. Once you know what you need to do, you create tasks.

Stories are estimated using the techniques I detailed on InfoQ.

Tasks
Tasks are the technical tasks that need to be completed to finish the story. They are written on a sticky and attached to the story on the wall. When a task is finished you put a green dot on the sticky. At any time you can see what stories are being worked on, how many tasks are associated with the story and how many have been completed so far.

Retrospectives
Even though we never felt like we needed a retrospective we got on a schedule of doing them every two weeks. I walked into every one thinking it was unnecessary, and walked out thinking it was critical that it happened. Great retrospectives really make a world of difference.

We all put stickies on the wall in the "not so well" or "well" columns, then we talk about each one. Everyone gets the opportunity to elaborate on their sticky. The common themes become action items.

Showcases
We also had weekly showcases to demo new functionality for anyone who was interested. In the showcase we also used a burndown chart to show progress. We only estimated the stories that were necessary for the next version or release, so the burndown chart was often a short term picture. Of course, any further detail would be greatly unreliable anyway. The burndown numbers are based on taking the sum of the estimates and applying the velocity, based on a weekly velocity total.

Story Wall
We also used a story wall to track progress. The stories moved from Definition -> Awaiting Development -> In Development -> in QA -> Awaiting Business Acceptance -> Complete. The stories in Awaiting Development are ordered from top down by priority. The business could come over at any time and reorder based on priority.

Waste Removal
I loved the process because we constantly removed waste (effort for zero value items). We didn't need to commit to points per iteration because it didn't gain us anything. We didn't bother tracking actuals, hours, or anything else that wasn't important. We also didn't discuss or estimate anything that wasn't in the next release. We only did what was necessary, and we delivered faster than I've ever delivered before. Every detail is judged by it's ROI.

Conclusion
I'm a huge fan. Context is king and it might not work for you based on your constraints, but it's definitely worth considering some if not all of the ideas.

6 comments:

  1. Anonymous7:25 PM

    I might be missing something obvious here but whilst it does leave me wondering about the value of "iterations". If stories can be introduced into the "awaiting development" column at any time and business owners can re-prioritise them and you try and release as often as possible, then what problem does an iteration solve? Don't they break up what is already a fluid process?

    ReplyDelete
  2. Anonymous7:26 PM

    That should have said: "while this sounds great, it does leave me wondering...".

    ReplyDelete
  3. Anonymous7:46 PM

    @Luke, there really weren't iterations per say, but you tracked points on a weekly basis. That's pretty much all I meant by "iteration".

    Cheers, Jay

    ReplyDelete
  4. Anonymous1:45 PM

    Looks like the normal lean kanban style process to me. I have been doing this for 6 months and much prefer it.

    If you "didn't bother tracking actuals, hours, or anything else" why do you estimate the stories? Or, have I misread the post?

    We've stopped estimating stories and keep delivering every week or two (max).

    ReplyDelete
  5. +1 for lean, Jay. I'm hoping to do a talk about our transition from scrum to a more lean process at the upcoming XP Day conference in London.

    My enthusiasm for lean was actually kick-started by a conversation with Fred at the last XP Day.

    One of the best resources I've found on the web about this stuff is the outstanding blog at
    http://leansoftwareengineering.com/ - highly recommended.

    ReplyDelete
  6. Anonymous12:28 PM

    @Andy, we estimate so that we can provide decent timelines for feature delivery. If your business doesn't require timelines, abandoning estimates sounds like a decent idea.

    Cheers, Jay

    ReplyDelete

Note: Only a member of this blog may post a comment.