≡ Menu
Pawel Brodzinski on Software Project Management

Agile Bullshit: You Can’t Be Somewhat Agile


If you’re using agile you should use it all, no exceptions. ScrumBut is bad. In general you can’t be somewhat agile. You either fully are or are not at all. You must see that a lot around the interwebs.

Sorry guys, but even with all these old-school heavy-weight highly-processed methods you are told most of things are optional and you should use those which are relevant to your situation. I understand the difference – if RUP describes more than 120 rules you aren’t supposed to follow them all, if Scrum ends up with less than 10 each of them is probably much more important on average.

Yet still when I see Kanban with barely 3 rules I’m ready to skip one if I believe I don’t need it at the moment. You can tell I’m neither agile nor lean and you know what? That’s fine. That’s perfectly fine because I don’t care about labels.

And I’m not alone here. Exception-powered Scrum, also known as ScrumBut, is pointed as the best part of Scrum almost as frequently as a major sin. I’m not surprised. I believe every methodology or approach should be treated as a toolbox. You choose the tool or tools which suit you fine at any given moment. If something generates only additional hassle and bring no value you just put it back to the box.

By the way, there isn’t even clear definition what does it mean to be fully agile. Is Scrum implemented by the book agile or not yet? Do you have to follow XP to call yourself agile? And who said that after all?

My take is: you can perfectly be somewhat agile. You can just use few of Scrum techniques and I’m fine with it. What makes difference at the end of the day is not which practices you did use but whether software is high-quality or not. And believe it or not people were building high-quality software long before agile was coined-up.

All posts of The Carnival of Agile Bullshit.

in: project management

11 comments… add one

  • Joshua Lewis March 24, 2010, 11:13 pm

    I agree 100%. My approach is to first find the root cause of a problem, then choose any tool from any flavour/meme which I think will help solve the root cause.

    This post is also related to something else I don’t believe in: when people say that you can’t gain the full benefit of XP if you leave any practice out, that the whole is greater than the sum of the parts.

    Not every practice is applicable in every environment. In my environment, TDD is so irrelevant its almost in a different universe. However practices like pairing or continuous integration would have huge benefit.

  • Pawel Brodzinski March 25, 2010, 2:08 am


    I’m glad to see your comment about TDD. Along with Marek’s comment below one of previous posts it exactly presents the case I wanted to point.

    While for Marek TDD is one of must-haves and crucial technique in his approach you call it completely irrelevant. And you both are right. Each of you has his own subset of practices which works in your environment. And I guess neither of you could be called fully agile by one of these agile orthodox, but that’s exactly how things look like in the real life. Real life isn’t about following the book, it’s about finding your own way of doing things.

  • Laurent Parenteau March 25, 2010, 12:01 pm

    I agree with you, especially with “I don’t care about labels”.

    But I think that it is also important to use the correct terminology to describe what you want to describe. We must not forget that Scrum != agile, even if some people often use one term for the other. So, you can use only some of Scrum’s recommendation and be agile. You can even do nothing of Scrum and be agile. But, if you are not doing 100% Scrum, it is totally fair to say that you aren’t doing Scrum. You may still be agile, but it’s no longer Scrum. I don’t like the term ScrumBut, since its meaning isn’t clear. How much of Scrum can you discard and still call it ScrumBut? It reminds me of an old joke about somebody asking for a rum & coke, without coke…!

    For me, as long as you value the 4 Agile Manifesto values, and you follow its 12 principles, you may claim that your are (100%) agile. If claiming such a thing is important to you…

  • Pawel Brodzinski March 26, 2010, 8:14 am


    The question is where is the value. For me it isn’t in being 100% agile or 100% Scrum or 100% Kanban. The value is in building set of principles and practices which resonate well with your team and allow you to build good software.

    Personally I don’t feel the urge to follow agile even if I think Agile Manifesto in general is good. The same as I don’t treat Kanban as panacea just because it suits perfectly my current team.

    If someone sets goals to become purely agile or follow Scrum by the book these goals are flawed. We don’t get paid for being agile but for delivering (hopefully) good software.

  • Laurent Parenteau March 26, 2010, 8:54 am

    Exactly. Delivering good software is the goal, being (0% .. 100%) agile is one of the path which can help you and your team achieve this goal.

    When you lose sight of your goal, whatever you are doing, you are getting lost.

  • Szymon Pobiega March 28, 2010, 11:13 pm

    We all agree that there’s no one blessed agile way. There is Scrum, Kabnan, XP and a a lot of other methodologies people can choose from. And they are designed for specific purposes. There is no chance all will fit your environment, but some will.

    And there are really (I mean really) smart people out there who design these methodologies to be used by others who find them useful. And these methodologies very with respect to experience of people they are targeted to.

    I understand agile this way: Scrum is good if you don’t want to experiment much. Just take it as is and try. There is a good chance it will work for you. But this has same downsides: if you remove some essential elements of scum, it won’t work at all.

    Kanban/Lean is totally different. It encourages experienced and skillful people to mix-and-match practices to create their own agile methodology.

    And last but not least, XP is for really really good engineers. For example, it prescribes practices that can be followed by less then 5 percent of engineers in my company, so switching to XP is not a choice to be made lightly.

    For me, being agile (you can’t do agile, it is an adjective — Kevlin Henney) is about responding to changes rather then creating an artificial world where no changes happen. Anything beyond this definition is, at least for me, an irrelevant detail.

  • Pawel Brodzinski March 30, 2010, 12:58 am


    You can do agile. Language changes. It is adjusted to the way people use it. Language development is an agile process after all – it embraces change.

    I wouldn’t split different agile approaches as you do. I try to avoid looking at any method from the perspective of who they are targeted at. I look rather at what do they give to you.

    Scrum organizes team work in the first place. Then it helps you a bit with engineering and a bit with project management (old-school understanding of project management).

    Kanban basically organizes workflow and helps to spread information.

    XP focuses on engineering techniques in the first place and don’t tell much, if anything, about project management side.

    If you take our company you’ll see that what we really discuss talking about agile is team organization and software development. We don’t really touch project management since it is already somehow organized and it doesn’t really suck.

    But yes, I agree with you that Kanban works in our case because of people, although other teams might have tried it too. I agree that implementing XP would be really hard and long process even if there was agreement we should do it (which won’t happen by the way).

    I think we should focus on people not on methods. Once there are good leaders in place good methods will follow.

  • Szymon Pobiega March 30, 2010, 8:39 pm

    Although out perspectives are different, we agree that there are some ‘standarized’ methods of doing;) agile. Some of them are more rigid (scrum) and some are less (kanban).

    My point was that if you take one of the more rigid ones you better have very good understanding of its inner workings if you want to tune it.

    Your last sentence is very important. I agree with you that good leaders are critical to success of any organization. But, on the other hand, not every team leader in the world is a ‘good’ one. Some of them are and they would probably fine-tune their processes with a kind of kanban. The rest need a strong guidance, like the one that Scrum comes with.

  • Laurent Parenteau March 31, 2010, 6:00 am

    Pawel, ‘I think we should focus on people not on methods’ resonates quite well with the first value of the agile manifesto, which is ‘Individuals and interactions over processes and tools’.

    And I think that what Szymon is saying is in line with it as well.

    By focusing on people, Szymon realized that in a particular team (most of them, according to him), people needed strong guidance, so he decided to use Scrum. If the team was different, you would have decided differently. He didn’t “pre-selected” a method and forced it the team, whoever is part of it. He (with the team) selected a method based on the members of the team.

    The resulting method can be anything, and this is totally fine. But it will be what best suit you, your team, and your project.

    This is agile.

  • Pawel Brodzinski March 31, 2010, 6:07 am

    I have one more insight regarding our discussions here and in real life. You look at Scrum and agile in general build with bottom-up approach. There are teams which want to be agile so they implement Scrum try to convince other teams to do so etc.

    As long as we’re talking about Scrum it is good perspective. You don’t need to have huge experience with you to try Scrum. What you need is determination and enthusiasm in the team and both can be built to some point.

    When I try to look at Kanban this way I see less chance to succeed exactly because arguments you give – without fine-tuning Kanban will suck almost for sure while Scrum can work pretty well.

    On the other hand you often have to face some kind of top-down approach to organization, let it be team organization (vide cross-functional teams or lack of them) or project management methodology (waterfallish techniqes) or other formalized process (quality control, ISO-like certifications etc). Either way you have to follow them no matter what’s your approach on team-level.

    You can of course build Scrum oasis and translate Scrum into the process of the rest of the company back and forth. But you may accept top-down process and just add some Kanban there. In this case you don’t need much knowledge how process should look like because it is already defined in a number of ways (it is arguable if these are the best ways, but that’s not the point). You can treat Kanban as an addition to whatever currently exists and chances are good it would work.

  • Jeff April 4, 2010, 12:25 pm

    Agreed! The focus should always be on delivering value to the business and empowering those who deliver said value so they stick around to deliver yet more value. The % of Scrum/XP that is employed in the pursuit of the first goal is secondary.

Leave a Comment