≡ Menu
Pawel Brodzinski on Software Project Management

Agile? Waterfall? CMMI? EVM? All of Them and More!

Agile? Waterfall? CMMI? EVM? All of Them and More! post image

There is one thing which really pisses me off. I mean really. It happens when someone has a single solution which is perfect to solve the whole domain of problems. I just organically can’t stand silver bullet salesmen. This is by the way something which made me pretty suspicious when I started learning about this whole agile stuff years ago. It wasn’t that I didn’t believe in methods. I did. The problem was I could hardly accept the “our way is the best, you lesser being” kind of attitude.

Anyway if you know me at least a bit you probably know that in basically every discussion I stand on the hill where all The Defenders of the Context stand. And I will defend it. To the last drop of blood. This means that you will never hear me saying that this or that method is universally best. By the way if you hear me saying so, don’t forget to slap me in the face because that means I betrayed The Defenders of the Context and I deserve it.

Yes, I am aware that I’m considered a strong Kanban proponent these days. I may be even considered Mr. Kanban Poland by some (yay!) And yet Kanban is not a solution for every problem and it isn’t applicable in each and every situation. Now, you have me – I’ve just admitted I don’t have panacea, sorry.

OK, I don’t try to sell you Kanban, not this time. Fine. So um… what’s the point? Well my point is that managing software projects is such a broad discipline that it takes many different approaches, attitudes, methods, tools, manifestos and movements to get the darn thing done in each possible case.

I will often promote Kanban as its beauty is that it is applicable in different situations. On the other hand Kanban with no other tools whatsoever won’t really help you. I love stories on successful implementations of Scrum, especially such down-to-earth as the one recently shared by Eric Sink. But you will also hear me saying that waterfallish approaches have their place as well, and sometimes they actually are a better choice than agile ones.

I guess I’ve proven worthy to be one of The Defenders of The Context, haven’t I? Now, where is it all going? Well, I have a bold hypothesis. I believe people from different worlds of software development and project management can learn a lot from each other. We tend to think that people still using waterfall-like approaches can learn from us agile folks. That’s true. But, and let me stress it, it works the other way around as well. And then there are other worlds which are kind of ignored in this old, beaten to death, agile versus waterfall skirmish. Earned Value, CMMI, Critical Chain and whatnot.

We can learn a ton about our methods, but also about our contexts: projects, people, organizations, clients, office politics, different stupid issues, totally strange requirements, constraints, etc. We can spend hours over beer discussing our best ideas and finding out why they might be not as good as we initially expected in a specific context. We can broaden our horizons way further than we usually do on agile conferences. Not that I have anything against agile events – they’re great. They just tend to gather only one of groups of people I’ve mentioned above.

That’s why I will support every initiative which aims at bringing people from different software development and project management worlds together in one place. I will because there aren’t many of them.

I’m strong supporter of Project Management Stack Exchange as it works exactly this way. Want to find PMPs? Here they are. Agile crowd? Sure! How about people struggling with chaotic projects? Plenty of them. Other worlds? You will get your answers as well.

I genuinely love to read questions and answers on issues which sound virtually out-of-this-world. I love because they remind me how different software projects are out there and how difficult it can be to apply our experience to solve problems in such projects. On the other hand I love to see how often common sense is sort of the best solution. Heck, if I got thousands of rep at PMSE it was basically because of promoting common sense.

On the side note: I did consider abandoning The Defenders of the Context and joining The Common Sense Proponents but the former had cooler outfits.

Another idea which fits the same scheme, although it will be interesting only for Poles, sorry, is Deadline conference. The main goal of the event is to create a common platform to exchange ideas and experience between people from different PM worlds. We have fine agile events in Poland (I even write these words during my trip to one of them – AgileByExample). We have events for PMPs and for CMMI folks, or so I hear. But we don’t try to merge those worlds in one place to learn from each other. That’s why I believe Deadline should be a must have for those project managers in Poland who want to broaden their horizons and those who care about learning.

Although I don’t know such events abroad I believe every local project management community deserves one. It does sound like an opportunity, doesn’t it?

One final thought to support this attitude. One of the most valuable thoughts I got from Kanban Leadership Retreat was a result of a chat with Jabe and Simon on applying sexy Kanban concepts in environments which are um… let’s say challenging. Where expectations of management can be to improve productivity so they can cut costs or where you fight for authority in the first place to be able to change anything at all. You’re right; it’s not really about Kanban. Yet it popped out in the context of Kanban discussion. And all that on a purely Kanban event.

Now you see what I think about – we never get away from the context and sometimes the context is kind of ugly. So the more different situations we’ve seen the better we are prepared to survive in this harsh world of building software projects.

in: communication, project management

10 comments… add one

  • Lech Ambrzykowski September 14, 2011, 1:46 pm

    I really enjoyed today’s entry and your strong points, Pawel. It’s difficult not to share them too, especially, if one faces an “‘our way is the best, you lesser being’ kind of attitude” *wink*

    There is one occasion, where a “silver bullet” might help. Beginners. It takes experience to adjust the toolset based on context. Then again, flexibility is something PMs ought to start developing as early as possible (this reminded me of E. de Bono’s Six Thinking Hats, BTW).

    Thanks for the food for thought!

  • Pawel Brodzinski September 14, 2011, 11:48 pm

    @Lech – I know that some people want to buy a silver bullet but it won’t make me selling one. I believe that even with beginners you can guide them through a bunch of choices finely trimmed to their needs so they learn from the very beginning that:

    – there are no freaking silver bullets
    – they are those who are responsible for fine-tuning their methods
    – and they should basically do it all the time

    I believe that we actively harm teams when we give them so-called silver bullets even when they expect us to do so.

    Anyway, I know I’m pretty radical on this subject.

  • Piotr Leszczyński September 15, 2011, 7:00 am

    Don’t you think that sometimes defending the Context is just the easier way? It’s just an excuse not to do something?

    For example:
    – Hey, why aren’t you doing Continues Integration?
    + You know, it’s hard to maintain in our project, we tried but it was not worth it.
    – Yeah, but don’t you see values it provides?
    + You won’t understand it – you don’t know the whole context.

    And, hell yes, I don’t know the whole context, but sometimes I don’t give a shit. There are practices which provide you really huge value and then context doesn’t really matter.
    In most cases I could imagine a situation when it is really, really caused by the situation, that there are circumnstances which cannot be avoided. However I dare to say that too often it is just chosing the easier path, finding reasons for not doing something good.

  • Pawel Brodzinski September 15, 2011, 7:08 am

    @Piotr – First, you should give a shit. Otherwise you will end up as one of those generic trainers who have their solutions except these solutions are hardly applicable anywhere. Don’t tell me you haven’t seen such trainers. Don’t tell me you were OK with them.

    Second, your example is just a lousy excuse and not discussion over the context. If you care about the context you don’t dismiss a discussion with “you won’t understand” argument.

    In other words: you either care about the context and you don’t avoid the discussion on the context or you just make excuses. But fear not, we don’t allow the latter to join the ranks of The Defenders of the Context :)

  • Piotr Leszczyński September 15, 2011, 7:42 am

    @Pawel Yes, I give a shit. As we’ve talked it drives me crazy when on Agile conference I hear coaches talking about how Pair Programming is great and easy, and when the audience is asked there are few people practising it. And it is Agile conference, so there should be plenty of them. And then I start to ask myself whether I’m stupid or this guy is saying bulshit or is living in a dreamworld.

    But the Context of this situation is such as I have given :>. People tend to use the Context as an excuse. And I know that it is crucial to understand the whole picture, that there are thing that are beyond your power.

    Having that said I still believe that there are things that don’t depend on the Context. Or maybe things is a bad word – approaches would be much better. Approaches such as Software Craftsmanship with it’s manifesto (http://manifesto.softwarecraftsmanship.org/). And in fact we agree that you should apply a proper solution to a problem, but doing things well is an attitude which is something over the Context.
    I think that in developing software we have created some good practices which are just adding value and sure – you can reject to use them but show me how are you replacing the value. And if you are not, your practices are worse than mine.

  • Pawel Brodzinski September 15, 2011, 9:22 am

    @Piotr – Yes, people use the context to make an excuse for their laziness and lousiness. Same as people use knives to kill other people. Does it make knives bad? Or does it make we should ban the knives?

    As my father used to say: if you want to hit a dog finding a stick won’t be a problem. If you don’t want to change you behavior, attitude, skills you will find a very good reason why you shouldn’t do that. Does make you right? Um, not so much.

    Regarding best engineering practices, I’m not that sure I can think of a single one which would be applicable and valuable in every possible situation. Probably continuous integration is the closest to the ideal but even then I would think of it twice if we discussed a solo project.

    Yes, I agree that there are practices, and many of them, which can and should be applied in majority of cases and it would be a good decision to make. However, I’m always far from assuming that this specific situation we talk about actually is a part of “majority.”

    If it is, your practices are probably better than mine, but unless we verify it, well, I just don’t buy this crap.

    BTW: This is an interesting discussion as we mostly agree on the value of best engineering practices yet we differ on attitudes toward enforcing them. Is “enforcing” a good word anyway?

  • Piotr Leszczyński September 16, 2011, 7:58 am

    When talking about practices I would choose Version Control. And yes – there are people who still don’t use it. And yes – I don’t understand them, but I’m sure they have damn good reasons not to do it. :>

    Yes it is a very interesting discussion and I think I have tried to use your attitude with encouraging team to use Pair Programming and it didn’t work. Maybe my attitude was wrong. Maybe our Context is different, but still it didn’t work. We are not doing Pair Programming. And I deeply believe that we should. I see so many benefits and now I’m just waiting for a proper moment to enforce doing it. I know that people would be more commited to this practice if they would be convinced by themself. I also used to think that you cannot make somebody do something because he/she will find milions of reasons to do the opposite, but I think need to change this attitude.

    Funny thing is that I’m sure we agree on the subject that Context matters. I’m only far from saying that it always matters.

  • Pawel Brodzinski September 16, 2011, 8:22 am

    @Piotr – Well, if you think that convincing people in the first place isn’t the right attitude, just force them to pair program. You will see whether it works better :)

    And if you want more context in this case, well, I think we may safely assume that there are developers who won’t adopt pair programming for whatever reasons, maybe because they have a character flaw or they don’t give a damn or they just don’t believe in pair programming. Now, consider you have a couple of such people in your team. Will pair programming be still such a good idea?

    It’s not that uncommon that you look for people who would accept the way you work. If you think about teams or companies which adopted many of practices we think of they basically verify how people react to them during recruitment or when they choose people to join the team. The whole process is sort of inverted.

    And, since you’re far from stating it I’ll do it for you: The context matters. Always.

  • Piotr Leszczyński September 16, 2011, 12:22 pm

    @Pawel I’m sure you know that I prefer to convince people to adopt a practice, but there are things I just expect people to do and it’s something we (team) will discuss. Such thing is for example keeping our Kanban board up to date. Of course I’ll try to explain and convince them and of course I care if they hate it. But it isn’t the place to make a compromise. In fact I believe that if someone hates the way I want to work with team and the way I want to deliver projects she will leave and it would win-win.

    Let’s say you convinced me that context always matters in applying practices. So I think it ends our discussion. But there are areas where it doesn’t matter. We can discuss them someday over a beer.

  • Pawel Brodzinski September 16, 2011, 2:16 pm

    @Piotr – As abe2011 left me in confrontational mood 2 cents more. That’s true that you expect the team to keep the Kanban board updated. But when you were starting with Kanban you got team buy-in first, didn’t you?

    That’s by the way exactly what I was trying to point. When you were significantly changing the way your team worked you consulted it with everyone. But now, once the change is already is in place anyone who joins the team has to accept it because this is how you all work.

Leave a Comment