Wednesday, November 10, 2010

From Weak Links to Better Answers

Some of the implicit questions driving me for the last couple years in the work I did for the Agile Skills Project were: how do we know who to trust, who has good advice, and who should we hire? The answer to these questions have a lot of value, as proven by the market demand for CSMs and other tech certificates, as well as for the hefty price recruiters get for matchmaking services. Yet when these matches depend on keywords in a resume, or on a recruiter's personal network, we hit one of two limits: keywords don't convey trust, and humans have a neurological limit of about 150 trusting relationships. So how do we broaden our searches for advice and/or recruits beyond 150 people? It's easy for clear-cut, objective answers--we can depend on the wisdom of crowds using things like Google's page rank algorithm, which represents the crowd's endorsement for certain advice. For more subjective questions, though, it is much more complicated.

Yesterday I read about weak links / weak ties in Enterprise 2.0 by Andrew McAfee--it reminds me of the fabric Peter Block identifies as social capital--and apparently the research about exploiting our personal networks was published relatively recently, in 2004 or 2005. McAfee suggests that the next way we'll be able to benefit from platforms like LinkedIn, Twitter, and FaceBook will be in referring our colleagues to our FAQ pages. This strikes me as really powerful for objective questions, but misguided for subjective questions. It's not the answers that my network of friends are useful for--it's the diversity of approaches they offer that is important. Since it's a subjective question, it is the analysis of factors, values or forces that will help guide me. I don't know of any scalable resource that connects people for subjective questions in this way. Do you?

There are technologies that connect people by the questions they ask--take the Stack Exchange engine for example. Yet they specifically close subjective discussions:

...questions that are not answerable — discussions, debates, opinions — should be closed as subjective. It seems simple enough: Fact good; opinion and discussion bad. But why?
Most forums and chat rooms have a scale problem. As in, they don’t. The more people that join the discussion, the more noise each of those connections bring. So the forums get progressively noisier and noisier, and suddenly one day … you stop learning.
This seems to leave a gap.  Subjective questions often produce conflicting advice on list serves. How do we sort through the answers? I don't see any of these social media platforms helping me decide who to trust. What if we built a community of questions and analyses--no answers permitted, just a catalog of the values, forces, etc. that go into making a decision. Anyone want to help me out? The first place I might begin is at Stack Exchange--but we'll need about 250 committed users to go live. Let's work out some of the details first--post your questions/comments here. One thing I will have to work out near the end is the name--should it be DevIntent, Philly Tech Points, Agile Welcoming Circle, or something else?

Would you such a site useful? Would it help you answer your questions? Would you participate in it?

Sunday, November 7, 2010

Agile Tour Philadelphia 2010

This year, Sebastian Hermida, Bonnie Aumann, David Bulkin, Ravindar Gujral and I tried out a new conference format--and it worked out splendidly (photo album). Essentially, we wanted this to be a conference for local practitioners, by local practitioners. We sought to encourage networking and group discussions, so we divided up our 4-hour conference into a keynote by Jon Kern followed by 4 x 45 minute-long sessions and a little time for breaks. Each of the organizers invited a friend to do a talk, and we got a great lineup including:

  • Bonnie Aumann (The Flow Game)
  • Aman King and Prashant Srivastava (Agile Buzzwords in Action)
  • Sebastian Hermida (9 simple rules for code design)
  • Prem Chandrasekaran (Automated Functional Testing: Getting it Right)
  • Burkhard Duemler (An Incremental Move to Continuous Integration)
  • Ravindar Gujral (You Get What You Measure)
  • Audrey Troutt (How Agile is like Yoga: this $h!t is really hard but it feels good)
  • Daryl Richter (Don't Replace That Old Application, Re-upholster It!)
  • Andre Dhondt (Working with Difficult Customers)
  • Brian Donahue (Software Craftmanship: Building a Solid Foundation)
  • Darian Rashid (Personality Types)

At the beginning of each session, all 70 or so attendees met in the middle of one large conference room, and speakers each had a chance to do a 60-second lightning talk to catch the interest of attendees, and to announce where they'd be doing their talk. Within ten minutes everyone had shuffled over to their chosen sessions, which lasted 25 minutes before a 10-minute break and then another round of lightning talks. This format gave people a lot of time to meet one another and explore topics of their own interest--which kept energy high and made it really fun. As an organizer I felt responsible for making things flow--so I couldn't fully participate in any of the sessions, but I did act like a butterfly and go listen in on at least a couple minutes of every talk I could.

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.