One Saturday earlier this year I made 160-mile trek to Dearborn, Mich. for the Agile and Beyond Conference.
I wasn't giving a talk, nor had my employer paid the registration fee or given me paid time off. As an independent consultants, I bill hourly, so time away from work is time unpaid. (At least it was on a Saturday-no billable hours lost.)
That said, the Agile and Beyond registration fee (about $100) covered entrance to the sessions, lunch, snacks and a chance to talk to the vendors. A half-dozen were hiring; the others were selling software. One of my clients sent a few project managers to the conference. After the event, the engineering group switched to the LeanKit Kanban project management tool based on a conversation in that vendor hall.
For that reason, and many more, Agile and Beyond-like many a small, regional, nonprofit IT conference-proved to be well worth the time, money and effort. It wasn't just me; the event sold out and attracted more than 600 attendees.
Small Conference, Big Agile Sessions
Beyond the vendors, the content included keynotes by David J. Anderson, who brought the idea of Kanban to software engineering, and Steve Denning, who wrote The Leaders Guide to Radical Management . Lanette Creamer flew in from Seattle to give a talk with Matt Barcomb, who drove up from Ohio, about the use of exploratory testing charters on an agile project.
Anderson describes agile not as an engineering concept but, rather, as a culture or "tribe." His first example was the idea of measuring the "agile-ness" of an organization in terms of the number of agile practices it uses.
Anderson's point was that such measurements have no direct connection to an actual business result or sociological outcome. To that end, he encouraged teams to consider the local context instead of adopting a cookie-cutter process.
Anderson also said that agile software development turns the old cost-of-change curve on its head. He insisted that perfect up-front-planning is expensive, often wasteful, and that it is better to make forward progress, get quick feedback and adjust than to try to prevent mistakes through perfect planning.
Meanwhile, Todd Kaufman gave a refreshing talk on agile metrics that matter with a subtitle of "How to stop abusing yourself and others with metrics." His first example was an agile team that split its work into springs and counted average velocity, or story points per iteration, to make predictions.
The problem with averages, of course, is that you are below average half the time. When the team missed its initial estimates, it needed to catch up, leading to either shortcuts that hurt future speed or, possibly, inflated estimates. Either approach hurts, rather than helps, long-term behavior. Kaufman thus recommended metrics that answer a particular question at a point in time. This is a welcome alternative to heavyweight tracking, especially if there are ways to game the system to hit the numerical target.
Analysis: Software Testing Lessons Learned From Knight Capital Fiasco
Finally, the exploratory testing talk exposed the elephant in the room-there are entire categories of software defects that automated tests tend to miss but are obvious to a person actually using the software. Creamer and Barcomb introduced the idea of testing charters. These are equal in weight to a development "story" and make the human tester's work visible to the entire team.
While the testing material was wonderful, the real value in the session was its multidisciplinary nature. Attendees included developers, graphic designers, managers and a handful of testers. One of the larger sources of waste I see in software is a mismatch in expectations among roles; these sorts of sessions eliminate that friction.
Candid Conversations With Agile Leaders
The biggest surprise of Agile and Beyond came not in a conference session but in an informal, around-the-table conversation in the dining room before lunch. People like Michael Drzewiecki, a project manager who drove to the event to pique his personal interest; Ron Jeffries, a co-author of the Agile Manifesto; Dan Neumann, an agile coach based in Michiana (an economic region in northern Indiana and southwestern Michigan), and Chet Hendrickson, who worked on the Chrysler Comprehensive Compensation System often cited as the original extreme programming project, all sat down table and just started talking about software development.
First we talked about the line manager's role in agile development. In an agile environment, you'll find a sort of self-organized, self-directed, multi-disciplinary project team.
If that's the case, then many of the traditional responsibilities of the "boss," from meeting with customers to slicing the work up in little boxes and handing it out, are delegated to the team. What, then, is a manager to do?
On a high-functioning team, Jeffries said, the need for a front-line manager decreases; the role, then, is unclear. The group agreed that there are some unique skills a manager can add, including technical leadership, a deep knowledge of onsite systems and processes and the ability to deal with HR in order to keep the team functioning. (A manager promoted from within might have these insights, but an external hire is unlikely to.)
How-To: Hiring Software Developers: The Agile Aptitude Test
From there the discussion turned to agile software development-specifically, the meaning of the phrase "... and beyond" in the conference's name. Jeffries took a marker and a piece of paper and drew something that looked like the image below. Jeffries' point: To get to "beyond," you have to go through "agile."
The rage at the conference was the Kanban method, which focuses on dropping iterations, limiting work-in-progress and achieving "pull" for work.
Jeffries suggested that teams "skipping" agile to go to Kanban will be restricted by a series of classic problems. Teams missing this step will end up playing the what-to-build telephone game, which a traditional agile methodology would rectify. Likewise, if a "beyond" lacks strong technical practices such as pair programming, test driven development or exploratory testing, it will struggle to reliably deliver software that works.
"Beyond agile" is a good ideal, Jeffries said, but he reinforced Anderson's comment on context. Teams need to find and fix their own pain points instead of jumping to solutions that solve someone else's problems somewhere else.
How-To: Rethinking Software Development, Testing and Inspection
Our conversation continued for two hours. We told sob stories and got some sage advice from some of the best minds in the business.
All this for $100. I wish there had been a tip jar at the registration desk.
Take Networking to Next Level at Small, Regional Conferences
To many software professionals, a conference is something those "other" people do-you know, the ones who work at companies with free lunch buffets, afternoon massages and the mini-lap pool. Conferences cost thousands of dollars and days away from the office work. You and I may agree they are worth every penny, but convincing the boss is another matter.
Agile and Beyond is one of many conferences offering an alternative-you can go on your own, as I did, or your company can send an entire team for less than the out-of-pocket cost to send one person to a major for-profit conference. These events are also common. In addition to Agile and Beyond, my neck of the woods features the Great Lakes Software Excellence Conference (Grand Rapids, Mich.), CodeMash (Sandusky, Ohio) and That Conference (Wisconsin Dells, Wis.).
Don't let a lack of funds or time off from work stop you from attending a conference, either. You can start small-at a free Saturday conference, for example-and open it up to anyone from your team who wants to go.
These conferences have benefits beyond the traditional conference session. They allow local people to connect, combine ideas and dig into the problems they face at work. You can then meet again for coffee a week later to continue the discussion.
It is at these little conferences that speakers present the new ideas and experience reports that become the extreme programming and Kanban of tomorrow.
I am planning to attend more of these events and share what I learn. You might want to consider them, too.
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Read more about agile in CIO's Agile Drilldown.