Software Development Community Meeting (Photo credit: Michael Kappel)
At a recent conference, I attended a seminar on being agile. It was actually a seminar on Scrum, but using Agile as a label for Scrum is the big thing these days, I guess.
Anyway, the speaker told a story about how the daily standups revealed to a manager that one of the developers was making no real progress and, as a result, that developer was fired.
How many developers out there are all fired up about getting agile, now?
This calls to mind a time I was doing a presentation at the C-level for a company about agility, and I asked the question, “What’s the value in having the people actually doing the work telling you what the relative effort is?” and the immediate answer was, “So you can hold them accountable.”
Not, “Because that sizing will be more accurate coming from the trenches than management,” but because people could be more effectively and harshly disciplined.
I want to be clear that I am in no way about to say that team members should never be reassigned or even let go. Sometimes, as a last resort, those kinds of things have to happen for a business to keep moving forward. I will say this, though:
Part of being agile is recognizing that you are all members of the same team working on the same goals, and you will succeed or fail as a team.
If a person seems to be stuck on a task that doesn’t seem to be that hard, that person should feel safe saying, “I thought this was going to be easy, but it’s pretty complicated, and I need help,” or even, “My dog died, yesterday, so I apologize to the team, but the truth is that I didn’t get a lot done.”
On the other hand, the team itself has a responsibility to reach out to this person even if they aren’t forthcoming. If a co-worker seems to be working on the same thing all week and it was a fairly small backlog item, go to them. Say, “Hey, I noticed that your item seems to be sticking. Can I help you with it? Do you want to trade backlog items?”
Agility promotes transparency, and this can either be terrifying for your team or it can be edifying for your team.
The purpose of transparency isn’t to more effectively blame people; it’s to more effectively help people. It’s a recognition that, at some point, we will all be the weakest link. At some point, what we thought was easy turned out to be difficult. At some point, a highly-skilled professional will find themselves in the middle of a problem and have no idea how to solve it. At some point, a manager will completely de-rail the project. Transparency shines a light on these issues so we can work together to resolve them, not throw darts more accurately.
Does your team work this way? Do managers and developers realize that they are working together to accomplish a goal? Does everyone realize that accomplishing the goal is more important than doling out blame or punishment? Does everyone understand that working together to solve a problem is far more valuable to the business than accurately blaming someone?
The person telling the story about the underperforming co-worker getting fired held this up as an example of agile success. To me, it was a sign of dismal failure.