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.

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.

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

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.

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.

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.

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.

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