Are One-on-Ones Good in an Agile World

When my last company transistioned from Waterfall/Iterative to Agile, we debated whether we should get rid of 1-on-1 meetings with individual performers. Since we were encouraging teams to become self-managing, there was an argument to be made that we should encourage each team to replace the role of the 1-on-1 meeting with ‘Management.’ However, we chose not to and I think that was a good idea. Here is why

  • Things will not go as planned during your roll-out. Something alwasy goes sideways and not everything can be fixed within the team dynamic. There was a lot of encouragement to work through as many team issues within the team but some were intra-team or intra-group and needed to be dealt with in a different manner.
  • Allowed individuals to speak freely in a ‘safe’ environment without any team dynamics. These are typically “Am I crazy for thinking this” moments. They may have received encouragement to deal with a team dynamic gone awry but it gave them a place to work through the issue before diving in.
  • Agile and especially self-managed teams was a new concept to us all and we had to work our way through the process.
  • Teams are all well and good but some things are personal and not the team’s business. This allowed the team members an alternate channel to bring issues that were not team related. Regular meetings with Management allowed it to not be a scary thing. It was a perfectly normal communication channel.
  • While the focus is on the team in Agile, personal development is really the team member’s role and a 1-on-1 allows management to mentor the individual outside of the team. Again encouraging a healthy communication channel with each individual is always a good thing even in an egalitarian team environment.

What is Wrong with Fixed Price

Government agencies either by preference or by statue tend to issue firm fixed price (FFP) Requests for Proposals (RFP). The draw is that costs are capped and the contractor assumes all the risk. From a lawmaker’s point of view, they look responsible and frugal. This is extremely misleading for several reasons.

Scope

By definition, the only thing the contractor can control is scope (and schedule to a lessor degree). Unless you have a project with little or no unknowns or your team has the world’s greatest requirement writer, this tends to become contentious. I have literally had conversations with clients where they knew what they meant and I knew what they meant but it did not say that. You build exactly what was asked for. If a better idea comes up, hey great, write it up, scope it, cost it and send it to the Change Control Board.

Customers

Most contractors love to delight their customers but FFP forces both parties to fight tooth and nail over what every requirement exactly means. I have been involved in many different customers at both the state and federal level and have spent ungodly chunks of those contracts pouring over contracts with the client . This wastes an inordinate amount of time. Time that would be much better spent building what you are supposed to be building.

Flexibility

FFP also allows little or no flexibility. Yes, you usually have a Change Control Board but now you have made the process slow. You interrupt the whole flow of the project. You make the process cumbersome. The project can turn but like a carrier group it takes awhile and you keep losing momentum.

Not So Hidden Costs

  • Endless debating about what a requirement means rather than building the requirement
  • Paper. Paper defines FFP. You have the requirements, the SOW, the contract itself, the change requests, the massive amounts of contract documentation, the ponderousness of the whole process.
  • Time of course. Time debating. Time debating change requests, time writing them, time deciding them. Time not delighting the customer. Time no one will ever get back in their lives.