≡ Menu
Pawel Brodzinski on Software Project Management

Agile Bullshit: You Can’t Do Agile, You Must Be Agile

Agile

If you read about agile you must have heard it: you better be agile instead of doing agile. Or I should say Agile with capital A (as if it would make any difference).

I don’t get it. I always thought that agile was in the beginning just set of general principles you should follow. Then different agile techniques appeared, Scrum being the most significant one, which were just a set of good engineering, software development, project management and team management practices. Set of practices.

And somehow people started treating it as a religion or something. They tell you to be agile. What does this mean anyway? Do I qualify if my stand-ups don’t look like vibrant exchange of information? Well, I don’t do stand-ups so I don’t qualify anyway.

That’s horrible! I won’t be agile! I mean Agile. What are we going to do now? All is lost! We won’t achieve true agile success!

On a second though simple success should be just fine. If this true agile success is something different than just a success I think I prefer the latter anyway.

Agile is just a toolbox – depending on level a toolbox of general principles or specific practices or both. Either way a toolbox. Agile isn’t a lifestyle or religion, so don’t try to sell it like it was. Just let people use tools which work for them. Teach people how to use new tools – they’ll be adopted if they’re found useful. The same as we use screwdrivers or wrenches. And when I last checked no one considered the way they used screwdriver as a religion or a lifestyle.

This is the final post of Carnival of Agile Bullshit. I already gathered a lot of comments from you but I ask you to let me know what you think not only about this post but also about the whole carnival.

in: project management

7 comments… add one

  • Pawel Lipinski March 26, 2010, 10:24 am

    In this post you’re right in one thing – what you’re writing is a bullshit.
    Don’t get me wrong – I don’t want to insult you. I just COMPLETELY disagree.
    I’ve seen teams ‘doing agile’ – they met everyday for a standup, had retrospectives (completely nonfunctioning), had iterations (usualy monthly), CI environment, a product owner etc. And they failed. Not because they hadn’t had agile trainings (they basically knew how to ‘use’ iterations and ‘use’ standups, etc.), but because they used agile AS A TOOLBOX.
    So agile is not ‘a set of general principles’ – its an attitude more than a specific action (actions are just result of the attitude).
    And agile is not a set of practices – just check how many agile methods are there: scrum, xp, fdd, crystal, etc. Each has its own practices. And usually they’re adaptive – you select/adapt to what fits your (constantly changing) environment.

    If you’re not ’embracing change’ and don’t focus on continuous improvement and technical excellence, and you’re not proactive and brave, don’t work on proper communication and not aim for simplicity, don’t tell me you’re agile. For me these values define what agility is. Everything else (i.e. the practices) is just means which proved to help people with agile mindset in their projects. And they’re not obligatory (for example Jim Coplien is a strong opponent of TDD, and you wouldn’t say he’s not agile).

    So to summarise: you don’t need to ‘do agile’ if you are agile.

  • Pawel Brodzinski March 27, 2010, 3:04 am

    Pawel,

    Finally a comment I’ve tried to trigger. You cover a few different aspects.

    1. Principles. I look at Agile Manifesto and I see a set of “value this over that” sentences. We can discuss how to call them but that’s pretty much meaningless. The way you work, your methods, can resonate with them better or worse. They aren’t even specific to the point you could tell who fully follows them and who doesn’t.

    2. Practices. Yes, there are a few different agile approaches. Each of them propose different set of practices. I don’t tell there is one specific set of agile practices. There isn’t. I don’t agree with people who point this or that practice as mandatory to call themselves agile. But in the end what agile teams do is they use one of another agile technique which, in the end, means using a set of practices.

    3. Doing agile. You describe ‘doing agile’ as misusing different techniques. Set agile aside for a moment. If you misuse any technique you will likely fail. It’s not the process or approach which should be blamed in the first place but people who misuse the technique.

    4. Toolbox. I think about continuous integration or unit testing or the way we’re setting priorities as tools. We use them to develop software. These aren’t rules we live by. Surprisingly enough we don’t fail because we don’t believe agile is some higher thing.

    5. You don’t need to do agile if you are agile. I guess that’s not what you meant but if I take what you counted as agile principles (embracing change, continuous improvement etc) you can perfectly end up working in chaos or doing the wrong thing.

    By the way: I like how Alistair Cockburn treats embracing change. He doesn’t make an agile flagship out of it.

    To summarize: I’m not convinced. There isn’t any clear definition of agile and this discussion is a good proof. But after all we don’t talk about religion or something. We’re discussing just the way we build software. Agile is neither the first nor the only approach which allows to build good software.

    Arguably agile is the only approach which is often sold as something more than just what it is: software development and/or project management methodology.

  • Pawel Lipinski March 27, 2010, 3:55 am

    I guessed you wanted to trigger that, and I’d just love to participate ;-)
    Soooo…
    Ad 1) Principles are what you find on the second page of the agilemanifesto.org. The first one is a statement of values. But generally you’re right – they’re not specific enough to judge if one’s agile by them. And in general I don’t judge if someone is agile. With some people I just like to work (or rather collaborate) and with some I don’t. These I like to work with want to achieve their goals, are passionate and willing to learn (just to cut it short.) If I dig deeper I come to agree with the agile manifesto principles and they pretty well describe the attidute I try to have and expect from those I work with.
    Ad 2) Practices – you’re just right here.
    Ad 3) Did I use the term ‘misuse’? No. There are teams which try to follow a given method perfectly. I’ve even seen a company in which they got additional bonus for following them all… But that’s the exact point in where we differ. I think it’s not enough to follow practices if it’s not your style of working (and sometimes even way of living.) I’ve seen a team which was well educated and was following scrum very well (as far as I can tell, but I guess I can.) And the project was a complete failure because noone in the team really cared. But still, all the scrum-required practices were followed well.
    Ad 4) I don’t get the point here, but toolbox is a different thing. You may create a great code of the highest possible quality and fail the project because: it wasn’t on time, in expected budget, application was useless, etc. So there is something more to software development than tools and practices.
    Ad 5) This IS what I meant. I believe agile practices (‘agile’ that you do – as a noun) are less important than agile values and principles (what you are – agile as an adjective.)

    To summarise: We’re not discussing about how we build software. It’s more about how we act while building it. I’ll try to convince you during agileCE ;-)

  • Pawel Lipinski March 27, 2010, 4:04 am

    I’ve created a slot for the openspace discussion for a discussion on the subject. See here: http://agilece.com/openspace. I linked to your post – hope you don’t mind.

  • Pawel Brodzinski March 28, 2010, 11:35 pm

    Pawel,

    Completely non-functioning retrospectives don’t sound for me as a good practice. But yes, I over-interpreted what you’ve said. Actually retros are a good example to discuss – if people in the team doesn’t believe that retrospectives bring value their input will be low-quality and repetitive.

    You may point it as an argument in doing vs being agile discussion but for me that’s a general rule. I saw the same thing with post mortems we were doing when we followed MSF (Microsoft Solutions Framework). And back then no one said we aren’t MSFish enough or we just do spiral instead of being spiral.

    By the way – self-improvement is one of principles included probably in every agile approach. I guess we may agree on this one. If so, every non-working process or practice should be adjusted or thrown out or you don’t fully follow agile principles.

    I think we are discussing how we build software and how we manage projects. The same as you can use all the best engineering techniques and build something completely useless, you can also try to deliver a product which is ideal in its founding but engineering-wise it’s just a piece of crap. If you think about project as end-to-end effort to deliver some business value with software you develop these two are inseparable.

    I’m looking forward to see you at AgileCE. I’m sure the discussion will be amusing.

  • Bob Hartman April 1, 2010, 9:03 pm

    Pawel, when you say “If you think about project as end-to-end effort to deliver some business value…” you are making my point for me. If you are just DOING agile, you would never think this way because DOING is not the same as THINKING or BEING agile. The fact that you are thinking in an agile way and you are concerned with improvement shows some of the basics of being agile, not just doing agile. Doing agile means not paying attention to anything except the process. In the case of Scrum it means holding 5 meetings, using 3 roles and 3 artifacts. That alone doesn’t make you successful. How you THINK and how you USE that framework changes the result.

    To me there is a big difference between holding a retrospective because the process says to do so, and actually getting something out of it. There is a big difference between holding a daily standup because the process says to do so, and actually using it to generate significant value for the team. There is a big difference between working from a prioritized backlog and actually making sure the prioritization makes sense from a business value delivery perspective. In all of these cases the first part of the sentence is DOING agile, the second part is BEING agile. You can DO agile without thinking. You cannot BE agile without thinking.

    You can choose to disagree with me. It’s fine and doesn’t bother me at all. I tend to think the disagreement is more about the fact that we come from different nationalities and cultures than it is about a difference of opinion about what is effective. You seem to think my statement about BEING agile doesn’t apply to you, but the fact that you are constantly striving to improve, that you think about business value and that you care about the results prove to me that you are in fact not just doing agile, but you are in fact being agile. Sorry to disappoint you :-)

    – Bob –

    – Bob –

  • Pawel Brodzinski April 2, 2010, 6:39 am

    Bob,

    Damn, I am agile even though I thought I do agile. I lost my credibility… I’m just kidding.

    Seriously, I see this do versus be discussion as artificial. If you’re doing retrospectives because some process told you so and you gain no value from that you aren’t doing agile – you’re wasting money.

    If we move agile to some very abstract idea it would be about doing a good job. And pretty much the same you can say about any methodology out there. I believe there never was a method which said “do evil to your customers” or “suck more at what you do.” The difference is of course in solutions we get which are better or worse adjusted to our individual situations.

    Nice to hear I’m considered as a one being agile but I still don’t fell like it. I don’t buy this whole semantics problem. I think we either do a good job with agile or a bad job with agile.

    Anyway what is really good about this discussion we differ on how we call things, not on things we do.

Leave a Comment