Last night, I obtained an autographed copy of Personal Kanban: Mapping Work | Navigating Life by Jim Benson and Tonianne DeMaria Barry. Jim gave an engaging speech in which he described some awesome success stories. The speech was about Kanban, in general, as applied in business settings. So, now, I’m anxious to read the book to get Jim and Tonianne’s take on how to apply it individually.
When I spoke to Tonianne privately after the event, I told her that I’m a fan of David Allen’s Getting Things Done: The Art of Stress-Free Productivity (“GTD”), and I asked her how their Personal Kanban compares to GTD. She said that PK actually plays nice with, and builds upon, GTD and that GTD is mentioned prominently in the book. Now, I just need to see if I can remember how to read a book that’s printed on physical paper.
My local study group has selected our next book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley. This one picks up where a previous book in the series, Continuous Integration: Improving Software Quality and Reducing Risk, leaves off by venturing outside the developer’s realm and tying together other parts of the organization.
I’m expecting this book to become a well-worn, dog-eared resident of my “Software Bibles” bookshelf. (Can you still say “well-worn” and “dog-eared” in the Kindle age?)
It’s often said that one of the virtues (and challenges) of an organization adopting an agile methodology is that it will highlight existing dysfunctions. (The challenge being not to shoot the messenger.) One of the dysfunctions that typically, quickly surfaces is how user requirements can get overly complicated. In an environment that relies on written specifications that are “thrown over the wall” it’s the natural tendency of everyone involved to be as thorough as they can be. And who can blame them? In one respect, it’s their job to think of every contingency and bring all of their experience to bear. Working in a vacuum, it’s only natural to want to err on the side of caution.
Unfortunately, this all too often means that a requirement statement will take on a life of its own. As it evolves and gets fleshed out, the original reason or impetus for the requirement becomes clouded. It is barely retained through implication, if at all.
Allow me to illustrate… Continue reading Simplifying User Requirements →
a blog by Craig L. Jones, Software Agilist