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