Agile Tools, Myths and Practices

Posted on August 14th, 2009 in Agile, Silver Catalyst by siddharta || No Comment

Selina interviewed me for the Producteering Forum recently. The transcripts for the first two parts have been put online.

Part 1

There is a tendency among some of the folks who practice agile to interpret the “Individuals and Interactions over processes and tools” in the Agile Manifesto to mean that Agile software development does not require any defined set of processes. So what is your take on that?

… What agile says is when you have different projects running, they all run in different conditions. You might have one project which is composed of a lot of senior people, you might have another project with a lot of junior people and a couple of senior people. [We] can’t have the same process for both the teams because the team structure is different, so some practices that work for the senior teams will not work for the mixed team. So while they will follow some practices, they might follow different set of practices. That’s a process, but then it’s not a centralized defined process done by someone sitting in an ivory tower who then enforces it among all the projects in the company…that’s something which people are genuinely against. Have a process – but have a process which is suitable for your condition.

Read the whole of Part 1 here.

Part 2

Agile has its own advantages and people who vouch for it. So does a completely different way of doing things – the CMM (Capability Maturity Model). What are the compelling reasons for a person who is practicing CMM processes to move to agile?

I’d say there’s only one compelling reason – and that is, if what you are doing currently is not working for you. If you’re following CMMI and it is working for you, that’s great, then there is really no need to change. You don’t have to change because it’s the in-thing. That’s something which I’m quite against.

But a lot of people do have problems when it comes to CMMI when requirements are unstable, because of the way it is structured, and with testing and user acceptance right at the end, which creates a lot of issues with respect to changing requirements. Or cases where you’ve not got the requirements exactly or there’s also the case where the customer sees a product and then gets lots of ideas on how it can be done. So when you have a market like this, then you find that CMMI tends to cause issues because you get bugs right in the end, you get change requests right in the end. It can be difficult to cope with it.

Read the whole of Part 2 here.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

Leave a Reply