Agile Team Leading for Dummies

In the past several months I seldom wrote code. I wrote emails, I had conf calls on Hangouts, I wrote specs, with various degrees of detail. But code, almost never, unless it was an itch that I desperately needed to scratch now.

What I do is paving the way for others, so they can find neat, freshly-laid tarmac, proper sidewalks, streetlights, and so on, so they can run fast and smooth. I don’t do the work myself, I just give directions. I lead (or I try to). I have been tasked with designing a new software architecture,  and I did, and then we built a prototype, and now we are about to deploy it to production. That’s cool, you might say. It is, but…

The problem is that, more often than not, I find myself lagging behind others. I see them turn in the distance, set against a blazing sun, and ask me things – perfectly legitimate things. “How should this work?” “Should this be sync or async?” “Do we already have something for this?”

My answers always come late, because I have too many questions to answer – and this is the first warning sign. Let’s just assume that I do not delegate enough, which might be the problem.

Then, I get up in the morning, and I have absolutely no idea about what I’m going to do during the day. “Anything necessary to get the project to completion” is a good definition. At 6 pm, I get up from my desk, and I have no idea on what I did all day. I’m not joking, this is for real.

In a way, I feel like I’m stealing money from my employer. I feel like an impostor.

Enter agile.

The place I work at is, like any other largish IT organization, a mammoth with zero agility, pretending to be agile. This is fine, probably, it’s just the way it is everywhere. No surprise.

Deep down, beneath the facade of enthusiasm and goodwill, we all know agile is just a myth (or form of a cargo cult), and that software just can’t be considered a product by itself, very much like a building’s blueprint cannot be considered a product by itself. You cannot industrialize software development. When they tell you otherwise, call it bullshit and move on.

In this context, I constantly fluctuate between two states: a feeling of utter uselessness, and a feeling of helplessness.

  1. “What am I doing?”
  2. “What am I supposed to be doing?”
  3. “What I’m doing is useless.”
  4. “We are going to fail miserably.”
  5. Goto 1.

You might argue that we are doing agile the wrong way. That’s right, I say, tell me how to do something that doesn’t exist. Because agile, in its essence, is trying to do something complex quickly by breaking it down in small pieces. Nice finding! That’s called divide et impera, and Ceasar invented it quite some time ago. The problem is that his divide et impera was based on a rigid chain of command, while agile is based on people functioning flawlessly in each of their roles, and in every social aspect, to work together like a happy family. The word utopia comes to mind. But I digress.

With a non-zero number of bumps along the way, I do manage to get projects to completion, more or less on time, more or less working reasonably well, sometimes hitting the brick wall hard.

But, this constant state of mediocrity is slowly killing me. This constant, floor-rounded tendency to compromise is stripping energy away from me, one deploy at a time, one “we’ll do it in the next sprint” at a time. The backlog becomes a strictly increasing function of time. This constant just-below-total-chaos status is dragging me down one “damn, this is wrong! Fuck it, let’s change it on the afternoon of the last day of the sprint” at a time.

And I keep asking, “is it me? Is it my fault? Am I doing something wrong?” Yes, in part at least, but what bugs me is that I can’t know for sure, there are too many moving targets to track, too many unknowns. I know that I’m working at too many levels – from architecture down to implementation details – on multiple projects at the same time, but I also suspect that I can’t do otherwise. As I said, I do whatever is necessary. Duck and run, yell orders, open fire, dress wounds – in both armies.

When someone asks you, “do you have a couple of minutes for X?” and you never do, that’s the final, ultimate sign that what you’re doing cannot work. You’re going to break down, soon. You’re going to fail.

I don’t have a conclusion, I thought I had one, but I don’t – see how messed up I am? I couldn’t even come up with a proper title.


Posted

in

by

Comments

One response to “Agile Team Leading for Dummies”

  1. Dafne Avatar
    Dafne

    We also have Agile team too. They seem to be doing very cool stuff all the time, very creative, that mainly involves sticking post-it notes on big white boards, or even walls. I just love stationery and post-it notes in particular, and I’d love to spend my days scribbling on post-its (they have all colors, not just the old boring yellow ones the rest of us get). The company next door has reached an even higher level of post-it proficiency: they have used multicolor post-its to create pictures on windows – like mosaics made with post-its. It seems they had a competition and admittedly, they did produce some really stunning shit. But then they’re a creative company, unlike us, who still use post-its to write stuff on…

    Do you use post-its too? If you do, stop complaining and be happy – when I was a kid I would have killed for my own post-its, and we didn’t even have the colors, just yellow. If you don’t, perhaps you should introduce them?

    Take care,
    Lasora