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.
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.
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.
| Reference: | Agile (micro)Management from our JCG partner Ryan LaRue at the Keyhole Software blog. |
Thanks for the article. It seems like an often missing component of agile is a real commitment to continual improvement driven by effective retrospectives.
In my view the biggest disadvantages of agile development is that it affects the overall product quality of deliverables. It feels more like a rat race where all developers are “sprinting” to meet the deadline and be able to complete all their assigned tasks(jiras) before QA phase kicks in . There are always estimation errors and unforseen circumstances where by you may have to juggle between different non task related items such as production issues, responding to day to day questions raised by clients, qc, et. All these items are never accounted for. On top of that, you have to… Read more »
Kumar: QA phase? The way you described your process doesn’t sound like Agile at all. It sounds like waterfall mixed with some practices brought from Agile. Of course it doesn’t work…
The most basic misunderstanding is that having sprints and daily standups doesn’t mean you are agile. These are just some particular practices commonly used in Agile SCRUM, but not Agile itself, that is so much more.