Do you really need those pesky users on your project, forever changing their minds and requesting new functionality just as you are about to be done?

When I was at school, my physic’s teacher was fond of telling us that, "if it were not for the students I would enjoy teaching." The same is true for users, they may cause us issues and headaches, but they are the reason we are there and developing software in the first place.

Why we Need User Input
The truth is that on agile projects we do not want user input we actually need user input in order to be successful. Agile projects are deliberately light on capturing initial requirements because we realize that requirements are likely to change, and evaluation of an emerging system will surface new requirements and improvements to existing requirements that we want to encourage.

This year’s Agile conference in Toronto this August will be structured slightly differently. Following a music festival structure, the conference will be divided into “stages” to cover different topics. I was able to visit the Agile 2008 conference venue in December when the last Agile Alliance Board meeting was held there and we toured the facility with the Agile 2008 Conference Committee.

Johanna Rothman and I are the “Leadership and Teams” chairs for the conference and we have been allocated a great venue; a large, bright ballroom with high ceilings and lots of natural light. This year the conference has much more space and larger mingling areas both indoors and out which I am sure will help.

On the “Leadership and Teams” stage we are looking for submissions on, you guessed it, leadership and team focused experience reports, research papers, tutorials, and presentations. Now is a great time to submit a proposal, so take a look at the submission system and propose your ideas.

The other element I am excited about is the submission system selection process. I have written previously about encouraging the agile community to prioritize our proposal backlog (list of submissions) and this year it is happening. On the Drupal based submission system anyone can write a review for a session and “up-vote” or “down-vote” a proposal. The cumulative scores for proposals help determine what gets selected.

This will not be a totally crowdsourced selection (like ideagora: Cambrian House), instead panel review will still be involved, but it is great to see the conference users (attendees) involved in prioritizing the features (proposals) for the event.

So, head over to the submission system and up-vote your buddy’s submission, down-vote anything from that guy that won’t return your emails (only kidding) or better yet, submit something valuable on Leadership and Teams for the conference, we would love to see it.

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

I have written a few posts now on estimation and so I thought it was time for a summary. Also, I am planning to create a series of one page best practice summaries / cheat-sheets for agile and this seemed like a good candidate.

(I am a real fan of one-pagers; there is special value in getting everything visible and presented on one page that brings unique scope comprehension and clarity.  Toyota and other lean organizations make heavy use of A3 reports, a one page summary of an issue, its root causes, countermeasures, and verification steps to summarize problems and planned solutions - they are powerful tools.

Incidentally, when I first started work I had a wise and cantankerous project manager who was full of oxymoronic proverbs. One I remember was “If you cannot summarize it on only one page, you need to go off and learn more about it!” An astute paradox.)

Anyway, here’s the summary; if you want more explanation on any of the points, refer to my previous posts (Upfront Estimates, Estimation Techniques, Estimate Ranges) on agile estimation.

Is agile about new tools and techniques or more a mindset? Philippe Kruchten asserts “agility is not a technology, science, or product but a culture”. This makes sense to me; innovation comes in waves (object oriented programming, business process engineering, lean production, etc); and while they all have their merits, most fail to deliver the full potential of their benefits because people concentrate on the process rather than the mindset. At the heart of agile is a mindset not a toolset.

I was speaking to Christopher Avery today, author of “Teamwork is an Individual Skill” and he shared some thoughts on personal agility and team motivation. Christopher is great for this since he approaches agility and team work from a psychological side whereas my thoughts are usually based on observation and trial and error.

We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.

Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within.  People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.

At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!

Telling someone what you really want to get out of a project might seem a little odd too, but fears of doing so indicate a ‘scarcity model’ to information. Why should we worry if people know what we really like to do or gain, chances are they will make opportunities available for us to do them. Helping others get what they want from projects creates an upward spiral of support and co-operation, which when you think about it, is the heart of a winning team.

Chatting to Christopher is always refreshing, he shares so much useful information that I struggle to retain it all. Fortunately for us Chris has recorded a free tele-seminar on Mastering Personal Agility. I heartily recommend it, the people side of projects have the greatest leverage, even small improvements here can yield large benefits; be sure to check it out.

Customer: How much is that parrot in the window?
Pet shop owner: Somewhere between $200 and $250
Customer: Erm, OK, I’ll give you $200 for it then!

To some people providing estimates as a range of values seem a strange and unsatisfying way of conducting business. They just want to know how much something will cost, not how much it may or not cost. This is reasonable if the object or service is ready for use, but not if it has yet to be created. The more uncertainty involved in the process the more likely there will be some variability. Now consider this conversation:

Customer: How much will it cost for a taxi ride from the library to the airport
Taxi driver: Probably between $20 and $25, depending on traffic
Customer: OK, that sounds fair, let’s go

It seems more reasonable, we understand the variability of traffic. Unfortunately not all stakeholders understand the variability caused by evolving requirements and changing technology often associated with software projects. However the uncertainties of software development are real and we have an obligation to report estimates as ranges to help manage expectations.