Surviving the management landmines in an Agile environment

Sounds familiar?

This post aims to give YOU - The zen developer / leader - some hints at surviving the management landmines in an Agile environment.

Without implying that your boss is incompetent, the fact is that the Agile way of project management is new and there are a lot of misconceptions lingering around. Here are some things you might hear your boss say and some hints about how to respond to them.

"Agile is flexible." - implying - We can pull people in and out of the teams and can keep changing the requirements at any point of time.

Make it immediately clear that the features and requirements are flexible and can keep changing. But the team and the requirements do get locked in for the duration of an "Agile Sprint" which generally varies from 2-4 weeks.

"There were 10 features out of which 3 could not be delivered in the sprint. You failed!"

Predicting software delivery has never been a walk in the park and when it comes to predicting the delivery in a short period of time it can only mean risks and uncertainties.

"At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." - Agile Principles

Agile is not magic. An Agile team understands its velocity, improves efficiency and evolves over time. This results in better estimates in future but only when given some stability to the team. Too many new additions (or subtractions) to the team? Make the risks clear to your boss and assure stability over time.

"Its only two days to code delivery date. We don't need automated unit tests. Just write the code, make the UI presentable and we're done."
Agile and BDD/TDD go hand-in-hand. If you don't write tests, the future iterations become unpredictable. In my experience, strict adherence to BDD / TDD helps you deliver faster (once you get a hang of it) or with little deviation from the original estimates. Make your boss aware of the future risks that it would pose to the project deliveries if you do otherwise.

"You wanted three people. Take this guy and these two interns and deliver the project"
Agile assumes that the team is made up of professionals who are highly motivated towards meeting the goals. You may have a few inexperienced people in the team but that arrangement works best if you can pair them up with some highly experienced developers for a few sprints. Make your boss aware that Agile is not a short-term quick fix but a way of delivering quality software in predictable time frames but the team might take a few sprints for it to happen.

Can you recall similar conversations with your boss? I would love to hear about them in the comments.

What's your estimate on your project?

The legend has it that in a big corporate meeting the youngest guy in the team stood up against the Senior Director of their business unit over his belief that "Every software is unique and you can't estimate its delivery dates. If you do then if you don't meet the dates, its disheartening for someone working day and night to achieve the goal. So why estimate in the first place? Just press the pedal to the floor and deliver at the earliest.".

But there was a mutual consensus at the end of the meeting that over a period of time, on an average, similar software solutions take similar time to code. Which could only mean that it was possible...

The Director was kind and patient. He later met this junior guy and appreciated the honesty and asked if this junior guy would some day want to lead a team of developers?
The junior guy said "Yes." promptly.
The director then asked if the stakeholders would be eager to know how long the team would be able to deliver the software.
The junior guy said "Yes." again.
The director asked - "So, how would you learn to estimate?"
"By experience" was the reply.
The director asked - "How would you gain that experience?"
This hit the junior guy in the face. Both he and the director knew what he was thinking.
The answer was - "By estimating regularly".

The junior guy had learnt early in his career a very important lesson which later helped him give estimates better that Dilbert.