Process, like management, doesn’t add value by itself. It should only be used as little or as much as necessary to achieve the desired results: better quality, better customer value, better suitability, faster time to market.

I don’t see any good reason to use waterfall or traditional software processes. I don’t see success coming from using no process at all (cowboy mentality); I don’t like when people play heroes or victims – I prefer delivering results and having fun while doing it.

I am a big fan of lightweight agile processes and I think they help deliver the results I mentioned at the beginning of the post.

However, I have some big problems with agile: it doesn’t work easily or very well with bigger teams or with distributed teams. For bigger teams you could use multiple smaller product or feature teams, but dealing with common/shared code becomes a problem because the whole team code ownership principle doesn’t apply anymore. For distributed teams it gets even worse: you need the whole team to sit together with the customer and that is just not possible all the time. Think about open source projects with team members all around the world and no customer – how are they so successful? The religious view in agile to have the team together also makes companies like ThoughWorks have their employees travel 4-5 days a week every week – that is the reason I was not at Thoughworks employee in my career, even though they do an amazing job technically and in promoting agile thinking.

The old style agile with the basic 13 XP principles is obsolete and now the devops and continuous delivery movements lead the pack. However, these movements don’t need all the agile principles to succeed. Let’s think again about successful open source projects with team members all around the world (like apache). That’s how even now big companies like SpringSource or even JBoss started and worked for a lot of years. They didn’t have the team together or a product owner or iteration (I hate sprints, because I hate to keep sprinting – a product is more like a marathon than a 100m race) planning or even retrospectives and demos. However, they have quality and responsible people on the team with a strong lead, a clear roadmap and frequent and valuable releases – how most software should be like.

In my opinion while agile has a lot to offer, becoming religious about it makes no sense because it is just a tool to help you, not the end result. There is a lot to learn from open source teams and processes that they use and I suspect that the next wave in software development will be like the open source model since more and more people want to work remotely (why do we have to work in offices? because of luck of trust. It also feels like an old idea from manufacturing days when management had to watch the lazy people do their work and inspect and micromanage them throughout the day).

My last thought is from one of the agile starters (Mr Ward C.) when asked if he uses agile practices all the time – he answered: “of course not”. The reason is because he created some of the agile practices by not following the practices at that time and experiencing with new ideas from him and others.

I don’t like being a hero, victim or religious about work and software practices – I deliver results and have fun while doing it.

One comment on “The state of agile software processes

  • Hi Florin,

    Nice post. I agree with you that it’s tough to sprint all the time. You are right, serious projects are a marathon, and you have to pace yourself or you just get exhausted. Agile methods deliver regular results, but they are coercive, and therefore painful. Whereas waterfall methods aren’t dynamic, they don’t adapt well to changes in requirements or environment, and the milestones are usually too far apart to stimulate consistent, continuous effort. Open source projects are often a better compromise, because they are not coercive, everybody volunteers and works within his capacity, there is usually a sense of community and the shared goal supports and rewards consistent progress.

    You may be interested in something I wrote on this subject, at http://psicom.com.au/blog/software-production-management

    Also, of course there are good reasons for us to work in offices. We are social animals, we need to be together to collaborate, share our goals, support and learn from each other. But again, this should be voluntary, according to the needs of the project and the team members. A fixed demand to work together is also coercive, and in my experience people do not give their best effort under coercion.

Leave a Reply