I spent the day in Portland’s Norse Hall with about ~180 other agile practitioners. We were there for a Software Association of Oregon open space event to discuss rthe relationship between developers and QA in Agile projects.
It was the 3rd or 4th Agile open space event I’ve attended, and as at previous events, I met some really interesting, accomplished people. I also confirmed (again) that the agile process that we built at my previous job was actually fairly mature and effective relative to our peers. As one of the people with a big hand in developing that process basically from the ground up, that makes me feel pretty good. And to the extent that I can share some of the lessons learned and best practices, I do so. So this morning at 11:00 I co-hosted a talk on “overcoming geography” – how to create and sustain an Agile software development process when some or all of the team members are remote.
The talk was well attended – maybe 40 people – and the discussion back and forth was lively and varied. You can view my raw notes from the discussion here. A good portion of the talk centered around offshoring and/or outsourcing, which was not part of my original intent – telecommuting being more in mind as I proposed the talk – but the people who are actively managing offshoring teams gave a lot of really great advice.
The other sessions I attended were:
- a session on common non-technical problems agile teams face and how to fix them
- a session on what to do if you don’t have stories to work from
- a session on what to do if you don’t have a QA team
As is typical with open space talks, the discussion ranged broadly, and I picked up several good nuggets of wisdom. Among them:
- Instead of focusing your retrospective on what bad things you need to avoid, maybe focus instead on what good things you can do more of.
- Automation, while it has its place, is not the Holy Grail of QA achievement, and there is still very much a place for “traditional” QA activities.
- It’s good to focus very clearly on three or four things with user stories:
- Get to a shared understanding of what the story encompasses. We used to call this a system metaphor in XP.
- Describe clearly what done means.
- Write stories that are testable.
- Don’t put too much effort in early requirements – stay ahead of the dev teams, but not too much.
- Disconnected product management or project management organizations can be problematic unless that org is good at, and buys into, Agile project planning.
Speaking of system metaphors, this event suffered,IMHO, from a lack of a clear understanding of the intended topics. So the suggestions for talks ranged all over the Agile landscape – estimating, planning, availability of customers, etc. It all trended toward QA, but not as clearly as I might have hoped. In that sense the “blurring” part of the event title may have presupposed a little too much specificity to an otherwise broad topic.
Other areas for improvement:
1) I would have had fewer meeting locations. We had nine locations in two large rooms, and the initial set of talks proposed were whittled down to 5 or 6 simultaneous talks per session, which seemed about right.
2) The acoustics at this particular venue were terrible for holding simultaneous sessions in the same room. As my hearing gets worse (thanks, Dad), I had to really lean in to hear some of the soft-spoken presenters or commenters.
3) The process of getting into the wiki used for posting notes was near-incomprehensible, and I write and use software for a living. I would recommend a different, more UX-driven, wiki platform for future events.
One thing I’m really interested in is the role the SAO played in the envisioning, planning, and theming of the event. Passive? Active? I’m not clear on the overlap of roles and organizations among some of the leading Agile practitioners in Portland, so it may be that the SAO was nominally a full partner from Day 1 of the planning. The SAO is sort of like the WTIA of Oregon, or so I gather, so I wish really good things for the organization and the people who contribute time and energy to the group.
If you’re interested in going back and discovering some of the real-time notes, we used the hashtag #pdxblur on Twitter.
