≡ Menu
Pawel Brodzinski on Software Project Management

Who Cares If You Are Agile?

agile

Let’s play a small role-playing game. You are the vendor and I am the client. I exactly know what I want to buy. Sort of actually. OK, we may have to face some course changes as we hit the road. Anyway, I know what I want, okay?

At the moment I’m going to decide how your offer is best of breed because it surely is. So you tell me how great all the projects I can find in your portfolio were. You boast how enthusiastic reactions of your other customers were.

And we both know that’s complete bullshit.

Oh, maybe it isn’t but you wouldn’t tell me if things looked different anyway. You would try to sell me exactly the same sweet talk no matter how far from the truth it was. So no, don’t expect me to buy it.

What’s next?

Well, not the price, this is the last resort. Now it’s time for “we’re such a professional company” part. Methodology! That’s the thing. “As you may know, we employ agile approach in our teams so the software can’t be anything but top-notch. You had to hear about agile, this is one of the most popular and basically the best methodology these days.

I don’t give a damn.

I mean really. Why should I care what approach you use? Because agile is better? There is no such thing as the ‘better’ methodology in general. Silver bullets just aren’t produced yet. Oh, I see, agile is the best approach in this very case. This is the best choice in my specific project and my specific environment. Yes, looks better that way. But you know what?

I couldn’t care less.

I mean really. I couldn’t care less what you say you use. The thing I could care about is how you really work. But you aren’t going to show me that. How could you anyway?

The trick is you can do equally crappy job under the banner of agile as under any other. You can tell waterfall stinks because Scrum is thousand times better. Or you can tell Scrum stinks because Kanban is thousand times better. And both will be equally false.

On the other hand if your teams are well-organized the name of your approach is third-rate. You will deliver and will deliver quality. And yes, I’ve just said you can perfectly do it using one of old-school heavy-weight approaches grouped under infamous ‘waterfall’ name.

Results produced by suboptimal (for any specific case) but well-organized approach will easily trump those produced by optimal but in-the-name-only approach. You can do terrible job using agile, or any other methodology for that case, which you use as your selling point.

So no, I don’t care whether you’re agile or not. What I care about is whether you build quality products. Unfortunately the latter is so hard to present.

in: project management, software business

18 comments… add one

  • Jacob February 8, 2010, 2:11 pm

    I’d have to imagine it might impress the client if I say “we’ll show you working code in three weeks for your review, and we’ll incorporate your feedback into new working code three weeks later, and three weeks after that, and so forth. No, the buzzword “agile” doesn’t help, but actual agility does.

  • Pawel Brodzinski February 8, 2010, 3:16 pm

    Jacob,

    Good engineering, craftsmanship, process, practices, you-name-it help. It isn’t really agile or anything else – it’s just doing damn good job.

    And yes, sometimes client will be impressed with results agile produce. But if we keep playing the game and you tell me you’re agile I’m not impressed because I expected you’d deliver working code in two weeks.

    And don’t get me started about what kind of software we’re discussing here. If that happen to be a piece of integration stuff which neither works nor makes any sense without three other external subsystems you have no control over, you won’t show anything really working as long as other vendors aren’t ready with their parts of the solution. And this may happen in 6 months from now.

    Don’t take it as agile criticism though. I just don’t believe in silver bullets and agile isn’t one. In a project defined as vaguely as in the post agile is probably the best choice, but I’d take any good process over flawed agile or agile-by-the-name-only process. It would just yield better results.

    Until I know you really deliver working code in 3 weeks and I see the next iteration really brings the changes I wanted I have only your word. The word which in selling process isabused so often no one takes it for granted any more.

    There is of course discussion about resigning from agile vendor after 6 weeks (two screwed iterations) and non-agile vendor after whole project is failed but that’s the other thread, which should earn its own posting here I guess.

  • Nikolay Iliev February 8, 2010, 3:23 pm

    Great article, I really enjoyed it. It is like reading my own thoughts.

    The client profile is also an important factor – a software company may care about the exact vendor methodology in order to have less friction between own and vendor teams, but for a non-IT company the vendor methodology name or classification is just another buzzword.

    None of the non-IT clients I have worked for has ever asked me what methodology we follow. They really don’t care whether it is agile, waterfall or hybrid – there is only one desire and it is to succeed with the project (as with any other investment).

    The agile approach was innovative and a competitive advantage years ago, now it is practically the standard approach everywhere, so really nobody cares.

    What I find amazing is that it took just few years for the agile approach to turn into something it was fighting against – a strictly defined and dogmatic approach.

    Now we have all these fancy agile methodology names, certifications and a lot of people blindly following them without understanding something really important – the process should serve the project needs and not vice versa.

  • Pawel Brodzinski February 8, 2010, 4:10 pm

    Nikolay,

    It is exactly as you write – a lot of things happen under the name of agile. Some of them are good and some of them are bad. And that’s exactly specific of mainstream approach – it becomes used for different purposes just because people heard the name.

    Pretty much the same happened with Prince2 some time ago. I saw at least a few companies stating they have good project management process because they use Prince2. Unfortunately crap organized according to Prince2 (or Scrum or whatever) is still crap.

  • Laurent February 9, 2010, 5:49 am

    I was thinking, would showing the history of projects you’ve done be a good idea? I mean, showing to the client the real time line of some projects you’ve done, showing all the important events (deliverables, spec. changed, tests failed, deadlines, etc.), showing how you reacted to that, etc. Everything leading to the conclusion of the project. This would present exactly what your team can achieve, and how well its working.

    Would this be showing too much? As a client, would you care seeing this?

  • Pawel Brodzinski February 9, 2010, 6:22 am

    If that would be too much or not should be decided by the vendor. If you’re all about transparency – why not?

    On the other hand, no I still wouldn’t care.

    I remember a situation when neighbour team was about to have internal audit (it was ISO audit, but it doesn’t really matter here). They failed the previous audit big time since they worked in complete chaos most of the time. What they did was they prepared a show case – they cleaned all the papers in one project and showed it during the audit. The report was shining: all issues fixed. Magic. And they didn’t even changed the way they worked a bit. Note: it was internal audit so auditors could ask much more than you’d be willing to show outside of the company.

    So no, in general I don’t believe in stories you tell (or show) me. And that’s a sad thing since if you’re honest there will be a bunch of competitors which look much better just because they lie.

    Game becomes a bit different when there is no client-vendor relationship but there is user-vendor relation instead. But then still, I don’t care what your methodology is. What I care about are other users reviews. Most likely reviews of users I trust, not just any users of vendor’s choice.

  • Nikolay Iliev February 9, 2010, 8:20 am

    This is another overrated part of the sales pitch – “We are CMM Level 5 organization” or “We are ISO certified”.

    Considering the self assessment nature of CMM it is hard to be convinced that the company is really mature enough for CMM level X. The ISO certification is also under question as you have shown with this example and is practically true for any certification.

    Here is a short excerpt from wikipedia pointing the same problem:
    “ISO 9001 is not in any way an indication that products produced using its certified systems are any good. A company can intend to produce a poor quality product and providing it does so consistantly and with the proper documentation can put an ISO 9001 stamp on it.”

  • Pawel Brodzinski February 9, 2010, 8:41 am

    Yes, of course. If you develop crap you can easily get ISO certification. It just has to be well-documented crap.

    ISO tells nothing about quality. And it’s the same with showing a number of Certified Scrum Masters or stating you’re so darn agile or whatever else.

    And that’s exactly my point. As long as you can’t convince client that you do really good job, and most of the time you just can’t, the choice will often be random or based on who is the best liar.

  • YvesHanoulle February 9, 2010, 11:22 am

    >Until I know you really deliver working code in 3 weeks and I see the >next iteration really brings the changes I wanted I have only your >word. The word which in selling process isabused so often no one >takes it for granted any more.
    Yes. And that is only 2 or 6 weeks. That is much quicker than most other companies do. if a vendor really is convinced that his way of working is good enough, he should allow you to stop after each iteration.
    I know companies that give access to the output pages of their buildserver to clients and possible clients. So they can see the builds, see the number of test, number of test failing, etc etc.

    Finding a good supplier is always about trust.
    Agile is about being open. yes it can be faked; but not for long.
    In my opinion if a companies would sell itself as being better as they are, will go down much faster.
    The biggest risk I see here is that the people selling the company/team etc might have no clue how good or bad they are.
    (Or might not understand how important it is to be open. )

    y

  • Pawel Brodzinski February 9, 2010, 3:00 pm

    Yves,

    I pretty much expected I’ll hear the argument “you will know it 2-6 weeks so you’ll be able to react” soon. Usually that’s not so easy to switch a vendor even if you invested just a month of their work. You have to go few steps back, and start all over again losing time, your own efforts etc.

    Anyway, I could show you our build server output. I will prove we have continuous build and write unit tests which passes (most of the time). What does it tell you about quality of our development process? Barely anything. You can’t even tell whether we write unit tests because some manager told everyone they had to and tests are crap or developers write them because they understand how important it is and test on average are high quality.

    I agree with you to the point that most of typical liar-vendors won’t even think about being so transparent to show you their build server. But once they learn it can be a key selling point they will adopt – that’s for sure.

    And personally I don’t expect selling process to become honest anytime soon.

  • Phil Ruse February 10, 2010, 1:35 am

    This post is absolutely spot-on. A name or a term doesn’t confer quality – the people do. In the end it’s all about the people :)

  • Pawel Brodzinski February 10, 2010, 2:02 am

    And yet there are people who still believe they will throw some buzzwords at you and it’s going to make you bow with respect in front of them. And it isn’t about agile only – PMP and others are used the same way all over again.

  • Allison February 10, 2010, 9:44 am

    Very much spot on. I like parts of Agile, for the right job. I like parts of Waterfall, for the right job. I love automated nightly builds for all jobs.

    When I look for software, I want to make sure it works correctly. I don’t care if it was agile, waterfall, boehm (death) spiral – whatever – as long as it works.

    and to the “we’ll show you something in the next iteration – you don’t have to be agile to do that. You can have a marketing driving engineering team for example. I’d also argue that in 3 weeks you’ll show more of a mock up/prototype/proof of concept rather than ready for prime time code.

    don’t get me wrong, I love many things about Agile. But I also love up front design and Gant charts. Give me a team that is consistent, thoughtful and methodical and I’ll give you a great product no matter what the process.

  • Pawel Brodzinski February 10, 2010, 2:03 pm

    If you had a good track record with projects you’ve already delivered I wouldn’t even ask what is your process. And yes, that’s all about people and their attitude, not about specific process they follow.

    Having said that I can imagine projects where I’d pretty much expect to see results frequently and I’d ask for that. If the vendor was a good one I’d probably get it no matter if they’re agile or not because, as you say, agile isn’t the only method which allow to deliver frequently.

  • Radu Davidescu April 13, 2010, 4:45 am

    Yes, that’s a very good advice and approach. Actually you don’t need to sell Agile, but sometimes it’s very useful to use it to make things happend the way that both you and your customer wants.

    My tag line for my small but brave development team is “problem solvers”. We want to solve customer problems through quality development, and yes, we are Agile.

    Yes, our client’s don’t care much that we are Agile, but appreciate iterative delivery, as well as we care about constant feedback.

  • Jon Kern April 13, 2010, 7:27 am

    People, process, and tools. In that order. Good people will deliver good results. Good people will do it with an effective process Good people will likely use/build helpful tools.

    As I always say, a company certified in *whatever* is meaningless if the team working on your project sucks.

  • Pawel Brodzinski April 13, 2010, 9:09 am

    Radu,

    It’s easier if a customer perfectly understand what exactly using agile approach means. Then you may be able to sign time & material deal which suits agile projects much better.

    On the other hand it is hard to expect the client would willingly agree on this kind of terms.

    And yes this doesn’t mean you can’t or shouldn’t use agile in your team. Use what works for you and what works for your customer. Even more – if you want to have agile software development but the client enforce waterfallish process it’s still doable although it requires more effort on your side.

  • Pawel Brodzinski April 13, 2010, 9:13 am

    Jon,

    People in the first place – I agree. What comes next isn’t so important. Especially that in details definitions of toolbox and process may interfere.

    And about certification – some people even think that certified people are on average worse than non-certified ones.

Leave a Comment