The ‘Secret Sauce’ of The Path to Agility
Yesterday’s Path to Agility conference in Columbus, OH was characterized by extraordinary energy. To start with, four hundreds participants in a regional conference is quite remarkable. Four hundreds participants with ‘infinite’ amount of energy all day long is quite extraordinary.
What is the ‘secret sauce’? According to Bart Murphy, Vice President of Solutions Delivery at QuickSolutions, the ‘trick’ is concentration of energy that usually gets spread over three or four days of a conference into a single day. A large number of interactions in a short time span create intensity and passion that are contagious. The energy flows from one person to another, from one group of people to another, creating an amplification effect that engulfs all participants.
You really had to be there to fully appreciate how powerful the experience was. You might not live close to Columbus, OH, but you owe to yourself to consider attending The Path to Agility 2011. And, don’t miss it for the world if Bart & Co. decide to apply their secret sauce to an Agile event close to where you live.
Thank you Bart, Jennifer, Matt and the other organizers and volunteers at COHAA – it has been a unique experience!
Written by israelgat
May 28, 2010 at 8:32 am
Posted in Events
Tagged with Bart Murphy, COHAA, Jennifer Bleen, Matt VanVleet, Quick Solutions
2 Responses
Subscribe to comments with RSS.
The Agile Executive 
I was impressed by Israel Gat’s presentation about technical debt, where he said two things I found fascinating.
One was when he suggested that technical debt could be–without too much loss of generality–be quantified in dollars, rather than only in subjective terms like “a little” or “a lot” or “probably less than our last project.”
The other was when he said that technical debt could be frequently assessed (in dollars, if desired) automatically by a continuous-integration server with measures like cyclomatic complexity and code coverage.
My own contribution to the discussion would be that such an assessment, while still probably useful, could only be treated as a lower bound. In the project where I’m presently engaged, for example, we have perhaps twenty tech-debt cards on the wall, of which maybe three would be accessible to a CI server.
I don’t think any CI server will ever be able to detect technical debt like “In pulling down the example data from production, we forgot to install a particular class of database constraints, and may have to go back and do it eventually,” or “Figure out how to build the Grails project with Maven.”
Dan Wiebe
May 28, 2010 at 9:12 pm
Thanks for the kind words, Dan!
A key differentiation one needs to make to make with respect to technical debt is intrinsic quality versus extrinsic quality. Jim Highsmith has an excellent discussion of the subject in pp. 329-333 of Agile Project Management: Creating Innovative Products. I will try to briefly demonstrate the concept here by the following analogy:
I have an itch in my left ear. Naturally, I scratch the ear with my my left hand. However, I might scratch it with my right hand. The two are functionally equivalent. However, the intrinsic quality of scratching with my left hand is far superior to that of scratching with my right hand. If I were able to apply source code analytics to ear scratching, I would find the complexity and the technical debt of scratching by the right hand far exceed those of scratching by the left hand.
In other words, technical debt is only about intrinsic quality. Various things you need to carry out in your project are not part of technical debt.
To summarize, the power of the technical debt concept is in its singular focus on intrinsic quality.
Best,
Israel
israelgat
June 1, 2010 at 6:25 am