DIY tripod for the iPhone

Do you need to make a short video explaining how to do something with your hands? A drawing, assembling some lego, playing with your Nintendo DS? Well, I needed, and since the only video camera I have is my iPhone, I needed a tripod for it. So here it is, my homemade iPhone tripod!

Converting a list of IP addresses to countries

If you have an Excel file with a column filled with IP addresses that need to be converted to countries, here's a way to do it. These instructions were tested on a Mac, but it should work fine in any environment with Python.

Start by downloading the GeoIP City database from MaxMind. They have a free version that you can download here. Download the one in binary format, and uncompress it.

Next, you need the library to access this database format. There's a pure Python library called pygeoip that you can download from google code. To install it, just uncompress it and run the installer: sudo python setup.py install

Next, you need to build a small script to convert the IP addresses to countries. Here's the script I used (note that the countries database should be in the same directory as the script).

#!/usr/bin/env python

import pygeoip, sys
gi = pygeoip.GeoIP('GeoLiteCity.dat')

for line in sys.stdin:
	rec = gi.record_by_addr(line)
	print rec['country_name']

I used this script (geo.py) by copying the IP list from excel to a plain text file (ips.txt), where you get one address per line. Then just run it with something like python geo.py < ips.text and you get a list of countries on your terminal window. Copy/paste to excel and you're done!

If you want more than just the country, just play a bit with the print line. Here's a variation I did to get the state and the city. The output is tab separated so that you can copy it easily to excel:

#!/usr/bin/env python

import pygeoip, sys
gi = pygeoip.GeoIP('GeoLiteCity.dat')

for line in sys.stdin:
	rec = gi.record_by_addr(line)
	print rec['country_name'] + '\t',
	if rec['country_code'] == 'US' and 'region_name' in rec:
		print rec['region_name'] + '\t' + rec['city']
	else:
		print '-' + '\t' + rec['city']

As a side note, I tried another database from hostip.info, but it was only able to convert about half of the IPs I threw at it, so I recommend going with the one from MaxMind...

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?