Be Agile, not chaotic

3 months around the world

If you travel by yourself and don’t have a time limit, you might wake up every morning and decide if you stay or you go, how far or for how long. But if you have a certain deadline and you travel with a few more people you are going to need to be a bit more organized. Let’s analyze two possible outcomes, assuming you have 3 months to complete your journey.

Scenario A

You start traveling with your mates, take a look at the map and decide the next checkpoint is 600 km away. You have transportation problems and don’t make it in time, but it doesn’t bother much, it is the beginning of the trip and morale is high.

Next morning you decide you have to be at the following checkpoint in two days, which seems highly unlikely given your current progress. People start arguing and finally with some discontent you make it there.

Then, without an apparent reason, you suddenly change your route. People follow, but begin to wonder if you know what you are doing. A few checkpoints ahead, your team is stressed out, unhappy and starts to realize that even if the final goal is clear (be back home in 3 months), no one knows how much progress they’ve made.

It seems there is always a long way ahead and it is impossible to know when they will reach what place, and if they are even going to finish on time.

Scenario B

Before hitting the road, you decide to spend a day or two examining the map. You realize that if you set up 8 checkpoints, traveling by X transportation between each of them, you are going to be back home on time.

You start traveling, and after each checkpoint you have a team talk to review how it went. If you were late to reach a place, you analyze why and try to correct the situation, if you arrive early you might make use of the extra time to patch your gear up or get supplies.

At any given time, the whole team knows how far they are because there are still X checkpoints ahead, and if that ever changes, everyone is given a chance to speak their minds. Everyone is happy, morale is high.

In which team would you rather be? Travelling is always a nice experience and you might argue you’d be happy in either of them, but if the context is anything other than that, let me tell you, you don’t want to be in team A.

Back to NaN

Here at NaN, it wasn’t so much about travel. Our goal was to develop a mobile application.

We started with no fixed deadline and no knowledge of all required features, which is roughly the situation of any startup. But as the gears started moving, we saw milestones without a clear goal (or date) in sight, people reassigned to more important tasks prior to finishing what they were working on, and even deployment dates suddenly changing, sending to production whatever had been done up to that point.
As you can imagine, this created confusion among the team. The result:

• Testing was not done correctly and bugs were invariably included in every release.

• Features were frequently not finished on time (since that time could be anytime).

• Team’s morale was low.

• Client was close to unhappy.

Looking back on what went wrong

• No clear milestones. Deployments were vaguely scheduled and could happen without much of a warning, so we felt like in the middle of a dense forest mist. We were walking blindly with the feeling that we could stumble upon anything along the way. Deploying a feature asap or deploying a hotfix to squash production bugs can happen, but this must not be the norm.

• Bad communication. Part of being Agile is to be able to change features’ priorities and due dates, but that must be done in an orderly fashion and the development team should be informed of why. If it feels random, the whole team will be, at best, stressed out and pissed off, and in many cases seized by panic.

• No improvement. We knew things looked bad, the client too, but there was simply no time to reflect on it and discuss what had just happened. So nothing changed.

What did we do? We took over the management of the project

The project was heading the wrong way. To stop things before they got bad, we convinced our client to move the management to our side and enforce some of the Agile practices we normally use in our projects; in this case we started with a light version of Scrum.

• Iterations. Since continuous delivery was top priority we established one-week iterations. Suddenly the mist started to fade away. We could see, not far, but at least where we were stepping and where we were heading to. Our goal was no more just-any-day. Our goal was Thursday, no rocket science management, no complicated methodologies. Thursday was the day we deployed to production. We could look ahead to that day and once there look ahead to the next. Hotfixes and urgent features are now the rare exception.

• Communication. Since due dates were clear now, dev team could provide better estimations and feedback. If something got complicated and the deadline would not be met, a hand could be raised in time to do something about it. Everyone was informed and payed attention to, and in return everybody cared more for the project.

• Retrospective meetings were scheduled for Friday mornings. If anything went wrong, if anyone felt bad, if anything, now there was a time and place to say it. By doing so we were able to capitalize on best practices used in other projects and adapt them to the context. We improved small things such as writing better feature requirements, systematically including acceptance criteria and opted for a more appropriate way of handling merge requests. Practical things that, put together, made daily work much more efficient and enjoyable. One iteration at a time.

With these simple yet important changes we managed to not only completely change the mood within the working place and the attitude of the team towards the project, but also the productivity and quality of what was delivered.

Be prepared for change

Being agile doesn’t mean doing whatever, whenever. It doesn’t even mean that we should be prepared for that. Agile means being prepared for change, yes, and adapting to new requirements, new dates, and potentially big changes in the direction of a project. But no one can do such a thing in the middle of chaos.

If a two-week sprint is too big, maybe set deployments every week, or perhaps the project’s needs are such that you have to deliver on a daily basis. In any case, the organization is the key. Everyone should know that deployment occurs every day at 9:00 am, next Thursday, or in ten days, and that it will regularly be so.

There are other Agile processes such as Kanban, that may fit better your organization and team needs.

Uncertainty and flexibility will play on your side only if you handle them wisely. If they are on the loose, your whole team is on the loose too, and so is the fate of your project.