ScrumMaster Can Be A Blocker

scrum master is a blocker I was intrigued by this article from InfoQ about the role of ScrumMaster as a blocker.

Personally, I hate office politics.

I think they’re are complete waste of time. They zap my energy and leave me feeling frustrated and angry.

I guess there’s an argument here that playing political games protects the team from people that don’t buy into the team’s approach.

I can kind of see their point. But encouraging such a political approach seems to be a bad idea to me. If you can’t debate the pros and cons of an approach – and win or lose the argument on an open and professional basis – I don’t think this is the answer.


3 Responses to “ScrumMaster Can Be A Blocker”

  1. Anonymous says:

    Scott Ambler seems to get about; he’s recently spoken at a Games Developer Conference, talking about how Agile might work in a game-development environment. Who knew that working with Agile could move us all towards the dream of making video games?

  2. ben ross says:

    The terms agile methodology, scrumm and blockers and all the associated bulls*** is a complete waste of time and brain space. Nobody is truly agile, everyone is secretly waterfall and does everything the same way they always have. What a complete load of managerial crap’ola.

    I was reading an article a few weeks ago which measured the effectiveness of Agile and the new philosophy or way of working compared to a traditional workflow. To surmise, the agile projects that were delivered took just as long as the waterfall approach, however the functional teams in the agile space were much more stressed which resulted in arguments and disagreements. This in turn cause a high level of attrition and churn within the groups.

    A successful project can be measured in the outcome traditionally, however in reality, it’s the journey getting there that deems if this was a successful project. Most, if not all agile projects are failures in this respect.

    In my time managing and working on numerous projects, I have not seen one Agile team deliver anything better than a waterfall one…. period.

    In conclusion, this is no more than a concoction of terminology, theory and noise for managers who don’t know how to manage workload or talk to their staff. Any attempt to create a practical application of agile methodologies soon results in the ‘secret’ waterfall approach because agile was not working for them, but they talk the talk to convince themselves and others otherwise.

  3. Kelly Waters says:

    Hi Ben,

    Sounds like you’ve had a lot of bad experience of agile. Your comments certainly don’t echo my experience at all. In fact I have seen agile reduce the stress a team is under quite significantly, particularly when moving from complete chaos with everyone shouting to get stuff done to a process that is more orderly and structured. Having said that, agile does feel quite chaotic when coming from a much more formal waterfall approach.

    The other benefit I have seen (one of many) is the advantage of releasing the software incrementally and much more frequently. I respect the fact that this isn’t possible for all types of projects – some just can’t be released until it has ‘all’ been done. But I have seen many projects deliver incremental benefits along the way, while the team carries on delivering remaining features, and that has carried quite an upside from a business perspective.

    If the fundamental practical difference between waterfall and agile is writing the whole spec up-front and doing all the user testing at the end, versus delivering one small feature at a time and testing it as you go along, I would never do waterfall again.

    I agree with you about the terminology. Coming up with lots of jargon and making agile seem like another language was a mistake and was presumably just for the commercialisation of it as a methodology. But agile can work, I’ve seen it many times.


Leave a Reply

What is 1 + 9 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)