The Agile GIS survey will be closing at the end of this weekend.  If you haven't had a chance to take it yet, please do.  It takes less than 5 minutes to complete and doesn't require any corporate, personal, or confidential information.  So far I've received over 330 responses and the results are pretty interesting.  I'll be posting the results and an analysis sometime next week.  Click here to take the survey or visit http://www.surveymonkey.com/s.aspx?sm=ZVYGPQ7Lzi61A28IU7t_2f1g_3d_3d

I received several e-mail comments on my last post on agile meetings.  The most common was not about the cost of the meeting time, but about the inability of people to make all of the meetings.  Some of the comments suggested having a wiki or something similar to share the results of each meeting with team members who could not attend the daily stand ups etc.  Others suggested recording the meetings using conference calls or Webex-type recordings.  I would have to voice my opinion that I don't think either of these are good ideas.  The daily stand up is an essential synchronization point for the team and should be attended by everyone everyday...unless there are really extenuating circumstances.  Planning meetings, reviews and retrospectives are equally important and demand the attendance of all team members.

There are three key points I'd like to make about documenting agile meeting minutes.  First, I believe that the more you enable people to not attend agile meetings the more you encourage the behavior.  If team members have no place to read about the meeting or hear a recording, they're forced to attend the live meetings.  If team members can simply miss a meeting and read a wiki entry about the meeting, while adding their own update to the wiki, you've enabled and encouraged the behavior of missing meetings. 

Secondly, in agile development, we focus on developing working software, not creating documentation.  I believe this extends to meeting minutes.  If we time-box a daily stand-up to 15 minutes, that should be all we spend on the meeting.  If we're required to document the meeting for those that missed it, we're spending valuable development time writing up the meeting minutes.

My final point is in regards to a collaborative, tight knit team.  If we enable people to miss meetings, we begin to degrade the collaborative team environment that agile practices thrive upon.  The daily stand-ups and other meetings are a chance for the team to communicate with each other.  It encourages a collaborative team environment.  If team members are enabled to regularly miss meetings, they're less likely to feel a part of the team and less likely to commit to the team goal each iteration.

So, to wrap this up....don't enable people to miss meetings.  These meetings are crucial to the success or failure of your agile practices.

This month, Dave Bouwman and I authored an article on agile project management for GIS development projects in GIS Development Magazine.  The article was published in the hard copy magazine and is now available online also.  If you're interested in reading the article, check it out here.

I've spent the past few days at the ESRI Petroleum Users Group Meeting in Houston.  I've had the opportunity to sit through plenty of presentations in 3 days.  I would have to say that not a single one was captivating, exciting, motivating...interesting.  Please don't rush to their defense and say "Well, petroleum GIS is pretty boring, what did you expect?".  Before you utter those words, I ask you this question: What do you think about copyright law?  Pretty boring subject matter, right?  Wrong...watch a presentation at the TED talks by Larry Lessig and you'll agree, even dull topics can be presented in a lively, exciting, motivating, and interesting manner.  Check it out here at the Ted Talks website.  But, let's not be so hard on the petroleum GIS world...let's be honest, 99.9% of all PowerPoints suck and we all know it...and for you Apple people out there...your Keynote stuff ain't much better.

So, please, let's put an end to the meaningless waste of the human creative spirit and start putting some thought and design into our presentations.  If you're looking at your latest presentation and it's full of slides with bullet points, charts, animations, and those cute little stick figure guys please...delete it now!  You can do it, really.  Take a deep breath, select the file, and press delete...don't you feel better now?  (I know I do). 

Now that you've deleted it, enroll yourself in the 5 Step PowerPoint Recovery Program:

(1) Run, don't walk, to your nearest bookstore and buy Garr Reynolds' book Presentation Zen.  Then open the book, read it, absorb it...and put it into practice.  You'll be surprised at how much this little book will help to make your presentations absolutely killer.

(2) Read Seth Godin's "Really Bad PowerPoint".  Your PowerPoint was bad and Seth tells you why.  Now, aren't you glad you deleted it before?

(3) Visit the Ted Talks website.  Watch people who are truly inspirational deliver some of THE best presentations you'll ever see.  Aside from being inspired, take a hard look at why these people communicate so well, both verbally and visually.  Learn from them, you can be just as exceptional at communicating.

(4) Vow to never use a PowerPoint (or Keynote) template ever again.  You're a creative person (you just don't know it yet).  You can build creative, innovative presentations that leave your audience wanting more.

(5) Get a subscription to a good stock photo site (or use some of the great free ones out there) and stop using worn out, cutesy, and hackneyed clip art.  The little stick figure guys are cheesy, but you already knew that!

That's it!!!  You can do it and I beg you to please do it for all of our sakes.  Wouldn't it be great if you went to a conference, workshop, or seminar and saw a ton of awesome and inspiring presentations? 

My Agile GIS survey will be closing at the end of this week.  If you haven't had a chance to take it yet, please do.  It takes less than 5 minutes to complete and doesn't require any corporate, personal, or confidential information.  So far I've received over 320 responses and the results are pretty interesting.  I'll be posting the results and an analysis sometime next week.  Click here to take the survey or visit http://www.surveymonkey.com/s.aspx?sm=ZVYGPQ7Lzi61A28IU7t_2f1g_3d_3d

If you've been doing agile, and especially Scrum, you're well aware of the meetings that are required to keep things running smoothly:  (1) the iteration planning session, (2) the daily stand ups, (3) the iteration review session, and (4) the iteration retrospective.  If you follow scrum by the book, a two-week iteration would include 18 hours of meeting time (8 hours for planning, 15 minute daily stand ups, 4 hours for review and 4 hours for a retrospective).  That's 22.5% of an 80-hour schedule for an iteration that is consumed by meetings.  Many people argue that this is too much time spent in meetings over the lifetime of a project, especially if it's an overhead or operational expense.  I don't necessarily disagree.  However, these meetings are essential to effectively delivering value to clients and to the continuous improvement of a team's agile practices.  So, how do you handle this dilemma of balancing meetings that enable practices with project budgets, etc.?  The answer: Use the scrum mantra "Inspect and Adapt".

Our agile teams have examined our meetings and have effectively reduced our meeting time to the following: 2 hours for iteration planning, 15 minute daily stand-ups (and they're usually shorter than that), 1 hour for our iteration review (usually shorter) and 1 hour for a retrospective (again, usually shorter).  This amounts to only 6 hours (or less) of meetings for every two week iteration or 7.5% of the iteration spent in meetings.  We think this is a manageable amount of time to dedicate to the various necessary activities of scrum to be both efficient and effective.   I think that anything shorter than these times would probably start affecting the value of these agile practices.  We are still planning without any problems and we are able to review two weeks worth of work in 1 hour or less with our clients.  We have also found that 1 hour is more than enough for our retrospectives.  Currently, we include these meetings in our project costs because we bid our projects as agile projects.  Our clients are aware of the value these meetings provide their final product. 

So, based on our experience, I would suggest really examining the value of the meetings you use to keep your agile practices running.  If you and your team find that you are merely filling up time-boxes to do scrum by the book, inspect and adapt.  And remember, if you adapt your meeting times to be shorter and you are finding that you need more time for a review or for your planning session...inspect and adapt.  Scrum is an imperical "process"...keep experimenting with your meeting times until it feels right for you, your team and your product owner.  And, if you can agree with your client that these are project related costs that provide value and not overhead or operational costs, all the better for you and your client.

I've been spending some time at the ESRI Petroleum User Group meeting this week in Houston.  I had the opportunity to speak with several people who were interested in agile practices.  One of them posed this question to me: "If you had to use one word to describe why your team found success with scrum, what would it be?".  I thought for a minute.  Hmmm...discipline sounds good, and that was almost my answer.  Then the right word popped into my head...trust.  On our team, there is a complete level of trust amongst all of our team members. 

Trust works on several levels within our team.  There is the general trust in each other that when we commit to a backlog for an iteration, we will all work as hard as possible to complete those backlog items by the end of the iteration.  There also a level of trust that the scrum master and other team members will not judge team members at the daily stand up meeting or the retrospective.  This encourages an open communication of project successes and any impediments we are facing.  We report impediments not with the expectation of being looked at with suspicion, but being viewed as good.  If we can express our impediments openly, we all get better together...and that's our key to success...trusting each other to raise issues and problems so that we can continually improve.  This also creates an atmosphere that is very conducive to true collaboration. 

Although it sounds easy, trust is difficult to establish.  I shouldn't really say difficult.  It's that trust is not something you can just implement.  It grows over time and requires a mature team.  It also requires an organization that is willing to allow individuals to raise issues and problems in a judgement-free environment.  This is perhaps the biggest hurdle to trust.  Many organizations may be unwilling or unable to allow team members to express problems they uncover in the way a team works, etc., without a penalty.  True agile teams and organizations find ways to look at problems, issues, and dysfunctions as opportunities to grow and improve.  So, if I can give you one word to work towards as an agile team, it is TRUST.

After working closely with the good folks at Rally Software Development, we have launched the Agilistas website as part of Agile Commons.  The Agilistas website is a collaborative space for agile practitioners to share ideas and information with each other and the world.  Agilistas has a community blog where members can post their ideas and opinions, a news and events section to announce current news in the agile community and upcoming agile events, a file share area for uploading, downloading and commenting on files, a discussion board, and a page for Agilistas on LinkedIn. 

If you are not currently an Agile Commons member, click here to join Agilistas.

If you are currently an Agile Commons member, click here to join Agilistas.

Yesterday, I wrote about backlogs and what your team includes in them.  Well, it seems that backlogs are on my mind a lot this week.  Today, I was working on a backlog for a new project and was considering what should be in it.  How far ahead should I be looking and what should the granularity of the stories be?  This brought to mind the idea of planning horizons and prioritization. 

The backlog I assembled is for the rollout of agile practices throughout our company's enterprise.  So, I have some things that require immediate attention and some that I know we won't be considering for a few months.  What I decided was to create a backlog with several planning horizons embedded in it.  The near term horizon has stories that are well defined.  The medium range horizon (2-3 months out) has stories that are defined but are still kind of fuzzy.  And the long range horizon (3-6 months or more out) has stories that are really just headlines.  As we move ahead in time, I'll work to increase the granularity of the medium and long range stories as they get closer to implementation.  We do this on all of our agile projects.  What is does is effectively reduce the waste of spending too much upfront time defining the details of a story that may or may not ever be implemented.

The next thing I had to do was start prioritizing the stories.  Instead of spending too much time prioritizing the entire list, I actually went through the list and did a top ten list of stories.  I know that we aren't going to work through more than 10 stories in the next 4 weeks, so I think that prioritizing beyond that can be wasteful as well.  As we complete stories on the top ten list, we'll move new stories into the top ten to keep it constantly stocked. 

I think that the use of both of these ideas keeps the backlog in alignment with value production and reduce waste. 

This morning I was looking over several of our project backlogs and noticed something that really caught my attention.  In addition to user stories that addressed the functionality we are developing, our project teams have been adding stories to the backlog that have nothing to do with project tasks (or maybe they have everything to do with project tasks).  The stories are about improving processes and practices, organizational issues, team matters, and even the project structure. 

I was really happy to see this.  It proved beyond a shadow of a doubt that our project teams are becoming mature agile practitioners.  They've realized that the issues uncovered in their retrospectives are important enough to warrant being put into a backlog.  This ensures that they won't be ignored or forgotten about when the retrospective is over.  It puts the issues front and center and on par with development tasks.  And, it makes sure that we are actually going to do something about them within a time-boxed period.

So, what's in your backlog?  Is your backlog filled with only development tasks or does it include stories about improving your team and your practices?  Take a look today and consider if you need to elevate these non-development stories to a higher level.

On Thursday, February 14th, 2008 (Happy Valentine's Day!) at 11:30am EDT, Michael Mah of QSM Associates, will be hosting a special "town meeting" event featuring an interview with Kim Wheeler of Follett Software and Mike Lunt of BMC Software. 

Date: Thursday 14 February, 2008
Time: 11:30 am EST (New York Time) / 8:30 am PST / 16:30 UTC/GMT
Location: Right at your desk! Just log on from your computer.
Duration: 60 minutes
Fee: Complimentary.

To register for the event, click here.

From the QSM Associates Announcement:

Why might you care?  If you recall, both Follett and BMC were featured as "poster children" - case studies for the fastest time-to-market and lowest defects for building software applications in two recent webinars I hosted via the Cutter Consortium.  We measured this using the QSM SLIM models against industry data collected worldwide from years of research.  These two webinars were among the highest attended at Cutter, and the questions wouldn't stop coming. so we decided to add this special session and invite you to take part.  If your management is constantly pressing you to meet tight deadlines, or encouraging that work just be sent offshore, then you'll want to hear how Kim and Mike dealt with similar demands and built a world-class, industry-beating agile team.
This event will allow you to ask Kim and Mike questions that they will answer, live and unrehearsed about what's in their "secret sauce."  The format will be an interactive Q&A session around the real-world technical and people issues they addressed and how they "got Agile."  I get to start the session with a PBS-Charlie Rose style chat, and then we'll open it up to the audience.

I've created a brief 10 question survey to gauge the level of agile adoption in the GIS industry.  The survey takes no longer than 5 minutes to complete and doesn't require any corporate, personal, or confidential information.  To take the survey click here.  The survey is being hosted courtesy of SurveyMonkey.  I'll publish the results of the survey in the next month or so.

Over the course of long projects (and some short ones too), the shared understanding of the project, release, or even iteration goals can drift.  Different team members remember or interpret project aspects differently over time.  This drift can result in producing a final product that doesn't satisfy your client's expectations.  So how do we counter drift throughout the life of a project?  Some say "Write a vision statement and stick it on the wall?".  I'm not a big fan of "statements".  I think people get lost in them, and statements, over time, can be open to interpretation as well. 

Short of a unifying statement of sorts, how else can you keep your team synchronized with the goal's of the project, release or iteration?    That's where the beauty of agile practices comes in.  There are several practices which foster a cohesive, shared understanding of the goals: the iteration planning meetings, the iteration review, the retrospectives...but none more than the daily stand-up.  I think the daily stand-up helps anchor agile teams to their goals more than anything else.  On a daily basis, drift is kept in check by synchronizing the work underway.  If teams treat their daily stand-ups more as a synchronization conversation rather than a status report, I think the daily stand up can go a long way towards preventing drift from happening.

Do you have mad ASP.NET, Ajax, Javascript, and CSS skills? Are you a web development guru? If you are, this might be your workstation. Data Transfer Solutions is hiring and we need someone who can do some serious web development. We’re an agile development shop and we’re looking for a web developer that will fit well with our existing Ft. Collins, CO team. Experience with agile development practices and geographic information systems are a plus but are not a prerequisite. If you’re a web developer and you’re looking for a new place to sit, visit www.chrisspagnuolo.com and click on the Contact Chris button to submit your resume.