Last week I enjoyed to opportunity to speak at the Agile2010 conference in Orlando, Florida. Of course, I also attended many of the other sessions as well. The conference has in my view an excellent atmosphere. Where I expected to find lots of consultants in their typical formal style of dressing I found 1400 people mostly dressed in T-shirt, jeans and sneakers instead. This must be the result of the Agile movement itself where people are first class citizens right? The portfolio of Agile2010 contains ‘hardcore technical’ sessions like tutorials in Clojure coding, real ‘softcore’ sessions like “Behavior Driven Development for Life” which advocated using Neural Linguistic Programming techniques straight from psychology and also sessions around themes like Leadership and Coaching. Don't worry, the conference organizing committee splits these nicely up in ‘Themes’ and ‘Stages’ so even if you only look at the program by a glance, you’ll hardly ever end up in an unwanted session. This is what I picked up from the conference in summary (you'll find all the details below):
- Conference focus (or lack thereof)
- "Religious wars" between Scrum, Kanban, Xp, Lean, ...
- Agile adoption in organizations worldwide
- "Value points" (compare to "Complexity points")
- Company improvement backlog
What I picked up
“Religious wars”The Agile movement is known to suffer from what I call “religious wars”. There are individuals advocating particular Agile styles like Scrum, Lean, or Kanban and telling their audience to forget about the rest. Luckily most leaders in the Agile movement advocate that ‘Improvement’ of your current way of working and constantly trying to improve yourself is way more important than picking the particular Agile flavor and trying to stick to it. I noticed this in the keynote sessions of Dave Thomas on Monday, in the keynotes of Ron Jeffries and Chet Hendrickson on Friday as well as in the closing keynote by Mike Cohn.
Agile adoptionFor me personally the “Agile Mythbusters” session by Scott Ambler on Wednesday was revealing. Scott has performed a number of industry surveys over the last four years in e.g. Dr. Dobbs, and we can now accept or reject “Myths” about Agile to a pretty good extend. Some intriguing examples: These myths are True:
- Majority of organizations is using Agile: 69% in 2008, 76% in 2009
- Agile works better than traditional (waterfall). Although this is true on the big numbers average, 'better' is still a close call!
- Most Agile teams are co-located (!!!)
- Most teams claiming to be Agile, are indeed Agile
Value pointsI picked up a very small idea that I will start to use immediately. Someone just used the term in the middle of group discussion during a tutorial style presentation but it was new to me. He mentioned “value points” indicating the relative business value of a user story comparable to "complexity points" that indicate the relative value of the effort needed to develop a user-story. It for sure will help my team in:
- prioritizing (# value points divided by # complexity points!!!)
- discussing with stakeholders
A book called “Switch”The most referred to book at this conference was “ Switch: How to Change Things When Change Is Hard” by Chip and Dan Heath. I have not read it yet, but for sure will. It addresses changing organizations and make sure the change is there to stay. From Mary Poppendieck’s session I picked up the key three themes in "Switch":
- motivate the elephant
- direct the rider
- shape the path
Company improvement backlogOne final item I’d like to share with you: Mike Cohn’s idea to introduce an “Enterprise Transition Community” and a number of “Improvement Communities”. The idea is to formalize ‘continuous improvement’ in organizations by introducing a ‘Company improvement backlog’ maintained by the “Enterprise Transition Community”.
My own experience as a speakerI presented an experience report called “Unleash the Agile Power: Bridge the Gap between Development & Operations”. I presented the typical characteristics of ‘Development’ and “Operations’ departments in enterprise size organizations and argued why these characteristics cause a natural gap between the two: where Development wants to change things, Operations wants to keep this stable. I continued arguing that adopting ‘Agile’ methodologies in ‘Development’ has an impact on ‘Operations’ that widens the gap and presented two possible options for bridging this gap:
- add Operations people in Development teams
- eliminate the hand-over from Development to Operations by automating all deployments with, e.g. Deployit