the Philly Agile community

In the 9 weeks since I've been back to Philly, I've been able to attend about 8 events (hosted by Agile Philly, Philly SPIN, and Lean Startup Philly, and I missed one I wanted to go to--Philly ALT.NET). It's such a vibrant community!  For the past couple years I've been trying to blog about every event I attend--but I'm having a hard time keeping up this time. So this entry will try to capture some of the highlights.

Lean Startup Philly is reading a book together: Steven Blank's The Four Steps to the Epiphany. We meet at lunchtime weekly to talk about the book and then how to apply its principles to the startups each of us are involved in.

Philly SPIN had a packed house for Jim Schiel's Sept 22 talk on "Quality and Productivity Metrics in Agile Development". Since I'm a big skeptic of any kind of productivity measurements, I was really curious to see what this meeting would be about. I asked a lot of questions to see how Lean/Kanban principles were being applied in the context of his clients--and basically, I get the opinion that the Scrum community seems very straight-laced. It's interesting to me because the XP community has stayed very open to changes, doesn't seem to claim intellectual property over its ideas, and often incorporates new things. Jim began his talk with a couple of really great questions--if we don't have big, up-front design documents and estimates in projects, then how can we tell if we come in ahead of schedule? How can we tell how productive we're being? I'd love to have an answer to this--though I don't know if there really is one. Software development can't be about efficiency, it's got to be about effectiveness. So then Jim continued on to talk about how high quality is a necessity for being productive, as well as being able to incorporate change into the plan, how we need to avoid overworking the team, and that we need to be cautious about what we measure. He proposes using the following measurements, not as a way to gauge productivity, not as a way to compare teams, but as indicators that there may be a problem, or even that things may be improving:

• change in velocity
• change in defects
• number of completed stories

Agile Philly has had two Code Kata nights. At the August 24th event we tried some Architectural Kata, by working from the dry erase board. Though we didn't actually use our computers this time, it was a great chance to work on collaborative design, and I learned a new technique from Sebastian Hermida, who will be presenting it next week at Bar Camp Philly. On his teams, they wanted to get everyone involved in all the architectural decisions, so at daily sprints they'd try to sell their implementation strategy--and team mates could buy or not. If not, that triggered further discussions. Later, after coding a story card complete, the pair will again try to sell the card--to make sure everyone is on board. It sounds like a fun and innovative way to encourage team ownership of the design of all the code.
At the next Coding Kata event on Nov 4, Audrey Troutt led us in 10-minute pair rotations for the bowling game using Jeff Bay's 9 rules for "Object Calisthenics". It was really intense, really fun, and felt great to think about how we write code. We paused half way through and talked about what was happening, then spoke again at the end about what we might want to do differently.

Agile Philly also hosted an Agile Tour stop this year. I'll write about that separately.