≡ Menu
Pawel Brodzinski on Software Project Management

Agile Means Formal

Agile techniques used to be called flexible, light-weight or informal. While I won’t argue on the first one, others are disputable.

Light-weight was coined as an opposite to heavy-weight PMBOK-like or Prince2-like methodologies which bring a lot of hassle to be implemented properly. You know, all these documents procedures etc. We don’t need them. We’re going to be light-weight. We’ll put people over processes. But wait, people should be organized in some way or they’ll be wandering around with no clear goal. We shall better have some techniques which will allow us to direct their efforts. We’ll have planning games, stand-ups and strict timeboxing. We’ll add some software development techniques as must-haves: test driven development and pair programming sound good. Wait, are we already surrounded by all these principles? Do we have as much formalism as we used to? Is that possible we are heavy-weight? Ouch.

I’m not trying to say agile is bad although some will read above paragraph that way. The thing I’m saying is that agile is pretty formal. And that’s perfectly understandable. Actually agile replaces some techniques we used in big old methodologies with some others which are more fun (user stories are more fun than 100-page Word document filled with requirements sent by a client) and in some situations are more useful and more productive. Which doesn’t mean they’re less formal.

Actually in the area of software development it was agile which brought much formalism. E.g. XP set up strict rules how code should be developed talking not only about code itself but also about developers and their interactions. From developer’s perspective old-school formal methodologies are probably way less formal than informal agile techniques.

Agile means formal, but formal doesn’t mean bad.

in: project management

9 comments… add one

  • Ed Darnell March 17, 2009, 3:44 am

    “But wait, people should be organized in some way or they’ll be wandering around with no clear goal.”

    Which comes first the goal or the organisation around it?

    In my experience if you have a clear goal which the team is committed to, pretty much anything works (and the less non-essential process you put in the way of performance the better).

    If you don’t have a clear goal or the team are not all committed to it then that’s where to start. Motivated teams are more than capable of self-organising.

  • nozebacle March 17, 2009, 6:31 am

    What I have seen is that Agile means discipline. You don’t need to fill zillions of formats, but you need to follow flawlessly the practices of your process.

    You’d better have a dictator as project manager when you’re doing agile! Have you tried doing XP and skipping one of the practices? The entire systems breaks! Conversely, heavier processes are more tolerant to ‘human failures’ such as missing unit tests for something, or programming without a partner.

  • Pawel Brodzinski March 17, 2009, 2:16 pm

    Ed,

    Simplifying things much (too much) agile came with rejecting old-school methodologies. With no alternative at hand most of the time it would end in chaos.

    Of course the goal is the main value here. If you can reach it and do it fast and get good quality with chaos all around you, well, that’s great. I won’t advise you to change your behavior.

    However in vast majority of cases putting a clear goal for the team is not enough to achieve success. You need to give people some guidance or every of them will try the way he thinks is the best. It isn’t the perfect way of teamwork, is it?

    Of course there are teams out there which do pretty good job in self-organization but they use the same techniques you’d choose if you were in charge. The difference is the decision is made by the team not by the manager who force her own idea.

    Even if the team makes the decision and it ends up with agile approach it’s still formal. Which was my point.

  • Pawel Brodzinski March 17, 2009, 2:22 pm

    Nozebacle,

    I consider XP as very strict methodology when talking about following rules. Actually I haven’t worked professionally in the team which used XP conservatively.

    On the other hand I’ve seen several practices taken from XP and implemented in other environment and it worked pretty darn well. I didn’t call it XP though. That’s by the way approach which is closer for me. Take parts which suits you the best and use them instead of following everything by the book.

    I think each process is pretty similar when it comes to tolerate people’s failures. The difference is in techniques used to deal with it. With XP you try to prevent failure as you work. In old-school methods you do it in more reactive way.

    I’m curious why do you think you need a dictator as PM with XP?

  • Tomek Dabrowski May 4, 2009, 3:11 am

    Hmmmm.. I can’t agree with this “Agile is pretty formal”.

    Pawel, could you clarify what you mean by “formal” keyword? Does usage of some good/well-working techniques mean for you formal?

    For me Agile is above all: feedback from customer, team; collaboration between people in order to achieve common goal; shipping often; continuous improvement of your process. Especially the last one – continuous improvement – gives you possibility of changing your process rather than following something that does not work. The team is fully entitled to apply new and resign old techniques – you don’t have to do your work every time in the same way.

  • Pawel Brodzinski May 4, 2009, 11:22 pm

    Tomek,

    In general, whenever we follow strict rules we’re more formal. It doesn’t have to be about generating a lot of document. It can be, and it is when it comes to agile, about actions we perform.

    Meet often and keep your meetings short” is pretty informal. “Meet everyday for 15 minutes and allow no one to sit down” is more formal. “Develop high-quality code using techniques which you believe work” is informal. “Write tests first, don’t develop code which doesn’t break any unit test, program in pairs, switch sits in pairs at least every half an hour, refactor at the end of implementation of each user story and have Kent Beck poster pinned over your desk” is way more formal. Just two examples from the top of my head.

    Don’t get me wrong – I don’t say these techniques are wrong. I just say that agile is quite strict in terms of rules you should follow.

    I was never trying to prove that agile is stiff. Of course it can be, and should be, adjusted every now and then but this doesn’t change the main point.

    By the way I think there’s no methodology which forbids you to adjust the process in any way so agile definitely isn’t unique here.

  • Tomek Dabrowski May 5, 2009, 12:48 am

    I’m still not convinced with your arguments. Agile give us some well-working techniques that you should try in your project. Of course, every technique has its own rules and it’s natural to follow them.

    As you said “agile is quite strict in terms of rules you should follow” – I’d like to make a point of word SHOULD :) In my opinion, should means “you are advised to” but you do not have to.

  • Pawel Brodzinski May 5, 2009, 1:24 am

    Tomek,

    First, you don’t have to convince me to use agile techniques. At least some of them are used in my teams for a couple of years already.

    Talking about what you should do and what you have to do to call yourself agile, well, it wasn’t me who started this whole orthodox thing.

    You’ll often find opinions that refactoring is not optional – you have to refactor if you want to be agile. Same with unit test – they’re obligatory. Or this one about Scrum which rarely uses a word “should,” let alone “you’re adviced to.”

    I agree with your approach to take these techniques which suit your team fine and leave those which don’t work. That’s exactly how I treat every methodology around.

    But it’s not me who try to put labels “agile” or “non-agile” on everything and everyone. I don’t pretend our team is agile just because we use burndown charts, share office space or have a cross-functional team. Actually I don’t care how agile my team is as far as we’re doing good job.

    However if we come up to definition of agile methodologies as complete wholes I still say they’re formal. If you choose just a few techniques from here and there you’re most likely much less formal, but don’t ask me whether you’re still agile or not. There are zealots out there who cares, but I’m not the one.

  • vukoje June 7, 2009, 4:00 pm

    This is excellent observation, agile methods are formal and I completely agree with nozebacle that PM should be dictator in applying small number of obligatory rules that are identified by agile methodologies and accepted by team members, at least until team is fully committed to project.

Leave a Comment