Optimize for value, not busyness or resource utilization

Recently, in several different project conversations, there surfaced an amazing argument.   The exchange went something like this:

-          We need to do X, Y and Z, since these are most valuable, risky and fundamental things for the project.   Once we complete X, Y and Z, we’ll be able to make other important decisions and move on to the following priorities.  

-          But doing X, Y and Z only requires XX people. Our team is XZ people.  We need to pick something else, to make sure everyone is busy. 

There is value in doing the best known and most important pieces now, and there is value in postponing decisions until the last responsible moment.  There is no value in making more people busy. 

Entry-level microeconomics courses offer this example: more chefs in the kitchen allows for more pies cooked, but only up to a point.  After that, adding people actually reduces productivity.

X axis: number of people on the team
Y axis: overall productivity of the team, number of widgets per time period

The concern is overall productivity of the team, measured in value delivered to the customer.  Number of people and working hours is only important if it is too high. People-hours metric is completely irrelevant when it is lower than certain allowed maximum.

If X, Y and Z are the most and only valuable items to work on right now, that is what the team should work on, and nothing else.  People, whose skills are not needed at this point in the project, can go home, learn some new skills, provide peer review to others, work on setting up infrastructure, etc.. The important part is to optimize for the project value, and not for resource utilization.

Agile teams: location matters

A team is the single most important point of success or failure for a project. Team culture and leadership have a great influence on productivity, and team communication is essential for effective and sustainable product delivery. Co-located teams have a better chance to create great team culture and leadership, than teams that do not communicate face-to-face. Interacting in-person helps build trust and respect, common vision and shared responsibility faster and more deeply.   

Having a fully co-located team requires an open-space environment, set hours to maximize face time, and sometimes even lunches together, so that the team spends the most time in face-to-face interactions.  In the pursuit of co-location other valuable things get dropped. Better specialists are not willing to work the exact hours, or are not available in a set location. Introverts suffer from too many hours in the open-space environment. And, because all communication is face-to-face, the team never has to develop the skills to communicate in any other way.

However, while co-location brings a significant benefit, it also comes with a cost. Getting every member of the team in the same room at the same time for the duration of the project often requires a change. Sometimes that cost is trivial. For example, if team members are scattered around the organizations' campus for historical reasons. Co-locating a team like that is as simple as designating a team room, arranging furniture in an open pattern, and moving the team members over. Chances are, the organization is better off getting the team co-located, and reaping the benefits of improved team dynamics. But there are plenty of situations where co-location is very expensive - or even impossible. For example, a project team must include a specialist who resides in another city or country, or a key person on the team has to work from home some days. Co-location may not be an option, but the team can still deliver. 

It is harder to build Agile culture of trust, open communication and shared responsibility in a distributed team, but it can be done. Communication is a skill, one that teams can develop, if there is the will, training, and positive reinforcement.  Remote teams can get very good at communicating using different channels.  Regular (or even occasional) travel to get the team together allows to build strong relationships, that last long after everybody went back to their original, possibly far away, locations.  

There are many distributed teams that do great work, are Agile, deliver value, and enjoy great team culture.  Co-location is one way to achieve these goals, but it is not the only way.

Join us on May 17th at Minute Maid Park, Houston, TX

Estimation agility

How good are your estimates?

Well, it depends.  If the project is slow-moving, the team is stable and has been at it for awhile, the platform is well-known and doesn't change much, and requirements are more along the lines of “get me some more of this”, rather than asking for something completely new and unknown – maybe the estimates are right on the money.  For the rest of us, working in the real world and on real projects, with real people involved, estimates are mostly guesses, often – very bad guesses.

Yet there is all that great pressure to get the estimates right early on.  The business side needs to know how much will be done when.  The clients have to understand when the product will be available for use.  Marketing is in dire need to make an announcement.  It has to go into the contract.  Salesperson already swore to it on building manager’s dog’s grave.

The estimate, which is often pure guesswork, rules the fate of the project, the development team, the customer’s hopes and the business success.  Never mind that the guess has been made at the worst possible time, when hardly anything is known about the project and no patterns have yet been established.   Rather than iterating on estimates, deadlines, project scopes, the tendency is to push for more overtime, less testing, more risk-taking – and more blame going around.

If the estimate is wrong, there is very little the project team can do to overcome an overly aggressive or too-far-out estimate.  Adding or removing people, and making the team work more hours has been shown to waste resources and reduce quality, rather than increase the speed of development.  Piling pressure to work “better and faster” helps even less.  

The only reasonable solution is to iterate on the estimate, refining and re-setting expectations as the project goes forward and new information becomes available.