How to mess up an already messed up schedule

In the recent past, I have found myself where no project manager wants to be. A deadline is fast coming and despite commitments from the developers, unless Jeff Dean joins the team you are screwed.

I will admit, on the way here I made a lot of mistakes, the most important being I failed to bound my uncertainty. You see when we started missing key milestones, I knew for sure we would not make the release date. The problem is I didn’t know how much we were to miss it, would it be a day? a month? a year?

In such situations, panic is practically inevitable. It’s only the most sophisticated companies that don’t jump into the code and fix model at the expense of a solid development practice.

In this entry, I will be sharing some of what I learnt and what we did to get to where we were.

Add more staff

If takes 5 painters 8 days to paint a house, how long would it take 10 painters to paint the same house?

You must have come across such a question in your high school math. How well do you think it plays out in the real world?

Suppose the contractor painting the house is in a tight market, after the first 5 expert painters, it became much harder to recruit new painters so the remaining 5 are either novice or intermediate, how does the math work out then?

What if the house must be painted sequentially?

What am alluding to is the ideal situation never plays out in the real world. These models gloss over a reality known to all managers, people are fundamentally unequal, diversely endowed in mental capacity, agreeableness and stick-to-it-ive-ness.

Further, new members are generally not as productive, no matter their technical knowledge, they are lacking in domain knowledge which is arguably more important.

In short, when its crunch time, you are better off sticking with your existing team.

Cancel continued education

Let us think for a second about the painters from the last section. If you are the owner of the house and you know there is a tornado coming your way, would now be the best time to be painting?

When faced with a crisis, the immediate reaction is to shut down all optimistic activities. What is the point of learning if you will never get to use the knowledge?

In this case, continued education will act as our proxy for all long-term capacity building activities which have no immediate tangible benefits.

The problem with this approach is you never really fix the fundamental problem. For example, when we noted a certain technology was not working out, the solution was to double down on what we already knew, this solved the problem then but later the same problem manifested but now in a different form, new features suddenly had an exponentially longer delivery time.

Even in the most dreary of times, you can not afford to ignore the education of your developers. It’s one of the key factors which when there encourage motivation and when not there drain it.

Extend the work day

There is something visceral about seeing people in the office doing the work. Just like the number of painters problem, the number of hours per painter is a variation of the same kind of thinking.

Here is what David Allen has to say on the topic:

 How much does it take to have a good idea?  Zero.  You don’t need time.  You need room in your head

I don’t believe any developer can code continuously for more than 6 hours. Add in breaks and you have a hard limit on a 9 hour work day. Anything more and you literally have zombies in the office, let them go home.

Software development is a creative exercise time does not matter as much as clarity of direction and mental space to think through ideas. This arises naturally when the developers have had a chance to rejuvenate themselves and spent time with their families.

Further, an insidious outcome of this move is people find a way to compensate. Suddenly people are sick more often or even just spend more time goofing around.

In conclusion, when things go wrong, don’t panic, orient yourself to the new reality come up with a revised plan and stick to the process.


Managing constructive disagreement

I am a big fan of constructive disagreement as you may have noted from a previous entry Working with sceptics to new practices.

To understand why you need to see how we usually consume information. For example, if you come across the statement:

Alcohol boils at 82C

What is the chance that you will stop whatever you are doing and confirm this fact?

Now imagine if you were in the middle of an argument with someone about which temperature to set your distiller, they say 78C you say 82C. Now, what is the chance you will actually take the time to research on this piece of data?

You see, arguments help us kick in our reasoning, Hugo Mercier and Dan Sperber in their paper Why do humans reason? Arguments for an argumentative theory state:

Our hypothesis is that the function of reasoning is argumentative. It is to devise and evaluate arguments intended to persuade. Reasoning so conceived is adaptive given the exceptional dependence of humans on communication and their vulnerability to misinformation.

Now obviously being in the middle of a disagreement is no fun, in this entry, we will be looking at what I think are some good practices to manage profitable disagreements.

What is the history of the team

Every team has a history. Sometimes you find yourself in a situation where some members of the team have nothing but vile for their colleagues. You can usually tell by the thinly veiled contempt remarks being thrown around.

In this kind of situation, no argument is worth even pursuing, your focus at this point in time should be in fixing the broken relationship.

It is no use trying to establish who is right, simply focus on forgiveness and the need to cooperate before anything meaningful can be done.

Keep calm

People generally have two natural conflict management strategies. One camp can be described as conflict seekers the other as avoiders.

The seekers have no qualms about speaking out their minds while avoiders will seek to preserve the relationship.

Personally, I am an avoider, I prefer it when everything is going smoothly and see no need for an argument for arguments sake. Yet I understand always avoiding conflict is the route to becoming a doormat.

It is imperative you understand your own disposition as well as your team members’. In this way, you can manage unproductive behaviors when they rear their ugly heads.

From seekers you can expect:

  • Public ridicule or insult of the other party
  • Shouting over the other decisions
  • Strong arming

From the avoiders you can expect:

  • Storming out of the meeting
  • Agreement without commitment (worse than disagreement)
  • Disengagement

Furthermore, don’t let yourself get lost to anger. Yes, it usually gets everyone in tow but at the cost of psychological safety.

Have some ground rules

You can not manage disagreement by fiat. Even if you get everyone to agree with you, what you now have is compliance not commitment. Even worse, you can find yourself dealing with a full blown mutiny.

Most developers are already sticklers for doing things right. Thus when there is a point to be made, avoid mystique about where you are coming from.

Focus on the process of arriving at decisions rather than the decisions. There is a reason rule of the law works better than the wisest of kings

Some sensible ground rules would be:

  • Don’t interrupt a speaker
  • Don’t use the phone or laptop as the other person is speaking
  • Always respect meeting times

Maintain participation

A disengaged individual literally sucks the energy out of the group. It is simply more effective to have the person not in the room at all.

I find one of the greatest joys in this world is intellectual communion with peers on matters of substance. I believe as long as you keep the conversation meaningful, there will be participation.

With that said, some people just don’t do well in big groups. In particular, you may end up with a situation where only the ideas from extroverts are brought to the fore and argued out.

To bring in the more silent introverts, you may need a different form of participation, say by having people either split up into small groups of two or three to discuss or write out their opinion on a piece of paper and send it to the front.

How do you deal with disagreement within your own teams? Talk to me in the comment section below or on my twitter @jchex


How to communicate your release plan

A release plan is simply the dates you expect to deliver on major milestones for your project.

The beauty of scrum and its sister methodologies is there isn’t too much ceremony around this information.

Really, once you get past trivial projects, you very quickly realize what is to be built is not very well understood. Any plan you come up with that ignores this fact is guaranteed to become a source of pain in the future.

I see planning as a search for value, if well done, it helps us answer the most important question for any software team. What should we build?

Its a consideration of the features, resources available and important dates. This then illuminates a possible path for development.

I find it ridiculous that some people write a detailed document complete with dates and then think they are done with it all and no further revisions are needed. A release plan should reflect the current context. This means the format you choose should be one that helps you best express your most current thoughts.

In this entry, I will be looking at some of the formats I have found useful for communicating release plans.

Outcome buckets

In a previous entry, I talked about Why I don’t assign deadlines by date

For context here is how tasks bucketed into weeks would look like.

Well, as it turns out, planning your tasks as such is also really good for presentation. You can very easily get a sense of when you expect things to be completed.

Even better, the system communicates a level of uncertainty, because you don’t have an exact date for any of the tasks, you know it can be delivered on any date within the bucket and the plan would still be true.

For highly uncertain outcomes, you can increase the size of an individual bucket, say to 1 month. This communicates to all stakeholders there is much more risk to the outcome but we will get it done early if we can.


Maybe it’s my finance background talking, but I must say I love spreadsheets!

I find it to be one of the most powerful tools to establish coherence of thought within whatever your team is working on.

As part of our communication kit, spreadsheets allow us to play around with the quantitative bits of our plan. For example, if we need to model what would happen if a story point takes 5 days to develop as opposed to 3 days, it would be trivial to do so with the tool.

There is a perception in the business world anything on Excel is more serious than on a goofy tool like Trello. The perception is wrong but since its there, why not make use of it?

Gantt charts

A Gantt chart is a staple of the project management industry. They are highly visual and easy to understand. As you can tell from the fact am using a stock image here, I am not the biggest fan of them.

TeamGantt sample
TeamGantt sample


The problem I have with Gantt charts is it doesn’t communicate the uncertainty inherent in any software project. Furthermore, when a date changes, you don’t immediately see how such a change escalates across all other tasks and further how the other outcomes are now more likely to take more time.

Not all of it is gloom and doom, because of its visual nature, its far easier for non-techies to grok it over say a spreadsheet.

Furthermore, for a high ceremony executive, a Gantt chat will likely fit better with the rest of the reports they have to go through for the rest of the day.

How do you communicate your own release plans? Talk to me in the comment section below or on my twitter @jchex