Readiness to Serve

Share
Reading time ~2 minutes

A couple of years ago a friend said: (I’m paraphrasing here)

My team are paid a huge pile of money to do nothing most of the time.

As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.

Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.

  • If your teams are always busy, how will they be able to cope with the next bump in the road?
  • If your teams are always busy, how will they be able to stop and see the big picture?
  • If your teams are always busy, when will they have enough time to stop and sharpen their tools?
  • If your teams are always busy, who is looking around to see what the rest of the world is doing?
  • If your teams are always busy, who will you have available to exploit the next change in the market before your competition?

Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.

Software Is Just A Means To An End

Share
Reading time ~1

Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.

Now I have them.

Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.

Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.

I could go on…

Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.

The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.

Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.

Learning to Say “No”

Share
Reading time ~3 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.

FrAgile

So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.

Simple?

Give this a try or adapt something similar for your own needs.

Creative Freedom & Product Ownership

Share
Reading time ~2 minutes

After nearly 2 years of blogging internally for my employer and building up an internal online community readership of nearly a thousand subscribers, I’ve been looking forward to getting my voice to the outside world. I have a lot to say, opinions on most things in the software industry and enjoy sharing.

Having made the personal commitment and investment to do so, I find that 2 days later the words are all there but can’t find form. Where’s all the inspiration that caused me to do this gone?

I know my intended audience, I know the sort of things I usually write about are interesting, I have complete creative control and no real constraints on what I can and can’t say for the first time in years! What happened?

Complete creative control with no constraints?… Oh!…

Complete creative control makes life harder, not easier!

When you move to an environment where you are both delivery team and product owner, how do you go about putting some of the safety rails back up to get back on track and delivering successfully?

Whilst over in the US last week I saw a biography on “Pink” –  I’ve just learned a great lesson from her experiences.

Creative control for Pink’s first album was governed by her record company and whilst very successful, she sought a greater say in her future output.

For her second album, Pink contacted an artist she greatly admired and against the wishes of her record company, developed an album of new material on her own terms. In developing the album she had a clear goal and vision; pair up with a personal heroine, take control and prove she could deliver.  Pink broke the rules and had something to fight for.

On hearing the output, record bosses conceded she’s achieved something special and the album was a massive global success. Following its success her songwriting partner saw a huge surge in demand for her skills and Pink was given complete creative freedom and trust for her next album. – She’d massively over-achieved her goal.

Album#3 didn’t go so well. Her partner was no longer available, complete control was hers but there was no focus. Development was a strained, long process and whilst it did eventually ship, sales performance was generally poor.

Does this sound familiar?

Needless to say Pink’s output did recover.  Now I’ve found my voice I need to re-check both my original vision and my constraints.

After mentioning that I was about to write this post, a good friend and colleague sent me a link to this old business week article from the VP of Google’s search products. It frames the whole constraint thing better than I can – well worth a read.