After 5 users weighed in, there were two obvious omissions in our app. Every single user tried to do these two things without any prodding and became frustrated when it didn’t work. I still had to do a bit of fighting to get the changes in, but that’s another story.

We overlooked these two obvious things in our design process. This happened because we were too close to the product. We were focused in a couple other areas and made some glaring omissions. This is what user testing gets you. Watch someone interact with your product. Just observe for 5 minutes and take notes. You learn as much from that as you do in the entire design process.

http://www.softwareresults.us/2010/06/agile-is-fragile.html

We recently had a bid accepted by a large company everyone knows by name. They liked one of our products and want a whitelabel version of their own. With three weeks left until launch of the product, they asked for about a month additional work to be done. Again, we couldn’t turn down the money. The result was that I had to move resources off another project to work on this additional bit. A couple of bugs and misunderstandings later, I’ve had most of my team working on this project for the last month.

While everyone is off working on the custom project, we’re not taking care of our other products. We’re not fixing important bugs, we’ve pushed other dates back, we’re ignoring other customers requests. These things tend to drag on. If you’re going to take on custom work, make sure the check is big enough to cover the increase in staff you’ll need.

When I took over the group I manage, every person in the company was welcome to visit any developer on the team and request that their top priority were completed. To help alleviate constant interruptions developers had to deal with, I started handling all requests. At some point, it occurred to me that I might not be the best person to set the priorities of the company. I’d like to have a say, but not the whole say. The more I read about agile, the more it made sense to have a product owner.

Ideally, the backlog would constantly be prioritized and before every sprint, we’d just grab the first N number of items off the stack to work on. This is a simple and brilliant concept. It keeps developers developing without constant interruption and ensures the most important features are always worked on.

I’m still struggling with changing the culture to mirror that of a software company instead of a machine shop where we can just flip a switch and have our developer machines output a different widget. Hopefully we get there and we get to see the results of implementing such a noble goal as to institute an ordered backlog.

As far as a date for this, we don’t have any. The next thing up for us is [project X] but we’re still ironing out exactly what that means. We can’t even estimate the work with any kind of accurately until we break it down. If we broke down every request that came in to where we could accurately estimate it, we’d never develop anything.  Also, it’s almost assured that priorities will change before we finish what we’re working on now. Here’s a link to the roadmap, that’s the best I can do.

I give that response so much I should just attach it to my email signature. I do it in the hopes that if I repeat it enough then it might start to sink in. I drive my boss insane when I do things like this, yet I won’t give it up. It’s a difficult thing to sell the idea that dates are not important, especially when you work for a company where almost all of the senior management staff come from backgrounds other than software. To me, it seems insane to look back on a long history of missed dates which were arbitrarily given by someone who didn’t fully understand what work was required and demand we keep doing it.

You don’t make a great museum by putting all the art in the world into a single room…The best is a sub-sub-subset of all the possibilities.

At my company, we constantly run from feature to feature, implementing solutions that are about 80% complete and moving onto the next thing. The result is a lot of half baked and buggy features. At a museum, the curator is responsible for choosing what pieces to display. What isn’t on the walls is as important as what is on them. If you are going to implement something, do it well. If you don’t have time to do it well, don’t do it.