I have been blogging on this site for a year now and it has been lots of fun. With 82 articles and 33,000 visitors from 127 countries, I have made plenty of contacts that I would not have made otherwise and learned lots in the process.

A couple of people have commented that it is hard to print articles from this site and so I have created a separate page with some of the more popular posts as PDF documents for download or printing. Just click on the "Articles as PDF documents" link of the top right of this page.

Who knows what year 2 will bring, but I’d like to hear from you so I have added a “Suggest a Topic” email link too.  Drop me a line and if your topic catches my fancy I’ll write about it.

Thanks for reading.
Mike

While your initial reaction may be “none”, I would assert that your whole team are actually volunteers and we can benefit from recognizing this and treating them accordingly. All that paying people does is ensure that they turn up (hopefully) and then once they are at work they must want to contribute or else very little will be achieved despite all the outward appearances of them “working”.

Attending the Agile 2007 conference in Washington and witnessing the passion of people engaged in something they truly care about and volunteering on programs with likeminded people got me thinking again about the productivity of volunteers and paid team members.

Team member contribution varies on a scale ranging from being a net drain on the project, all the way up to passionate innovation.

On the left hand side of this spectrum we have instances of people actually negatively impacting the project. Either intentionally or through misguided objectives and actions, their presence on the team actually has a net drain on project productivity.

The next region “Passive Compliance” people do generally work on to-do items, but without much thought and without any passion for the task or goal. Unfortunately “Passive Compliance” is an all too common category for team members in large organizations who feel like “cogs” in a machine they have very little say in.

I’m heading off to the Agile 2007 conference in Washington DC next week so you can probably expect a short gap in postings here as I take in the sessions and events there. This year’s conference sold out early as it was capped at 1100 people due to venue capacity. Next year’s conference will be in Toronto and there has been a good dialogue on the Agile Alliance board recently regarding the objectives for the 2008 conference including optimal size and format.

An element I have suggested for inclusion is a stronger community involvement. On agile projects we let the users prioritize the requirements and I would like to see a similar approach used for Agile 2008. Agile Alliance members could be encouraged to suggest a conference theme and asked to vote on the splits for conference tracks (development, testing, project management, etc) as well as the formats (presentation, Open Space, workshops, etc).

The same could work for selecting presentations and papers too. Why not employ the Wisdom of Crowds and Participation of Crowds in choosing presentations also? Rather than having only a selection committee, give members the facility to vote for presentations using modern web 2.0 collaboration tools. Or if that is too radical and a selection committee is required to ensure a balanced mix of programs across the spectrum of agile methods, at least give 50% of the voting power to the agile community.

The tools to allow such mass collaboration are already available and being used by Amazon in UnSpun and Cambrian House in RobinHoodFund. I’m sure Agile 2007 will be a great conference and with more user participation, Agile 2008 can break new ground in user driven content.

I went to see a bad chiropractor a few months ago and his approach diminished my (already quite skeptical) perception of this medical practice. His outright dismissal of conventional medicine and biased view that chiropractic treatment is the only true solution to all ailments turned me away from him and from any benefits I may have found by continuing with his treatment.

I am not comparing agile methods to alternative medicine, instead I’m just pointing out that zealots who fail to acknowledge alternative views can do a lot to damage their profession. As proponents of agile methods, I believe we can make a stronger case for agile by acknowledging strengths of traditional approaches and explaining how agile can help common challenges, rather than by dismissing traditional techniques.

Encouraged by other recommendations, I visited a different chiropractor and received great benefit. He did not attempt to undermine traditional medicine, instead he explained how he might be able to help and we took it from there. My symptoms got worse before they got better, but I stuck with it since his explanations seemed reasonable. My “conversion” moment came when he also relieved some additional injuries I had been suffering with for many years.

I do not think I am alone in appreciating a considered approach. Most of the people I deal with in the business community are smart, conscientious professionals who are looking for successful projects. Yet, we see the actions of zealots and as a believer it is easy to be caught up in their damaging behaviour.

The following list outlines some common examples of how biased thinking can undermine the value of agile methods and offers some advice to ambassadors of agile methods for avoiding these pitfalls.

Dismissing the Waterfall Process
The waterfall process as originally outlined by Winston Royce in 1970 actually contains some really good advice. For a start it recommends that the waterfall process always be run at least twice for a project because you will not get everything right the first time. Also that there should be regular feedback loops and checks along the way to ensure things are working correctly. Take a look, here’s a reprint of the original 1970 paper, look at page 7.

Download original_waterfall_paper_winston_royce.pdf

Agile ambassadors could do better to offer agile as a solution to single pass waterfall challenges on software projects rather than a superior approach period.

Running down the PMI, PMPs and the PMBOK