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.