Tracking change and innovation in the enterprise software development community
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Vikas Hazrati on Sep 12, 2008 04:00 AM
The importance of information radiators and informative workspace is unquestioned in Agile. Scrum and XP have enough visual indicators like whiteboards, flip charts, burndown charts, build status lamps etc. so that the information is highlighted as soon as it is gathered for easy consumption.
Michael Hunger and Takeshi Kakeda take this idea a bit further by using Lego blocks to track time spent on various projects and bug tracking. According to them it is both effective and fun.
Michael Hunger discovered the Lego way of time tracking when he was trying to find a solution for visually depicting and planning the time spent on various projects in a week. Michael represented each column on the base as a ruler on which he could stack the hours. He represented each hour as an aggregation of 4 studs of Lego, each stud representing quarter of an hour. So if the first hour was spent on 2 projects then it would have 2 studs of 2 colors on the first row. Each project is represented with a different color.
On similar lines Takeshi Kakeda presented about the use of Lego blocks in doing effective bug tracking at Agile 2008.The bugs were represented as Lego blocks on the board with priority being represented horizontally, dependency between bugs represented by stacking them vertically and the difficulty represented by the shape. Some of the benefits that Takeshi observed were that bugs were intuitively visible and mindset of the developers changed from negative to positive. Also, given the physical constraint of the board on which bugs could be placed new bugs could not be added unless the earlier ones were resolved, thus making it necessary to resolve existing bugs faster.
Thus use of Lego blocks has gone further from just being present in a kids play basket to being used as effective information radiator in the Agile environment.
Lean Software Development Governance, a whitepaper by Per Kroll and Scott Ambler
Agile Projects: Five Ways to Fail When You Scale
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
The Future of Software Delivery According to visionaries Grady Booch & Erich Gamma
Webcast: Applying lean thinking to the governance of software development
Gotta hand it to Michael and Takeshi - they've taken the mundane task of Time Tracking and made it fun again. I like Michael's one drawback: co-workers coming along, assuming the legos are to play with, and then destroy your weeks work in one fell swoop.
Legos haven't been for kids since they came out with the first Mindstorm kit... You could apply this to any real world set of objects though. I wouldn't use M&Ms though.
A side note... is it common for others to track tasks down to 1/4 hr?
A side note... is it common for others to track tasks down to 1/4 hr?
May be some consultants need to do it on the basis of multiple projects that they are working on. For me a one hour slot is kind of manageable
Thanks for mentioning this on infoq.
We even continued our journey into LegoLand.
The next things I plan are integrating a webcam into the time tracking board for automatic recording of the brick columns (similar things (but oriented in the wrong direction have been build by databrick.de.
The next great thing (tm) is printing onto lego bricks. I was looking for ways to increase the available colors for the time tracking (especially when extended to task tracking on agile projects). So my neighbor Mattcher and me came to the conclusion that just printing onto lego walls is the solution. See this blog entry for first impressions.
I'm continuing my efforts on finding a proper name for this time tracking. A lot of names have been proposed by
Lifehacker readers and commenters to my blog. Istarted a poll on that on my blog
Perhaps I should present that at JAOO in two weeks :)
Regarding the quarter hour question. My current client requires all his contributors to track the time at that level. So thats not necessarily my choice (besides if you have a half hour task which crosses the hour boundary you still need to break it up for display in the two rows).
Michael
Perhaps the comments on lifehacker on lego time tracking are also of interest.
Michael
Four years ago I have created a workshop about leadership with Lego. (You can download it here
www.paircoaching.net/games_en.php )
While playing this game at several Xp events around the world (we also played it at Agile 2008)
I learned that Lego Group has a business consultancy company that is called Lego Serious play.
en.wikipedia.org/wiki/Lego_Serious_Play
Teams new to agile planning sometimes break work into very small tasks in order to understand what needs to be done. Once they understand it, usually relatively soon, they tend to roll several small tasks up into larger ones, or even estimate at the story level.
A mature team could probably eliminate some waste by estimating at a larger granularity. If they say they cannot, I'd see a red flag and look for too much multitasking.
Charles Nutter discusses bringing JRuby to the JVM, why Ruby is hard to implement, JIT compilation, precompilation, core Ruby implementation, Java library access, library challenges and future plans.
Alois Reitbauer specifies several architectural anti-patterns that one should stay away from and which can downgrade an application’s performance.
Teams in large organizations still struggle to adopt TDD. In this article Mark Levison shares problems he uncovered when he surveyed teams, and his own strategy to introduce TDD into an organization.
In this talk from RubyFringe, Luke Francl asks: is developer-driven testing really the best way to find software defects? Or is the emphasis on testing and test coverage barking up the wrong tree?
John Pampuch discusses the HotSpot compiler, the history of Java performance, HotSpot development philosophies and challenges, optimization, JVM library improvements, and tips for better performance.
In this interview, Keith Braithwaite, an Agile developer, consultant and trainer, says that we should show a good deal of skepticism towards today’s Agile practice.
This article demonstrates how to build and orchestrate highly configurable and extensible yet light-weight embedded process flow using AOP techniques with Spring AOP and Aspect J.
Jeff Patton explains why one needs to embrace uncertainty in order to succeed with his/her Agile project and how to avoid some of the common mistakes leading to project failure.
7 comments
Reply