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.
As an answer to your quesiton of what you should do in the next release, I would think of what the biggest risk you face at this point in the project. Then I would find the quickest way to release a version of the product that exercises the risk.
IMO you are wearing too much hats to hope any approximately scientific conclusion out of this experiment.
But, being so, this allows you to decide faster and drive the implementation of the idea and vision you have in your head faster and in a much more agile way than common agile projects.
So, I would say you should continue the way you were during the first iteration.
>Can I plead temporary insanity?
*lol*
Scott, thank you for your honest analysis. I believe this is how this experiment teaches its audience.
I would agree with Luis, if it was a goal of this experiment to draw scientific conclusions. However, I see it “just” as another chance to get anecdotal evidence on the subject, which might lead to some theory in the future. Over all, I’m happy with it.
I tend to follow Rogers idea of exercising risks, that’s kind of what I used to do in my projects. But some really cool article on the web – which I don’t recognise anymore, sh** – suggested to design value in instead of designing risks out. So I propose going over the use cases, see what we can change or add, do a quick round on priorities and off we go.
PS: Please let me add another quick remark on the term prototype, which somehow made it into our APR language. I think there’s not much room for prototypes in agile development (there is room, but it is almost before the start). The Nexus alpha release is exactly that: a release.
PPS: the cool thing about wearing lots of hats is that you can gain different kinds of satisfaction. It adds up! :-) Keep motivated, Scott.
On Rolf’s point about risks versus value: I see the distinction as a false dichotomy. Failure to deliver value is itself a risk. When prioritizing risks, you consider all of them, including value and architectural uncertainties.
Interesting discussion, and thanks all for the ideas and support!
Exercising risks, or exorcising risks? The goal is to grow the user base until nexus reaches a tipping point where it becomes more valuable to the contributors than the cost of investing time in the site. What are the biggest risks to that?
They can be technical, marketing, or functional.
At the pre-beta stage, I’m not worried about marketing. Granted, we get a bunch indirectly from readers here, but it isn’t the focus.
Functional risks, I think we will address within the normal use case prioritization exercise, as Rolf suggests.
Technical risks, there are actually a couple – that search work effectively, that we get pagination of the site, that we get emailing set up without becoming a spambot for someone.
Roger – were you thinking of other facets of risk too?
That about covers it, Scott :-) Although there is requirements risk. Requirements risk comes from not being able to know what users really want until you put something demoable or usable in front of them. To some extent, the very nature of “true” agile is to confront these risks through frequent releases.
Nonetheless, you might also consider what the biggest requirements unknowns are. If, for example, security or other nonfunctional requirements were the biggest risk, you would want to implement the use cases (or use case versions) that exercise them.