Nothing to see here, move along

NerdPassionsA few months ago I had lunch with a friend who wanted to pick my brain about some frustrations she was having with her company’s software development department.  Her company produces specialized machinery for something (actually, I forget what they do), but they also build and sell software products.  In her role, she leads up a marketing team in charge of commercialization, PR and marketing of their software.

She started the lunch in a quite civil mood – the food was great, the restaurant was awesome – but once she started talking about their software guys, she got a bit edgy.  “I don’t know what they’re doing.” She said, clearly agitated.  “We’re supposed to release this new version in 3 weeks, and I’ve never even seen it.  I don’t know what new features are actually going into it, and they won’t tell me.”

“Every Time I go to meet with them to get more information, they treat me like I’m an intruder – like I’m some annoying idiot from Marketing invading their turf.  All I get is hand-waving and the big brush-off: ‘Nothing to see here pretty lady…’ blah blah blah.”

“I don’t get it.  How am I supposed to do my job? We’re supposed to go live in 3 weeks and they won’t even show me!”

My immediate reactions while she was telling me this story were a bit like this:  I wanted to go strangle that software team.   It was clear that they were badly organized, lacked leadership, they’ll no doubt miss their release target, it will ship with a reduced set of features, and the quality will be poor.  I got especially annoyed when she went on to tell me that they were “Agile”.  Her comment was, “I know you do Agile too, but I don’t think it works.”  That was the clincher.

strangle

Agile is all about transparency, it’s about delivering continuous working software, it’s about inviting all stakeholders in to participate in the development of a product.  Like anything, there are a lot of pretenders out there using a popular concept to hide their own inability.

So, if you were in my shoes, in that situation, sitting across from her, what would you say she should do?

Should she escalate the issue to higher-ups?

Should she continue to badger them till she got answers?

Maybe she should just know-her place.   Bow down to the divine miracle-makers in software.  Wait patiently until they’ve completed the magic-of-software-development before asking more tedious marketing questions.

What would you say? (see poll below)

Ultimately, there are so many things wrong with this situation; I struggle to know where to begin.  So, I’ll make a quick list of the obvious problems that this represents before diving into any detail:

  1. There’s a clear misaligned idea of product ‘ownership’.  While the product should be owned by the business as a whole, the development team appears to view their role as somehow ‘more entitled’
  2. There is a dangerous breakdown in Transparency and Communication
  3. The software team doesn’t know how to ‘ship’ software

A misaligned idea of product ‘ownership’

Clearly many software teams are compelled to believe that what they do – their role in their organization – is to ‘write software’.  Which, in some respects, has some functional truth to it; but the greater truth to what technology professionals do is, “Build Market-Driven Products”.

So, okay, maybe that statement makes you want to roll your eyes to the sky … but at the end of the day, we all work for a company that is in the business of doing business.  Making money.  Whether you’re building commercial or internal software, your company is investing in your time because they believe that it will help them make money.  It’s pretty rare that someone will pay you to play with technology.  The fact is, they’re paying you to do whatever you can to produce a product that has the maximum market potential and ROI so that they can make money.

The long and short of all that is: the technology team doesn’t ‘own’ the product and they have no right to throw up barriers around that product when other stakeholders with equal ownership need to participate in the product’s success.  The product is owned by the business, and the software group’s contribution to that should be a business-driven contribution. NOT a technology-driven contribution.

A Breakdown in Transparency

Software developers have a strong desire to hide in a dark corner and fidget away at their work – their creation – for as long as they can get away with.  The goal is to reappear, unveil the masterpiece with a “Ta Da!” and crowds will applaud the genius, the angels will sing and he will have saved the day.

This is likely the most dangerous thing in the world of software.nothing to see here

Ensuring that your team is fully transparent from all aspects of communication, visibility and availability of working product is absolutely fundamental to a successful software project. If you’re getting pushed off with the “Move along, nothing to see here…” attitude from the dev shop, it’s a clear sign that things are not well in that department.

Learn to ShipSoftware

I just had a chat with my friend, and as it turns out, 4 months later, they still haven’t shipped that release.  And it’s still not clear to her, or anyone else outside the technology department, what will be released or when.

Writing the code is only one aspect of creating a commercial product that you deliver to happy customers (internal or commercial).  The act of shipping that software product is craft that requires practice, experience and a lot of planning.  It’s tricky to ship.  No question.  So, to manage the risk and pitfalls that exist around getting your product to market, best practices tell us to ship all the time.  Ship your software as often as you can. Even if it’s only to internal stakeholders – your BA, Product Manager, trusted clients, etc.  Ship.

If you are on the outside looking in; and your dev group can’t prove that they can ship the software asset you’re investing in long before the release date – this is another sign that things are not well in that department.

Chris Ronak

Advertisements

5 responses to “Nothing to see here, move along

  1. Great post. A keeper.

  2. Pingback: News and Stuff, August 14 | The Build Doctor

  3. me gusta mucho. This is exactly what I’ve lived with for 7 years. It is quite refreshing to know what a good solid plan / solution is to this problem. What happens when the Dev department is the only department on board with this methodology and the rest of the organization JUST DOESN’T GET IT??

  4. “I know you do Agile too, but I don’t think it works.”

    Great line!

    Sadly your friend’s experience is not unique. I’ve heard stories from several other people that amount to “we can’t give you the information you need because we’re doing agile now”.

    I suspect judicious use of electroshock therapy is called for.

  5. Nice post. All to common of a situation. I think it is important for Agile practitioners to respond to those who blame a problems in delivering and a lack of transparency on Agile.

    We (IT development) had these problems way before Agile. Agile arose as a response to this problem. When Agile is not done well, these problems persist. When Agile is done responsibly these problems are addressed. Your friend’s software development team is just not being run responsibly.

    They are probably “saving money” by not bringing in a transformation consultant or hiring mature developers. The shame of this is that in the four months they have squandered, they could have turned around their team.

    Dennis Stevens

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s