Do you have your core software development mechanics in place?

This week we are hosting the Agile In Action seminar series in Seattle, Santa Clara and San Diego together with Perforce , Klocwork and VersionOne . As the keynote speaker, we've invited the 2009 Gordon Pask Award recipient David Hussman - a visionary yet pragmatic software anthropologist who introduces himself as 'the dude', talks about dude's law and is a great speaker. There has been quite some interest for the seminars, I think the core message coming out from David and us hosting it around making agile work in larger scale environments resonates and we all have some great stories and experiences to share with the audience about this.
The agile movement has been around for at least 10 years now - being a Certified Scrum controller since a few years back I find it interesting how it's discussion has evolved in some perspectives and seems to have stagnated in others, and I'm reflecting on why. On the one hand, the principles of the agile manifesto were so maturely thought through and are so oriented around common-sense at a high-level such that once said or stated, I think there is not much more that generally can or should be added to it. On the other hand, we live in a very complex world and everyone's reality and their perception of it differs. With that said and given all the experience out there today of trying to scale up agile, I find it's really in the details where the value to the discussion is added these days, and this is also where I see us tools vendors playing such an important role of actually making things happen.
Working as an engineering team lead back in 2005, I remember taking some pioneering initial agile steps outside of the static process-oriented norm and realized immediate benefits, attention and success with our first daily scrums, pair programming explorations, backlog planning events and sprint demo's. I must confess me and my team did not do everything right but we were always very open-minded and reactive to change which really fostered a great, fun and learning working atmosphere. Another main take-away from this time is that we lacked a lot of the core mechanics to make agile successfully happen while still talking and focusing a lot on the organizational aspects of our working environment. In retrospect I also believe that was one of the most important reasons why our company as a whole eventually failed to scale out a broad agile adoption across the entire development organization and also eventually didn't survive the financial crisis storms in 2008 - focusing too much of going big with agile at the organizational level before making sure we had the majority of the necessary core mechanics in place. This is also one of David Hussman's key conclusions and take-aways from his talks - focusing on the right organizational issue at the right time and also knowing if and when you are ready and prepared to make that change.

So what are some of these core mechanics, crucially important for you and your organization (no matter if you're going agile or not)? I'm in no way trying to compose a complete list here, but the following definitely qualifies:

1. An understanding of your current development workflow. I encourage you to ask yourself the question of how you are producing your own software today and try to come up with some model representing it. I can guarantee you it will be a learning experience for anyone involved.
2. An architecture of your software that allows for incremental release. Not easy but it will make a tremendous impact if and once you succeed getting to this point.
3. A process that enables you to frequently deliver working software. If you're reading this blog post from me working at the company delivering the most advanced computation and process acceleration engines around , wouldn't you expect this being one of the core mechanics listed here? Enabling a process to deliver working software frequently has been the main topic of my talks during this seminar series and seriously, I can't emphasize enough how important this is for any R&D organization looking to compete in the 21st century. I'd be happy to talk more about this topic if anyone's questioning it.
4. A flexible configuration management environment that "stays out of your way", letting you as a user focus on your core software and product and not how the underlying CM-system is architected. One of our customers as well as seminar co-hosts Perforce just posted an interesting reflection about this on their blog here .
5. A QA environment that quickly and with confidence can turn the crank and assess the quality of your deliverables. Typically this means running a large proportion of automated tests possibly in combination with some manual exploratory, functional or acceptance testing - managing the execution and reporting of these tests is another area where usage of the unique technology provided by CloudBees can make a tremendous difference for you.

With this said - I know it's kind of late but if you happen to be in San Diego tomorrow, don't hesitate to come by and listen to some very interesting and inspiring talks where I promise you will learn more about how you actually would go about putting these core mechanics in place! More details here .