Mobile Trends and Numbers - Infographic

Here's an infographic that I designed for OutSystems. It shows some of the impressive numbers around mobile adoption and mobile in the enterprise:

Via: OutSystems

What's wrong with ScrumBut?

When I talk to other Agilists about SCRUM, I usually get two very extreme reactions to this methodology:

On one side, I get people that say you've got to follow all the rules. That's what SCRUM is! There is no but!

On the other side, I get people saying that there's no such thing as a one size fits all methodology, so you always need to adapt SCRUM for your particular scenario.

Now, I don't agree that you need to blindly follow all the rules of SCRUM. That's not Agile at all... remember the 1st rule in the Agile Manifesto?  "Individuals and interactions over processes and tools". Seems clear to me that, if your team agrees that some part of SCRUM can be improved, the Agile Manifesto is there to back you up.

But...

Just because it is ok to change SCRUM, doesn't mean you should. Failing to properly implement SCRUM is not a valid excuse to change the process "to fit your organization". That's the the type of attitude that gives ScrumBut a bad name!

Before adapting SCRUM to your organization, you need to implement and use original SCRUM for a while. It's only when you finally get SCRUM running smoothly on your organization (and that will take some time!) that you and your team can move to phase 2: Analyze the process, do retrospectives, and improve the process to better suite your needs.

And that's when the real fun of Agile and SCRUM begins!

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?

Sprint review meeting: It's all about Marketing!

I attend a lot of Sprint Review meetings, and sometimes I leave those meetings a bit sad...

It's not that the team hasn't done a great job! Quite the opposite. The teams I work with do miracles! But, like most engineers, they sell themselves short.

Sprint Review Meetings are all about Marketing! Your team needs to sell the work done during the Sprint to the audience!

Here are a few tips to effectively market your work:

• Show the value of what you did: Don't explain how you did it, and don't go into excruciating technical detail about what you implemented... explain the benefits of what you did!
• Do: "By improving the reticulating splines performance, customers have a much smoother checkout process"
• Don't: "We improved reticulating splines speed by using a really smart b-tree structure"
• Make a big fuss about what you did: Don't hide the great work you did in a bullet list with all the details of the Sprint. Pick 3 to 5 key points, and make a slide for each of them.
• Do:
  
• Don't:
  
• Make a real world demo: Be smart with your seed data. Use real data whenever possible, or some really clever examples to make your demo more effective.
• Do: "Peter Smith bought a Mega Chair and paid it with a Visa card"
• Don't: "Customer A bought Product 1 and paid with card X"
• Talk about the entire Use Case: Even if you don't demo it all, explain how the user got to the point of the demo and what the user is trying to achieve. It will make understanding your demo much easier.
• Do: "Peter Smith was navigating at our web site to buy a chair. He did a search for chairs, and clicked the 1st result on the list. What you see here is the page present to him at that stage."
• Don't: "Assume Customer 1 is at this page"
• Make a clean demo: The demo should be as near to reality as possible. Avoid launching the command line, use batch files, or employ other kind of odd gizmos during your demo.
• Don't dwell on what you didn't do: If your team made a commitment to this sprint that it wasn't able to keep, mention it, give a one sentence justification, and move along. Be prepared to answer any questions that may arise, but don't spend the time you have to talk about what you did, speaking about what you didn't do.

What other tips would you add to this list? How do you turn your Sprint Review meetings into huge successes?

When is enough good enough?

We all love perfect products! Those products that you actually feel pleasure just for using. And naturally, we all want to make our own products perfect!

But perfection comes at a price. Generally speaking, the closer you want to get to perfection, the more it will cost you. And the cost increase isn't linear!

(the smiling faces represent the mood of your "average user")

This means you have to be careful when investing on perfection. In most scenarios, there's simply not enough time to make everything perfect. Nothing new here, right? It's just the old quantity vs. quality dilemma. You either do 1 perfect thing, or you do 2 "good enough" things.

If you take this into a software product scope, there are a few guidelines that can help deciding how perfect your feature needs to be:

1. How many times will the feature be used? Rarely used features can be a bit uncomfortable, and seldom used features can be good enough. Perfection should be saved for those features that are used all the time!
   
2. Who will be using the feature? Features targeted at one particular user can get away with a hack. For features existing users are craving for, a quick "good enough" solution may be better than a delayed perfect solution. If you're aiming for first time users, you should go for perfection, to make sure they stick around for more.
   
3. How unique is the feature? Is this something every other product does? Is it always done the same way? Unless this is really core to your product, you probably should stick to good enough and go with the crowd. But if this is something truly unique to your product, polish it up for perfection!
4. Is the feature demo-able? If this is something you'll be wanting to show at a prospect demo or at a room with 400 people, going for perfection is a good investment.
5. Is the feature sell-able? Is this one of those features that has the potential to enchant customers? Better yet, is this a feature customers will be talking about to your prospects? If so, by all means make it perfect!
   

These are just a few things to consider. I bet there's lots more! What factors do you take into consideration when deciding how much effort you should invest on a feature?

PS: The same principle can be applied to a bunch of other areas of a software product, like documentation and marketing. Anyone care to make a blog post about those? :-)