This post originated from an RSS feed registered with Ruby Buzz
by Jay Fields.
Original Post: Lean Software Development
Feed Title: Jay Fields Thoughts
Feed URL: http://blog.jayfields.com/rss.xml
Feed Description: Thoughts on 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.
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.
Previous Topic
