Chindōgu is the act - some would say art - of creating a product whose usefulness is precluded by its absurdity.Chindōgus are not absolutely useless, since they typically solve a problem; yet in practical terms, chindōgus are much more humorous in their inherent absurdity than they are useful.
The Japanese word chindōgu means unusual tool. Chindōgu, and its inventor Kenji Kawakami, were featured on the BBC television show It'll Never Work.
How many software chindōgus are you aware of ?Our team is consistently bewildered, confounded, and confused trying to use Version One to plan and track iterations and work tasks. This isn't a rant about Version One. Maybe Version Two will provide tangible value....who knows?
If you have a Version One success (or failure) story,Or, if you have a Software Chindōgu to share...
Please post a comment!
Donald Norman's case studies in The Design of Everyday Things awaken us to the successes and failures of everyday things from the standpoint of usability. Software professionals involved with user interfaces would do well to read Norman's book if only to re-sensitize themselves to the user's experience.
As software professionals, we should strive to grow software that is well-thought out and cleverly usable -- not spawn software oddities suitable for chindōgu museums.
Perhaps Rally and VersionOne share the same type of user experience fundamental principals. I've come into a situation where the team was using Rally and immediately uncovered serious flaws in the included Burndown chart with respect to total number of hours remaining as well as a bazaar method of calculating the ideal burndown that is always changing. Go figure.
ReplyDeleteNice article by the way...
I've never run across the term - Chindogu - thanks for the new term. Having used VersionOne and Rally to track Scrum project - I agree that both are not ideal, and at times rather obtuse. Given that you were not ranting - I'd be interested in your choice of Scrum tracking tools!
ReplyDeleteI prefer pencil and paper - large task boards with sticky notes.
I did use an early version of ScrumWorks that did very well - it matched the Scrum principles well. However I still prefer the interaction and tactile nature of a physical task board and the low fidelity of drawing your own burn down chart on a flip chart.
@M&M - I am slightly disappointed to hear that Rally has its own debilitating quirks like the flawed burndown calc.
ReplyDelete@David,
ReplyDeleteI am in tune with your preference for task boards with stick notes. My early impression was that a software tool benefited the ScrumMaster (or equivalent person responsible for generating various team pulse and velocity reports to stakeholders) than it did team-members (e.g., the people doing the work).
My biggest criticism of tools is things get hidden. When a tool is compared to an old-school, low-fidelity, well-kept task boards, one finds that a lot of team intelligence gets wrapped up (and hidden) in the tool –e.g., the old visibility of the task board goes “poof” when you hide all of it in a software tool.
The old open source tool XPlanner was ugly yet intuitive, easy-to-use, and easy-to-adopt.
A group of us need to build an open source tool that’s 2.0 pretty and offers analogous functionality to XPlanner.
Agilebuddy is a new tool on the market specifically designed to enhance collaboration and surface everything. For example, an activity tracker displays all interactions with the site so that everyone knows exactly what is going on. We use Agilebuddy for our own development across multiple projects although biased, wouldn't do it any other way.
ReplyDeleteIdeally, I think teams should:
ReplyDelete- Learn their process enough to practice it
- Practice and progress through the forming, storming, norming performing cycle.
- Allow tool needs to emerge from the successful execution of process.
- Choose a couple of candidate tools to try based on real-world needs.
- Pick the tool that best meets their real-world needs (features, support, budget, customer service, usability, etc.).
Choosing a tool on hypothetical needs, lists of features a team "needs" developed a priori, previous needs the team had before adopting agile/Scrum/Lean or management wants, invites risk. The last thing you want to do is spend money on a tool your developers won't use.
I do work for ScrumWorks - just to be transparent. But I think my advice is good for any tool.
Hi Bob,
ReplyDeleteOf course, I'm biased, too, but I wanted to say that ScrumWorks Pro is incredibly easy to use. We make it especially easy on developers with our web client, which is essentially a virtual version of the Scrummiest tool around:a task board. (SWP has a desktop client, too, but it's for more complex functions than updating tasks.) You can take a look here: http://www.danube.com/sw_flash/quick_start_demo/quick_start_demo.html
Hi Bob,
ReplyDeleteI tried Version One but found it really hard work to get started. In the end we settled on Acunote http://www.acunote.com/promo because it was simple and lightweight. I'd much prefer a whiteboard but it's not practical with a distributed team. There is some waffle on why I chose it here http://www.software.craftysims.com/?p=42
Nick
I hate to pile on but this is a fun post for me. Apps like VersionOne and XPlanner were the inspirations for my company to build and use a much lighter weight product: Lean-to (http://lean-to.com)
ReplyDeleteIt doesn't do everything that managers want but it works well for developers.
+1 for lean-to
ReplyDeleteRegarding success with VersionOne, you may want to look at this analysis: http://agilesoftwaredevelopment.com/blog/mattgrommes/my-first-agile-project-part-9-choosing-new-tool-versionone
ReplyDeleteNothing like a juicy conversation about Agile tools to get an exec's attention - I am the founder and CTO of Rally. Just wanted to respond to couple of things in this thread -
ReplyDelete1. Rally focuses on scaling Agile practices for larger, often distributed teams - our functionality helps managers deliver Agile benefits in the large. There is quite a difference between our focus and the needs of a single, co-located team. I encourage all teams to start with stickies to learn Agile, but I hold up customer videos of great success with our tool - http://www.rallydev.com/
2. With regard to burn down issues - I would love to have more context, M&M might be delighted to see one of our newest mash-ups that gives teams total control over burndown charting including trend lines, columns, colors, axis and units.
3. Not only are we easier to use that V1, we guarantee your success. http://www.rallydev.com/guarantee/ (Off soap box now - could not help it:)
Feel free to ping me @RallyOn (twitter)
"Money back guarantee" sounds like an infomercial!
ReplyDeleteI used XPlanner for years and once you worked around a couple of its quirks it was good value. It is still the only true open-source planning tool I am aware of which is a shame. There is a market for a new or updated open source tool that can be hosted with the team. In the meantime we have been reasonably happy with Jira and GreenHopper (it is the most cost effective solution I could find, and testers are happy to use it as much as developers and analysts).
ReplyDelete