Agile Open Northwest

By Brian Walsh, president, bwalsh.com inc.

Many projects fail and very few fail due to technology. Most fail due to people issues. Software seems to evolve at the rate of bacteria, constantly adapting to the natural selection of competition. Not so with us poor humans – our rate of evolution can’t keep pace. Project methodologies in part categorize the human characteristics that predict how we behave under the stresses of tight timeframes and budget.

Over the past decade the emergence and rapid evolution of agile methodologies have helped to decrease project failure. The Standish group has reported a 100% improvement in project success rates since 1994. If there was any doubt, the reduction in project size and shortened iteration cycle contribute greatly to this result.

Agile methodologies focus on iteration and interaction

All of the agile methodologies (XP, Scrum, etc.) share a common core. They focus on the iteration and extol interaction and communication. They also emphasize the delivery of working software and de-emphasize resource-intensive intermediate artifacts. According to Wikipedia, “Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration.”

I’ve recommended agile methodologies and used them for years whenever the customer and project dynamics allow. It all seems very intuitive. I have to admit that project methodologies are not the type of thing that keeps me up at night. It would take a month of motivation to spend an evening with a PMP book.

Agile conference adopts open spaces methodology

So when I saw the notice for the Agile Open Northwest conference, I decided to go. There is no easier way to get the intellectual batteries charged up than by listening to smart people talk. Plus, the price was right and I’ve always enjoyed the Kennedy school – small, comfortable and local.

I have to admit I didn’t delve too deep into the proposed sessions and speakers. One of the pleasant surprises of the conference was its organization. In other words, when I showed up, there was no agenda, no set speakers. The conference was organized using the open spaces conference methodology – an approach to structuring meetings that allows groups to self-organize, create an agenda and solve complex problems. In other words, the conference tries to capture human behavior where the best learning takes place over coffee and where most decisions are made in the hallway. I went to a traditional East Coast Catholic primary school. This conference gave me insight into what it would have been like to go to a Montessori school – an opportunity I never had as a child.

The conference hosts invited the attendees to get up in front of the crowd, pitch an idea for a session, schedule it and then facilitate it. After a little apprehension, I and 60 other folks summoned up the courage to propose a session.

Session topics included:

The attendees documented the sessions on the fly as the session notes grew over the course of the conference. For example, the session on “Finding the Right SCRUM Product Manager” documented the group’s thoughts on the product manager’s responsibilities and the need for authority, as well as the ability to question requirements and track down business value for functionality. The session on “Black Box to White Box – Code Metrics” discussed the importance of metrics in agile project management and introduced the idea of technical debt “cards” to externalize debt introduced by the team to meet a goal. This allowed attendees to dive deep into specifics of project management.

“The Importance of Slack” covered the slack time in project schedule; how is it valued, can there be too much and structure slack/creativity?

“Black Box to White Box – Code Metrics” covered the use of metrics as another factor to provide additional leverage to affect product quality.

“180 Degrees at End of Iteration” covered the boiling frog syndrome, in which no one notices the shortcomings of the project or feels empowered to speak up and change direction.

"Agile Phobia” discussed the fears preventing adoption of agile practices. Agile is more disciplined than conventional development in some respects, less disciplined in others. Some people fear the perceived lack of discipline. Others fear the introduction of new kinds of discipline. This session provided an insight into the mindset and enthusiasm the attendees had for working in a project team. Their solutions for dealing with obstacles to agile adoption included:

• View the resistance as a resource and honor it. Resistance is a piece of new information about why something might be a bad idea.
• Talk about “why” before “how.”
• Lead by example/enthusiasm.
• Introduce agile development in small steps at first (“Let's just try this”).
• Be open to changing/retracting things that didn't work.
• If possible, start by doing agile with the subset of the team that is most interested in it.
• Phrase it as an invitation rather than a demand.
• Make it an experiment and time-box it.

Everyone expressed interest in the quality of the attendees, their depth of project experience and the willingness to contribute and listen to other points of view. There is no better way to learn from others’ war stories without having to live through the project. The group intends on offering the conference again in Portland and/or Seattle. Check out their website at http://www.agileopennorthwest.com/.

About the author
Brian Walsh runs a Portland-based service firm. His practice concentrates on enterprise software – providing counsel, architecture and development. He enjoys the hands-on approach and divides his time between policy issues and technical challenges. Previous articles have appeared in Network Computing and theServerSide.com.