Giving Gantt charts some Agile love!

Gantt charts have a really bad reputation these days. They're strongly associated with the waterfall methodology, are considered an evil tool that managers use to micro-manage teams, and are usually classified as outdated delusions of certainty about projects that are subject to lots of change.

But still, I love Gantt charts! They're a great way to keep everybody in synch with the overall timeline of a project, team allocation, and how the project dates relate to other important dates.

My secret to make Gantt charts successful is easy: Keep It Simple!

Here are a few tips on how to achieve Gantt Nirvana:

• You have to be able to produce the Gantt really quickly. The problem with most Gantt charts is that creating them is a project in itself. And that means that by the time you publish them, they're already out-of-date.
• It must be really easy to change the Gantt. The Gantt's main purpose is communication. So when the project changes, the Gantt must also change. 
• Gantt's don't work well with lots of data. Forget about the never-ending WBSs. It's too much detail and too much work. User stories are more than enough detail.
• Assign to teams, not individuals. It's up to the team to organize how they solve problems. Besides, it means a lot less work for you!
• Gantt's don't scale well vertically. Don't make a stair case of user stories if they all belong to the same project. Show them one after the other, with the most important first, of course!
• Be precise. There's not much point communicating something that's wrong. Take into account the team velocity, vacations, national holidays, ...
• Add milestones and releases. Make it obvious when things will be made available. Just because a user story is completed next week, that doesn't mean it will be available in production.
• Worry about the future. Retrospectives are important learning tools, but usually it's more important to communicate were we are heading. Focus on that.

At OutSystems, we used our own Agile Platform to automate the entire process of creating the Gantt. All I have to do is click a button, and hey presto! Here's how they look:

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!

It's not about the numbers!

When an organization is small, everyone knows what's going on. People have the full context, communication is easy, and so is evaluating performance. Everything is natural, very ad-hoc, and mostly qualitative.

When the company grows, formalism starts to impose itself.  Some evaluation forms (aka Excel files) appear, and goals and metrics are agreed upon. Still, when evaluation time arrives, everybody is very well aware that things changed since the day the goals were written, and a more qualitative approach is used once again.

When the company gets big, people don't know each other so well, and they don't have all the organization's context at the top of their heads. To make sure everybody is aligned and working for the same grand objective, metrics are put in place. Big mistake!

Don't get me wrong. Metrics are good. The problem is turning metrics into goals and evaluations. Once you do that, people will try to make the number blindly, even if they have to go against the organization's best interest. To put it a single sentence:

Metrics are tools, not goals!

As with every tool, some care must be taken with metrics. Here's a few hints to make sure your metrics are helping you:

1. Understand the metric: Not only the formula to obtain the metric, but why are you getting the current values.
2. Question the values: It's really easy to measure wrong. Check your numbers. Measure twice, cut once.
3. Question the metric: Don't assume the current metric is adequate. Mistakes are made. Things change. More information is available. Be extra critical with metrics!
4. Study the derivative: More important than the number, is the derivative. More important than knowing the current numbers, is knowing next month's.
5. Don't trust all stats: You need a big sample of values to trust statistics. Don't trust averages and the like if the sample is small.
6. Don't use metrics as a direction: Use them as guidance.
7. Talk to people: Don't trust yourself to analyze the results. Talk to the people that measure. Talk to the people that affect the metric.

I'm sure the list goes on and on. What is your advice for working with metrics? Do you have any stories of metrics gone wrong?