Agile Zone is brought to you in partnership with:

Jay Fields is a software developer at DRW Trading. He has a passion for discovering and maturing innovative solutions. His most recent work has been in the Domain Specific Language space where he's delivered applications that empowered subject matter experts to write the business rules of the applications. He is also very interested in maturing software design through software testing. Jay is a DZone MVB and is not an employee of DZone and has posted 116 posts at DZone. You can read more from them at their website. View Full User Profile

Lean Software Development

08.26.2008
| 15125 views |
  • submit to reddit
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.
References
Published at DZone with permission of Jay Fields, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)