≡ Menu
Pawel Brodzinski on Software Project Management

Agile Bullshit: Your Organization Must Be Agile to the Last Bit

Agile

One of things you’ll read every now and then is your whole organization has to be agile or your team won’t be truly agile. Here’s a good example:

When I hear management say things like ”We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.

Or someone will create a survey for you to tell whether you’re still doing Scrum or rather infamous ScrumBut.

Every time I read something like that my reaction is the same: “OK, I’m not truly agile (whatever it means). So freaking what?

First thing here is I know a lot of examples of agile techniques being implemented in highly formalized organizations. The trick is to build bridges between process existing outside of the team and Scrum or any other approach used within the team. If these bridges work well and people on both sides are able to easily match their roadmaps you don’t need much more.

Another myth is that agile team shouldn’t (or even isn’t able to) build reliable long-term project plan. What a bullshit. Actually any team, no matter which approach they use do develop software, should be able to build reasonable project plan as long as they employ reliable estimating technique. If you’re perfect in estimating stories in story points why can’t you spend some time estimating the whole big ugly product this way? Will your brain blow or something? Is it forbidden to use other estimating techniques like Evidence Based Scheduling if you work with agile? If so, no one told me.

Besides that, if my chunk of organization works as well-oiled agile machine and I don’t even know how other tens or hundreds chunks of company work does it mean I’m not agile? Come on. I bet IBM or Accenture has some hardcore agile teams doing some stuff for customers who appreciate and expect working with agile teams. Should we blame these teams for working under the banner of huge corporation, which as a whole can’t be called anything like agile?

After all, agile is just a label as any other. The label itself doesn’t make you produce better software. Practices do. If someone tells me I’m not agile because I don’t do stand-ups, screw them. As far as my approach lets the team developing good products I don’t care about labels.

All posts of The Carnival of Agile Bullshit.

in: project management

9 comments… add one

  • Allison March 17, 2010, 2:36 pm

    this post sums up one of my pet peeves with Agile zealots: Long term planning. I actually had an Agile person tell me, with a straight face mind you, “that any type of planning is wrong, if you write it down, you’ve created a document that will be wrong so why do it in the first place?”

    This same logic was used for requirements as well.

  • LuNell March 17, 2010, 3:38 pm

    The Agile/Scrum world is definitely difficult for Sarbanes-Oxley and internal auditors of highly regulated companies. Where are the artifacts? Where are approval gates? Auditors are looking for requirements doc, design doc, test plan, test summary – documents – to ensure IT’s engagement with the business, best practices have been followed and that software that was deployed was what was actually tested. I have yet to find how Agile addresses this – but if anyone knows, please speak up.

  • Pawel Brodzinski March 18, 2010, 1:43 am

    Allison,

    Arguments about long-term planning being wrong and useless are just stupid. Situations where you build something but don’t exactly know what are very rare so almost always someone has to have long-term plan which is a roadmap for the team.

    Actually Scrum doesn’t say you shouldn’t have a plan or you shouldn’t gather requirements. There can be different names used (user stories, product backlog) but goals are pretty much the same: learn what your clients/users want and organize it in some way. This may be more or less formal but I don’t believe Product Owners just randomly chooses whichever story/feature should be completed next.

  • Pawel Brodzinski March 18, 2010, 1:54 am

    LuNell,

    I can’t give you an answer for a specific environment you have in your mind. However I know how formalized was the process in Motorola (Krakow office). What people hated there is how much documents they had to produce because of small changes in code and how long they had to wait to see their changes live in the product.

    And they implemented Scrum in a couple of teams there. They didn’t stop to produce all required documents but they changed the way they worked within the team.

    The whole trick was to build some kind of umbrella above the team. On the top of this umbrella everything looked exactly as the process required: documents, artifacts, plans etc. Under the umbrella they had user stories, product backlog etc. Yes, they had to do additional work (I guess it was Scrum Master who dealt with it) of translating one reality to another back and forth but they worked at better pace.

    Incorporating scrum into big ugly process is possible although it requires significant effort. This investment may but doesn’t have to be a good one – you have to decide individually in each case. But it is definitely possible.

  • James Briant March 18, 2010, 10:29 am

    Allison,

    If someone told you that, then they are not an Agile zealot. They are just wrong, and I share your pain. I am a certified scrum master, and I can tell you that my biggest frustration is getting teams to create that long term plan. I also understand their pain. Long term planning is “hard”, because, frankly, it forces Mr Big to confront the fact that Shiny 2.0 can’t have Magical Feature if he also wants it to ship in three months. It forces Mr Geek to confront the fact that a qsort will suffice, instead of Book-Deal Algorithm. There are so many interests arrayed *against* long term planning, except the one that is important: We Get Paid To Produce Working Software. It can be quite a shock.

    Jamie

  • Olga March 18, 2010, 12:36 pm

    Pawel. Great post. And funny in a way though :) The thing is that I’ve seen similar posts like 3 or 5 more times and it makes me wonder if anything is really new in this huge blogosphere? I guess folks are just writing about their own personal experiences – and then it turns out that someone else has already felt the same :) For one more example of such a train of thought regarding “are we agile, are we not agile”, that dates back to October 2008, see our blog post :)
    http://www.targetprocess.com/blog/2008/10/are-we-agile-yet-grrrrr.html
    Yours respectfully :)
    Olga

  • Pawel Brodzinski March 18, 2010, 12:50 pm

    Olga,

    I wish I wrote this in 2008 too. It’s no surprise you see similar arguments on and on. First, people write about their experience and it looks like it isn’t just me who sees a problem here. Second, you see people trying to test your agility or stating that you must be purely agile every now and then and that’s how we can response.

    But yes, there isn’t much new there. We keep telling what we learned and others independently learn the same thus tell the same.

  • John Quincy October 18, 2011, 6:11 pm

    In a related video… http://www.youtube.com/watch?v=nvks70PD0Rs

    Respectfully,
    John

  • Fareed Quraishi August 13, 2013, 10:24 am

    Well written and very agreeable. Noted there are a lot of Agile Zealots and I myself have been caught in that loop arguing what is with what could be. Anyone saying they are doing Agile or saying someone is not doing Agile is malarkey. I like to lean on something I heard from videos of Jeff Sutherland or Martin Flower, that Agile is an emotion. There is the values, and our integrity to strive towards those values. Every cooperation will have different way of incorporating them. The way you are positioning things it seems more like an Agile Coach or the PMI-ACP accreditation, where we can’t do everything but what applies best in this situation.

Leave a Comment