Sounds familiar?
This post aims to give YOU - The zen developer / leader - some hints at surviving the management landmines in an Agile environment.
"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.
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 howAgile 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.
to become more effective, then tunes and adjusts
its behavior accordingly." - Agile Principles
"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.
No comments:
Post a Comment