Working on features with no value – frustrating

Few things on a project are as frustrating as being forced to work on a feature that adds no value to the immediate goal of releasing a product. When project managers who are new to product development confuse product ship date with the project deadline, you end up being forced to deliver features that will not be used for weeks or even months to come. Perhaps, not ever. That’s when you sit staring, with a twitch in your eye, at the most basic story. Those “I’d rather be <fill in the blank>” license plate holders immediately come to mind.

As a startup, perhaps, you harbor visions of grandeur, thinking of the time when you’ll be a billion-dollar company employing several hundred people in your back-office operations. But on day one, month one, even month two or three — you are not. Building features and interfaces designed to make the lives of your potential future employees easier is probably not the best use of one’s time when you’re close to launch and your current employee count is at zero.

Focus on your product. Make sure it is appealing and easy to use. Make sure that it will attract that first million-dollar customer and will enable him to do business with you. And if in the mean time your initial staff of employees has to jump through a couple of hoops and push a few too many buttons to service this million-dollar customer, well — attribute that to growing pains.

 

 

 

Mr. Potato Head of Agile or How to fill a box

In the Downtown Disney Marketplace there’s a store called Once Upon a Toy. One of the areas inside of the store sells various loose Mr. Potato Head parts: Disney themed parts, Star War themed parts, Halloween parts — almost anything you can imagine. Some parts, like the eyeballs, are small. Other parts, like the arms, are larger. And yet others, like the hats and the shoes, are large. They sell parts by a box: pick up an empty cardboard box, fill it with whatever parts strike your fancy, and, as long the box closes, it is $20.

A kid let loose to pick his own parts may grab a few of the larger pieces, the hats and such, put them in a box and find out that there is no more room for anything else. So for 20 bucks, that kid may get 6 different parts. This is what the store hopes you will do.

A seasoned or a frugal shopper will approach the problem with a little more sophistication, strategically picking a mix of small, medium and large parts to optimize the box space. This shopper may end up with a mix of about a dozen parts or more. Not exactly what the store wants, but I’m sure they still make money.

The other day, a client, new to Agile, asked me for help to understand the concept of estimating in points and how to translate story points to hours / dollars — a common request. As I was thinking about a good way to explain points, I remembered my Disney World trips. The analogy of the Mr. Potato Head box is what makes translating points into dollars tricky. How much an Agile team accomplishes in a week, how many stories and points you get for your 20 dollars, it all depends on the level of the team’s sophistication, on their velocity.

Think of the user stories as loose Mr. Potato Head parts each worth 1, 3 or 5 points (depending on the size) and of a sprint as one cardboard box. A sprint, just like the box, can hold a finite number of parts (user stories), resulting in a finite number of points. Exactly how many depends on your teams’ ability to optimize the box space — the team’s velocity. Early in the process, they probably can only figure out how to put 6 pirate hats (5 points each) into the box, accomplishing 30 points. As they get smarter and start figuring things out, they may realize that if, instead of a pirate hat for 5 points, they get 2 medium arms (each worth 3 points), they can actually complete more. And because of the shape of the arms, 2 arms leave even some room for 2 more eyeballs (1 point each) for a total of 8 points now. So suddenly, instead of 30 points, you are getting 33 points in one box.

Unfortunately, there may come a sprint when you really want that tall and pointy Mickey’s Wizard hat, which takes up much of the box, leaving very little room for anything else. Some sprints you win, some sprints you lose. At the end of the day, your box of a sprint still costs you 20 dollars, regardless of how many parts you manage to walk away with. And if you’re really concerned with how much each size part cost after all, just look at the average velocity. But only after a healthy number of good, clean boxes of parts.

Number of hours in a sprint divided by the average sprint velocity should give you the number of hours per story point.

What do you think? Does this analogy work?

 

 

eBooks are our faceless friends

I love my Kindle. I’ve read probably a hundred books on it and will definitely read many hundreds more. I love everything about it: the convenience factor, the screen, the storage space, the form factor — everything.

I’ve read about a hundred books, but, if it wasn’t for Shelfari, I probably wouldn’t remember reading half of them. Not what the book is about, but the very fact that I’ve read this book. If I were browsing library shelves and happened to pick up some of the books I’ve read, I wouldn’t recognize them. Why is that?

The familiar and easily recognizable form factor of a Kindle makes the experience of reading one book virtually indistinguishable from reading any other. You may be reading a Lincoln biography, The Three Musketeers or the Holly Bible — nothing, absolutely nothing, changes. It’s the same black device with the same screen and the same black-on-white print. There are no pictures; the weight, the size, or the font of the book never changes. All those memory hooks that allow us to remember and distinguish things are missing. The books that you’re reading simply have no face. It’s like meeting a hundred faceless men at a cocktail party and having them tell you their name and their life story. You may remember the stories, but good luck telling which story belongs to who.

The same thing happens when I try to remember a specific paragraph or illustration from a book. The way memory, at least my memory, works, I remember that this specific paragraph was somewhere in the last third of the book, it was after this illustration but before that diagram, it was at the bottom of a page that had some other distinguishable sentences on it. I might have even highlighted it. In other words, finding something in a physical book is possible by just leafing through pages and setting off memory triggers. In an ebook all of that is missing: you can’t open a book in its last third and leaf through the pages to find something. You have to rely on the search feature, but you have to know what you’re searching for in the first place.

(Of course, there’s the highlight feature of a Kindle, but unless you make just a few highlights in a given book, finding a particular highlight is also not so straight forward.)

I find that using ebooks forces me to give up the natural way I remember things. It is forcing me to devise new ways, which don’t feel right and, frankly, don’t work for me. I’m yet to come up with a system for consuming all those highlights I made in all those Kindle books. I’ve tried importing my highlights and organizing them somehow in Evernote, but that, once again, forces me to have to remember what I’m looking for in the first place. I’m considering starting a good old notebook of handwritten notes. Seems like too much work though.

What do you do? Do you have a system for remembering or finding things in ebooks?

Agile does not mean fast

When people think of Agile, what drives customers’ interest in Agile is thinking that Agile will enable them to get projects don’t faster and cheaper than the classic project management. But that is not always the case.  

Agile is not synonymous with fast. The dictionary defines “agile” as “able to move quickly and easily”. An Agile team is one that can quickly and easily react to changes in project’s requirements and new ideas as the project takes shape in front of the customer. If you think of a project as a road trip from point A (start of the project) to point B (delivery of the project), an Agile team is the one that doesn’t get slowed down or thrown off course by road construction, avalanches or collapsed bridges. Agile teams don’t blindly follow the GPS. If the GPS is leading them straight into the ocean, they can adjust their course quickly enough to not slow down the project. They don’t need to stop or even return back home and plan a different route.

But all that does not imply that they will get to their destination faster than anyone else. It just means that they will get to their destination, no matter the obstacles along the way.

Such agility, however, comes at a cost. The overall trip may end up taking longer than what the GPS originally promised you because it didn’t know about the missing bridge ahead. And it may even cost more: you might need to bring an extra person with you, someone who knows the roads well. But you will get to your destination and with great road trip stories to tell.