At the ALE 2011 conference, Rachel Davies held the first keynote of the day. She reflected on 10 years of Agile software development, and what this probably means for the future.

Rachel referred to the impact that inaugural meeting of 17 persons 10 years ago had. They came up with the name “Agile” for the things they were doing. They nailed down the values and principles of their work for everyone else to see and read.

Having attended the Agile 2011 conference, most of the original authors answered questions from an audience of 1600 people. Rachel applied Rudy’s Rutabaga Rule by asking “What’s our next problem?” She pointed out to the many fallacies most companies claiming to do Agile nowadays fell into. One example she picked is having planning poker cards doesn’t mean you are Agile at all.

Rachel took the Agile principles, and asked the audience whether they apply them in their working environment. Everyone participating was asked to stand-up, and sit down as soon as their daily work did not fulfill the principle she showed. As Rachel showed more and more of the twelve principles, more and more people in the room sat down. In the end, about twenty people of an audience of 200 people were still standing.

Rachel had three phrases from companies she visited. They all had in common the lack of daily communication between the project stakeholders and the development team. Rachel explained that Agile was build to challenge some of the underlying notions we have in our daily work. Something I learned as well from the context-driven testing school of thought back at CAST 2011, and James Bach’s context-driven leadership tutorial. Though James explained to not only challenge rules that don’t make sense to you, but also to challenge rules that actually make sense in order to understand them.

Rachel encouraged to focus on deliver value. From my perception this is one of the weaker principles. What does value really mean? As Jerry Weinberg once wrote in a book, he asked an audience whether they cared for quality. Everyone was raising his hands. If you asked the same audience whether they would like to deliver value, I supposed everyone would also raise their hands. This actually means, that there is a lot of ambiguity in the terms used. What does “deliver” really mean? What about “value”? Since everyone has a different interpretation of that, everyone will be subject to lack the notion of what really means, to be blind of their problems, and their flaws in their daily work. (On a side note: That’s why consultants can introduce improvements most of the time very quickly.)

Rachel continued referring to Story Mapping. She explained that Jeff Patton came up with this alternative based on the notion that a flat product backlog simply does not work. He applied out-of-the-box thinking to the problem, and came up with a multi-dimensional backlog by using Story Mapping.

Rachel got on to continuous delivery. One principle to deliver more often is by making the delivery more easy, or maybe more fun to deliver you software celebrating your success using more ceremony, i.e. by holding a delivery party. I personally have a two-fold reaction to that. On the one hand delivering with every commit is nice, but you might lack the realization that you broke down your system completely. James Bach and Michael Bolton examined such a system – a virtual online world – a bunch of months ago, only to find out that the system was actually really screwed from their perception, and they found it rather unusable due to several problems in the system. But it could be deployed multiple times per day, still missed the point completely.

Rachel went on to team organization. Software development is actually about people working together from day-to-day. Still many companies use dispersed or distributed teams in which most team members haven’t met each other before. Having worked with teams in Romania, Poland, Ucraine, Brasil, Malaysia, etc. I could resonate to that. Most of my colleagues at that time I haven’T met before. Still, it was hard to convince people to spend money and time to get us together.

Building good teamwork needs the right environment and relies on motivation. Motivation reminded me on the difference between intrinsic and extrinsic motivation. Actually, you can only demotivate as a leader or manager in an organization. That’s extrinsic motivation. With the right environment you stop demotivating your teammates. But still this leaves the problem to get them engaged with intrinsic motivation.

Rachel explained that Agile needs support from many areas within the organization. Hiring policies, line management, incentives, operations, and office furniture were rather revolutionary in the early days of Agile software development.

These folks still took the courage – a value which you can find not only in XP, that Rachel mentioned, but also is a core principle in Scrum software development. The early Agilists took the courage to change their working situation besides furniture policies in place that actually prevented them from working together properly.

Rachel encouraged the ALE audience to take the opportunities and learn from others how they work together successfully. Growing a community like Agile Lean Europe is among the best things that happened to Agile software development in the past ten years from my perspective.