Agile Development Blog

Ooooh! It’s Friday and time for another celebration of a one hit wonder. And though it is April Fool’s Day, this is no joke. Today I am thinking about how we have to continually hone our craft in our technology world. Sometimes, I feel as though I am in a never ending PhD program. Or, I keep moving from one apprenticeship to another. It can be overwhelming. And yet, I love my work. I love feeling growth and challenge in how we continuously improve the software industry.

I started in this technical world 30 years ago, programming JCL on punch cards. It was that or paper tape. (I am NOT making this up!) I moved on to PL/1, Fortran, C, and a couple of assembly languages along the way. I then made the dramatic move from procedural languages to object-oriented languages.

And there were other areas in which the world of technology invited my growth through challenge and reward. I slowly moved away from a very documentation-driven view of the world. (Well, I could call it “graduated from” but I don’t want to be too provocative on a “One Hit Wonder Friday!”) And there was a time when my sense of significance was deeply wrapped up in my prowess in Microsoft Project, in 5-level work breakdown structures, and in pages of perfectly aligned Gantt charts based on my skills with Finish-Start dependencies. Whoa! Just had a trip down memory lane! It’s a heart-breaking story. And it is worth telling. Because, now I am in an Agile world.

Today, I am pausing and reflecting on how I have had to continually be prepared to re-tool my thinking and my tools. It hasn’t always been easy. And, it has ALWAYS been rewarding. Moving to the world of Agile and continuously working on my grasp of lean thinking, systems thinking, complexity theory and knowledgement management has all been a challenge. The rewards, however, are priceless.

And now our one hit wonder of the day. This week I am thinking about an artist not from the music industry. His work was limited to the big (and little) screen. He was brilliant in his craft at the time of his fame. In fact, I would say he was singular, outstanding, ground-breaking. He won the hearts of millions. And yet, he fell into obsolescense to the point of later appearing in television shows and movies more as a perfect caricature of himself. Why? He didn’t keep up with technology. He remained in a world in which his craft lost its value. As good as he was, he was left behind. He is a poignant reminder that we must always invite growth and change even when we may feel lost or that it is all just too much. Our artist for today gave selflessly to others when all odds were against them.

Yes, today we are celebrating “Robbie the Robot” from the the 1956 movie “Forbidden Planet”. The spelling of his name (Robby/Robbie) seems to be somewhat of a mystery just as Robbie’s dedication to his performance was mystical. Though he appeared in a variety of movies and TV shows after “Forbidden Plant” (including “Lost in Space” no less), these were only as brief cameos, as sad reminders of glory days long past.

I met Robbie several weeks ago in the Intel Museum in Hillsboro, Oregon. I was at the Intel Agile Conference there when Scott Hanselman of Microsoft asked to interview me for channel9.msdn.com. Where better to hold the interview than in the museum just across the way from the conference? And there he was, Robbie the Robot. Wow. Me meeting Robbie the Robot. Robbie still holds up his head with pride despite being relegated to museum status. He still holds out his large rounded, clumsy digits ever ready to offer assistance despite his inability to do so. I salute Robbie for all he has given us.

Jean Tabaka is a crash skier, college hoops shredologist, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka

There are several problems with traditional requirements formats

• They cost a lot of money to produce and yet you can’t sell them to your customers (waste)
• They can be monolithic (90 page use cases) and so they’re hard to manage when different pieces have different importance.  The desire to make them comprehensive loads extra work onto the development team. (strain)
• They take a long time to produce, holding up the development process and delaying the feedback that comes when users get to see working software (wait time)
• The more detailed they are, the more the team thinks they’re complete and the less critical thinking gets applied to them, leading to more defects (waste)

User stories are designed to address these issues.  A user story represents a small piece of business value that a software team can deliver within an iteration.  Here’s one:

As a customer, I want to check my order status online so that I can know when to expect my package.

There’s actually a lot in that little line – we know who the user is, what’s the activity they want to do, and what’s the underlying goal.

Ron Jeffries has said that there are actually three parts of a user story:

1. Card - the part we wrote in italics above.  It’s just a placeholder – a project management mechanism that we’ll use to remind us that at some point we probably should get around to building an order status thingy.  This part should be short enough to write on one side of an index card with a sharpie marker.  You could even word it “Order Status Checker Thingy” to emphasize that it’s a placeholder, not a requirement.
2. Conversation - When this card comes up in the stack as the top priority, the team will talk during iteration planning about the acceptance criteria that will need to be met to satisfy the customer or Product Owner that they built the right kind of “Order Status Checker Thingy”.  Sometimes the criteria are noted on the back of an index card or in an agile tracking tool.
3. Confirmation – The detailed acceptance tests that the team writes during the iteration to define exactly how an “Order Status Checker Thingy” should work, in excruciating detail

A user story is unlike regular requirements because the requirements aren’t specified in detail until the tests are written, around the same time as implementation.  Benefits of this approach:

• No inherent waste.  We’re only writing down as much as we need to document our conversations and make sure we’re all on the same page
• Encourages discussion. Your developers and testers know a lot about what they’re building.  They’re capable of thinking of important details and preventing defects and other bigger mistakes, if the process encourages them
• Easy to manage.  If you’re used to use cases, break down your scenarios and steps into stories.  You can do the important parts early and postpone the less important parts later.
• Easy to manage scope creep.  If you think of new things to do, create new stories and add them to your list in priority order.  Since you’re always doing the most important things first, you’ll end up naturally managing scope in a way you can’t when you’re working off of requirements documents.

(This is a draft – please add comments or edit the pattern itself)