Sometimes blog posts from other people just combine in my head.

I was reading Rory Blyth's Are You Passionate About Utilizing Your Core Competencies To Effect Strategic Outcomes? about corporate-speak and then read Dare Obasanjo's great post about the Second System effect (basically when a team goes nuts putting in all the frills they cut just to get 1.0 out the door).

First off, anyone saying I "effect outcomes with core utilization of my strategic diversity" (Japanese-Irish-female type) is just saying I'm my normal Betsy pain in the assness, giving my opinion on where I think the project should go. In that spirit, I'd like to add a few more items to Dare's list, while talking about the way those flaws might be packaged .

Aside from can't do it all, pick date or features as your goal, and don't lose site of what made v 1.0 work, I'd suggest these as other project pitfalls:

Juicy Fruit Syndrome - Because X system worked so well to do A, it MUST work well at doing B because the technology is similar - even if the business purpose of B  is not  the same. Yes, you can use chewing gum to stick notes to walls - but do you really want a world of gumwads instead of post-it notes?  You have a young SQL backend? What a coincidence, so do we! Maybe they can date!

Feature Arguments Built on Sand-  Speaking of date, this next one  is more a corollary of date driven vs feature driven dilemma but in this dilemma, there is a shell game going on as the team struggles to define where the application is going.

An  easy example is if a someone may say they want the feature cut because there's no customer value - but it really has more to do them hating to have to code it. Or, wanting to add a feature to be added because it's "cooler technology". Or because the system is "simpler and cleaner" with that feature cut, unless its a cleanliness that the customer sees.

 No matter what your team says, they are not the customer (this goes for pms too, me included). If an agile team can't point to the key business/customer scenarios that are the most important, the team as a whole needs to level-set with the product owner and make sure they are on track.

Sometimes that product owner is the executive sponsor, whereupon you darn well better make sure you align the right higher level scenarios, but sometimes it's an external partner or stakeholder who really knows the customer better than you.

No Real Friends V 1.0 gave you something for customers to sink their teeth into and give you feedback. In the rush to get in all the second system features you scrupulously cut so you would finish  1.0, take the time to ensure you aren't alienating your existing customers or at least have talked with them about why their experience will change. Yes, there are such things as vocal minorities and yes there are such thing as edge case champions. They are most commonly found on your own software team because as previously mentioned, the team doesn't count as the customer.  :)

Can't cross the chasm without the early adopters helping spread the word so you get the later adopters who are more mainstream. So 1.0 worked - but 2.0 might not without folks who believe in you, helping.

 Why Listen to Marketing? Despite the age-old tensions between marketing and development teams, marketing teams can keep you on the straight and narrow. They are the ones doing the surveys, tracking Web site metrics,and noting sales numbers. They know exactly how much it cost you to get that guy to buy your widget. They will know the windows for your business opportunity have a time limit because its their job to track the competition. They trick your product out in the press and in ad campaigns.  Boy, is it a bummer to launch a product or a Web site without them watching your back. Don't forget them even though they ain't coding.  Sometimes the spoken word is worth more than the carriage return.

 

Live it vivid!