Sunday, May 23, 2010

Beating the Delivery Deadline!

I'm a product delivery manager at OutSystems. In a nutshell, my job is to make sure new versions of the Agile Platform are released on time, with quality, and with all the features agreed upon.

Last Friday we released version 5.1 beta of the Agile Platform! And yes, it was released on time, with quality, and with everything the stakeholders were expecting! Cool, hum?

And if you're wondering, this wasn't a one time lucky shot. This is the 4th version since I'm a delivery manager that we've pulled this off!

Actually, this shouldn't be anything to be amazed about... But the fact of the matter is that it is so unusual, that it surprises most people I know in the software industry. So I decided to share some principles I follow to make sure we ship on time:

  • Embrace change: One of the most anticipated features on 5.1 are the Wizards. Funny enough, the wizards weren't part of 5.1 when it started! This could've been a major stress factor, but it wasn't! From the moment we understood it was the right decision, we were more than thrilled to make it happen!
  • Don't add, swap: It's really easy to add a bunch of features to a version, just so see its ship date delayed over and over. Swapping puts a price on features and forces everyone to prioritize. This keeps everyone focused on shipping the most important things first!
  • Say 'No': It happens on every version. The end date gets near and everybody wants to add just one more thing. It's much easier to say "yes", but you'll regret it for much longer. I usually put it like this: Is it worth it to miss the ship date to add this last minute feature? It usually isn't...
  • Know your teams: 5.1 got out on time because we were able to predict how long it would take to build! And the reason we were able to predict this (even with so much change!) is because we studied past versions to learn how long we take to do stuff. And not just the time software takes to build, we also consider interactions with other teams, user feedback, meetings, ...
  • Establish design rules: It's really easy to derail when developing software. Establishing good design rules (visions, goals, guidelines, ...) is a great way to make sure everyone is on the same page. To be honest, I usually don't come up with these rules. The teams do! I just help teams stick to them.
  • Get out of the way: I'm always available to give help and advice to my teams. But once I feel they're on track, I get out of the way. This is actually much harder to do than it seems, but once you have this level of trust with your teams, it's pure bliss - for both the manager and the team!
  • Ship: There's always last minute bugs. There's always a reason to stop the presses and hold the version. Turns out most last minute bugs only occur when the planets are aligned and it's raining in the Kalahari... so ship anyway! You can fix it tomorrow!
These might seem like easy enough tips, but to each of them there's a lot of preparation, trust, and discernment going on! Not only that, there's a huge requirement to make any of these tips work:

You need amazing teams working with you!

Lucky for me, I work with the best teams on the planet!

3 comments:

Sreekanth Challam said...

Hi, I like your articles about product development and delivery. Could you please provide the list of sample design rules that your development team uses? Are there any processes that your team follow to make sure the code well tested and complete as per specifications before delivering it to QA?

Raja Bavani said...

Nice blog! and the tips are very practical!

Do you work with distributed teams?

kutuma said...

@Sreekanth Design rules are really very specific to the project, more than the teams. Check the slides from Dan Saffer on the topic, from slide 21 onwards: http://www.slideshare.net/dansaffer/ideation-and-design-principles-workshop