APR: Process Deviation?

Rolf presented a valid critique and some questions on our previous article announcing the launch of nexus. I started writing a long response, and realized it would work well as an article for analysis of our process over the last month. Here it is.

Rolf’s Critique and Questions

Here’s the critique/question part of Rolf’s comment:

However, allow me to comment on the agile project experiment (no offense intended !).
For me, in an agile project there’s no room for “Bonus Features -
a couple other things implemented early while we were there”. I’d like to see us come back to the original idea of prioritization (which can mean a change of priorities with the help of the users).

All new ideas or things we stumble upon should undergo the same persona/usecase/priorities analysis as the original ideas did. Otherwise this project leans over to hacking. (However, I respect your dictator role, Scott.) This should be done for the purpose of the experiment reader’s (and my) education and their chance of gaining insight. I know that it is easier to skip these things, but that is not what we are preaching in agile/lean product development classes/articles/books.

On the other hand, can the “change of plan” be interpreted as an experience with agile projects? Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products? (or even further, that projects should be created so, that a product manager can implement his own vision ;-)
This would be very interesting knowledge I gain from the experiment.

I’d love to know what YOU are thinking about the project’s process. Why did we deviate?

Hey Rolf, first – thanks for the help on the project, I’m looking forward to more as we go. Second – thanks for the spot-on critique of the “bonus features.”

It is definitely not agile. Can I plead temporary insanity? I cite as evidence the “ideas” section in the previous article. That is definitely the right way to do it from an agile standpoint – throw ideas into the prioritization mix. I would also add that there is an element of dictatorial product management in the mix. We can walk through each of the bonus features and see what we think…

Here’s how I would categorize the ‘bonus features’ above:

• Faceted navigation & URLs – an interaction design-driven part of the implementation approach. I would contend that this is orthogonal to the prioritization process. This is getting good ideas at a lower level, into implementation. I think this was wholly appropriate and not subverting the process. Maybe it feels clunky trying to mix it into the other discussions, but I didn’t view it as “implement and refactor without reprioritization.” I felt that the ‘out of the box’ routing (/nexus/article/show/12) was sophomoric, and the implementation of the first version of page navigation (specifically for browsing) required some form of IA implementation and solution in order to create the nav-bars. So this was the first proposed solution for browsing – just with user feedback.
• Having reviews in the first public release. I would say that this was just bad form on my part. A sign of weak project management. The product manager (me) knew it was important – it was scheduled for the second release. The developer (me) knew it was relatively easy – what I had just learned as part of implementing article-submission made it easy to extend to reviews. The project manager (me) was still busy freaking out about the risk of XSS attacks and was distracted by the demands from the President (me) that the site not go live until acceptable security measures were in place. The developer (me again) and product manager (me) snuck it into the first release. We occasionally show disdain for me in this way.
• Rating a Review – I put this in the dictatorial product manager bucket. I felt that it was important (as part of allowing comment/reviews) to the notion of credibility and trust, that we have this feature. Especially since to make it happen required 30 minutes of learning/refactoring the existing rating implementation to apply it to reviews as well as articles.
• User Page – hmm. Don’t really know if I can sneak this in as design or dictatorship. Just seemed like the right thing to do. Wasn’t in any of the mockups either – just appeared during development.
• Calculating a User Score – OK, so this one is definitely a violation of prioritization. And it probably took a couple hours to figure out and implement. I did get some feedback offline on the design and approach, but will it demonstrate value – maybe. No way to describe this one as anything other than “not following process.” Slapping myself on the wrist now.

Drawing Conclusions

Getting back to Rolf’s question – “Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products?”

I think people trump process any day. But a good process makes people better. So process is worth pursuing. I have a struggle on this project, wearing dev/design/product&project management hats. Plus I have the dictator-card. And blogging about the project as we go, while really useful info for learning, is also a form of inappropriate, low level marketing announcements. We’re essentially broadcasting very prematurely, about every move we make and when we’ll make it. So this study is a bit polluted. By watching the process, we modify the process. Good thing this isn’t a quantum mechanics experiment.

I think design inputs are valid elements of the implementation (faceted navigation as an implementation choice for browsing). I think a process that prevents convenient low-hanging fruit (rating the quality of reviews) is a bad process.

Also, I think we made a mistake in including reviews in the first release without re-prioritizing first. In my defense, the security-thing threw me for a bit of a loop, and reviews were not part of the very-first release (which was shared with the Austin on Rails developers). I probably should have just addressed security and released without reviews. As a developer, I needed some occasional breaks and accomplishments to make the days of reading about XSS and SQL-injection solutions more fun. And that’s what I ended up doing. Probably shouldn’t have.

We did get some good user feedback about reviews being more important than numerical ratings for some people. So it was easy to “cheat.” I think the dictator philosophy is actually a good one – listen to your customers – absolutely. But that doesn’t mean you do exactly what they say. You do what they need, to the best of your ability, which is highly aligned with what they say – but not exactly the same thing.

What Do You Think?

What should we do differently next week as part of building out the next release? Our plan is to start with prioritization of pending / new ideas.