| Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work. Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week". This is why in Agile we have the Scrum Master who fields all requests like that and tells Marketdrone A to fight Marketdrone B on whose task is more important, because team only has enough time to complete either task on the next sprint. Every time someone tries to interfere with the team's work they firmly direct the person to the SM. In a few actual cases the team's SM has physically removed the over-eager middle manager out of the team's space with their "few quick requests and improvements". I'd really want to know what kind of tasks can't be completed in two weeks in your opinion. The tasks in a sprint aren't "build a house from scratch" -level, you split them until they're in manageable chunks of time. In a single sprint you might have the task of clearing the plot from any trees and laying down the markers for the house's base. Then the client comes in and approves the direction or asks you to make the bathroom a bit bigger or move the house 5 meters to the east - which is still easy because the "house" is just stakes in the ground with string connecting them. And again you pick 2 weeks of work you know your team can finish and the client checks that everything looks good. etc etc. It really isn't complicated. I think the majority of HN has only been subjected to cargo-cult Agile or some kind of Agile-ish system where you just use the terms, but none of the actual processes. |
If it's implemented well it's fantastic. You get to focus on the important stuff during the sprint. Issues tend to get caught early on because experienced team members chime in during planning poker. The whole team takes responsibility for the sprint together. This leads to lots of knowledge sharing and collaboration within the team.
Once the team velocity is predictable it also becomes much easier to ask for x amount of time per week for refactoring work as the impact to project timelines can be easily quantified.