Web Development Business

Agile (micro)Management

Ryan LaRue Agile, Dev Methodologies 2 Comments

Is Agile Development making your development team dread coming into work?

Several years ago, a company I was new to had been pushing the need for agile development. After numerous meetings, discussions and even some training, everyone was excited and ready to roll.

Only a few weeks after the agile onset, however, I asked a developer how he was liking the new practices.

His unfiltered, honest answer (per his usual – sometimes hilarious – manner) was: “Meh, it’s just another way to micromanage”.

Over the next several weeks, I found that he was not alone in his feelings. In fact, every single developer, some of whom were in the process of finding a way out, felt the same way.

In the interest of avoiding this problem in the future, here are some takeaways I learned as I continued to work with this team.

Don’t ignore the early red flags

Daily stand-ups at this company, which were officially allotted the industry-standard of 15 minutes, would routinely run over – sometimes taking an hour or more. Big team, you might surmise? No, the stand-ups always included less than 10 people.

Stand-ups running too long is often one of the first red flags that a cancer may be setting in on an agile team, and the quicker things are brought back to where they should be, the less chance that the cancer takes over the whole team.

After attending a couple stand-ups on this particular team, it was pretty obvious why they were taking so long. It was also imminently clear why the developers were feeling so micromanaged…

Micromanagers should not run the stand-ups

The main problem, I believe, was that the wrong person was driving the stand-up – namely, whichever PM had been assigned to the project.

By their nature, and indeed often their job description, many project managers are micromanagers. While this can be a good thing for their chosen profession, it means they are more likely to steer the discussion into too much detail, especially in the areas of resolving roadblocks and meeting deadlines.

See Also:  Microservices Anti-Patterns

For the developers, the morning stand-ups became a little piece of hell they were able to look forward to attending first thing, every morning. Needless to say, they basically began to dread coming into work.

Whomever is driving the standup, whether it’s a PM, a team lead, or someone else, he or she should basically be nothing more than a familiar voice to start the meeting and maybe a silent note taker. If he or she can’t constrain himself or herself to that role, then someone else that can should drive the stand-ups instead.

Is this really agile development?

There were other major issues with this team, like the fact that there were no voting sessions. The project managers and business analysts would create project milestones, wrap stories around them and a developer would then be assigned to the project.

It didn’t take a genius to realize that this team was not, at all, practicing agile development.

Unfortunately, this is not uncommon. A company may claim to be an agile shop but – whether intentional or not – reality is often quite different.

It all comes down to TRUST

The developers on this team were not feeling valued, and rightly so.  There was a palpable distrust emanating their way from several departments – a distrust which was, by the way, completely unwarranted.  These were (and are) good developers and they deserved the respect and trust that a micromanaged environment cannot provide.

Personally, I favor a more laid-back style of agile development, utilizing a max of 3 stand-ups per week, task-less stories, and other practices that would make a micromanager pull his or her hair out.  Part of the reason I favor this style is because I feel it instills that feeling of trust this particular team was missing.

See Also:  Working Remotely As An Agile Dev Team: Tips & Suggestions

I like to share the following guiding principle with any new team: We’re all professionals, and we’re all adults (until proven otherwise).  That principle serves as my promise that they won’t be micromanaged, but I expect them to get the work done in a professional manner.

So, plain and simple, do you trust your developers to do their jobs in a professional manner, or don’t you?

Granted, every team has its own nuances. So there needs to be someone on your team who has the ability to feel out which path should be followed at the current time.

Is it time to reassess your agile practices?

As the story about the company above illustrates, a great place to start assessing the current state is simply by talking to your developers.

Ask them if they feel valued and trusted, or if they just feel micromanaged.

If you consider yourself an agile shop but you hear some answers that lean towards the latter, it’s time to take a serious, objective look at your agile practices. Afterwards, don’t be afraid to make the necessary tweaks or even big changes.

In the long run, the entire team will be more productive, happier and, as a bonus, won’t have a sense of dread as they come into work to face those morning stand-ups.

Comments 2

  1. Stand-ups are a dark side of Agile. I’d rather have a less-frequent, useful meeting, or even produce a short periodic written status. Okay, now I’m started …

    I used to LOATH LOATH LOATH the morning stand-up. When it was over, I could begin my productive day. Why was the client paying me to be unproductive? It was supposed to be a quick reporting of blockers, progress, and what task or defect was to be worked on next. Almost never quick. Almost never useful. I believe the information went unheard, as indicated by later emails.

    Not everybody on a project is necessarily interdependent. Not everybody listens to what’s said. Most of us were mentally rehearsing what we’d each say at our turn! After their turn, many were waiting for others to shut up so we could go to work. The stand-up was simply a crank to turn before we could work. Many times, information I shared was apparently unknown to the team a half day later.

    We used tools like JIRA or Rally, and moved story cards around. We made comments in the stories and defects. There was a mechanism to indicate blockers. Why didn’t those tools, with their pretty reporting formats, suffice to let the PM see the status of the project?

  2. Ryan LaRue Post

    I wouldn’t disagree with a word of that, Lou. But, ya know, you and I have seen it/felt it/endured it from the developer perspective – and something is telling me that may be important
    To me, this discussion helps make the argument that the person creating/leading the agile practices on any team should come from the development side rather than the business side. I’ve seen it done both ways.

    This obviously does not mean that the business side should not be involved at all. A competent BA creating the stories to be voted, helping prioritize those stories, and helping load the sprints is of HUGE benefit.

Leave a Reply to Ryan LaRue Cancel reply