Over a million developers have joined DZone.

Lean Software Development

DZone's Guide to

Lean Software Development

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

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 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 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.

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.

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.

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.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Jay Fields, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}