Earlier this month, I was privileged to speak at Rally Software Development's Customer Summit at the Agile Development Practices Conference in Orlando.  I gave a talk called Becoming Agile. It was a brief talk about our team's transition to agile.  It follows our team's agile journey from our humble beginnings to our exit from our old organization and our new home here at Data Transfer Solutions.  I've uploaded the slide deck from the presentation with notes so that you can read what was presented.  I hope you enjoy the presentation and I would really appreciate any feedback or comments as well.  You can view the presentation here or download the full PowerPoint with notes at my SlideShare site.  Or click here to download the slide deck and notes in Adobe PDF format.

 

Exactly one month ago we launched the Agilistas Group on LinkedIn.  The Agilistas Group is a collaborative community dedicated to evangelizing and advancing Agile practices in software and product development.  Today, we hit the 200 member mark for the group! 

In the next month or so we will be launching an Agilistas web site to promote open communication throughout the agile community.  Stay tuned for more info on the web site as it becomes available.  Also, if you have suggestions or ideas about what you'd like to see on the site, please let us know.  And finally, if you haven't joined Agilistas yet, head over to LinkedIn and get yourself signed up if you're interested.  Here's the direct link to the Agilistas Group sign up page.  Thanks for all the interest so far...

Here's wishing you all a very peaceful, happy, and healthy holiday season.  I want to thank all of my readers and agile friends for your loyalty and support this past year...without you, this blog would just be sending my thoughts into the big cloud.  I'd also like to thank the greatest development team I've ever worked with: Dave Bouwman, Mike Juniper, Vish, and Jeff Germain.  Without these four guys, I'd be just another software project manager.  Finally I want to thank Data Transfer Solutions for being so supportive of our development team here in Fort Collins and of agile practices in general...so thanks to Allen Ibaugh, Jason Amadori, Trey Fragala, and Randy Goss.

I'll be taking some time off during this holiday season but will be back in 2008 writing about and discussing Agile practices and GIS.  See you all next year and thanks again!!!

 

In the coming months, I'll be conducting interviews with leaders in the GIS industry discussing their level of agile adoption.  However, today I found two new polls on the Directions Magazine website which give an insight into what the GIS market is doing with agile.  The first poll examined the level of knowledge GIS professionals had in terms of agile product/software management knowledge.  The results showed that only 28% of the 36 respondents are using agile practices (and what that means can be kind of nebulous).  The astonishing figure is that 31% of the industry has never heard of agile.  This may help answer Dave Bouwman's and my questions about why the GIS industry is slow in adopting agile practices.

The results of this poll stand in sharp contrast to the level of agile adoption in the broader software development world.  According to an August 2006 survey by Version One, 84% of the 722 respondents indicated that their company had adopted Agile development practices somewhere within their software organization.  A similar survey conducted by Digital Focus last year concluded that 81% of the 136 executives they surveyed were either actively using Agile development methodologies within their organization or looking for opportunities to do so.  This makes two clear points:

1. Agile is rapidly gaining acceptance as the primary tool in today's mainstream application development world
2. GIS software development is lagging behind mainstream development when it comes to agile adoption

To hammer home this point, Mary Poppendieck gave a keynote speech about the state of agile adoption at the Agile Development Practices conference called "Welcome to the Mainstream".  Mary concluded that agile has crossed the chasm and is now part of mainstream software development.  She used Geoffrey Moore's classic product adoption diagram to illustrate where agile practices are in the general software development adoption curve.  I'd like to modify the product adoption diagram further to illustrate where I believe GIS agile adoption is today as follows:

The second poll asked a question about what type of educational course GIS professionals would choose.  The significant result here is that the second highest response was "Project Management" at 16%.  This agrees with what I have repeatedly heard at the conclusion of nearly every ESRI Users Conference I've attended in the past 10 years.  Every year, Jack Dangermond asks conference attendees what they want more of in the conference for the next year.  Without fail, someone always says "Project management" which is usually met by big applause from the audience. 

I believe that these two results taken in combination provide some great insight into two areas of the GIS industry that need real help: Agile adoption and project management.  What I really think is that the GIS world is ready to begin it's journey down the path toward accepting agile project management practices to start producing valuable, quality software for our end users.

To meet that need in the GIS market place Data Transfer Solutions is going to begin offering agile project management and software development training and coaching in 2008.  With the breadth of knowledge we have accumulated through our own agile adoption, we'd like to work to help bring the rest of the GIS into the mainstream fold of agile project management and software development.  If you're interested in training or assistance in getting your agile adoption underway, please feel free to contact either myself or Dave Bouwman. 

If you missed Michael Mah of QSM at the Agile Development Practices Conference this month, he is doing an encore webinar of his very informative case study of the productivity of 5 agile companies.  If you haven't seen this before, you need to see it.  It overwhelmingly makes the case for agile practices over waterfall methods with real world metrics.  Not only that, but Michael reveals the latest productivity and quality patterns from their research on Agile practices.

Details:

Case Study: Agile Productivity at 5 Companies by Michael Mah

January 17, 2008 at 11:30 am EST

Register at the Cutter Consortium website

Our friends and fellow bloggers over at Project Management View have a series of agile project management and development podcasts coming up in the New Year.  Check out their website for full details.  Here's a quick rundown of the schedule so far:

January 16, 12:00pm EST: Beyond Agile: How to Deliver Better Software, Faster with Matt Nolker

January 23, 12:00pm EST: How Good is Good? Quality Levels and the Cost of Perfection with Peter Hodgkins

February 6, 12:00pm EST: Scrum 101, with Sinan Si Alhir

April 16, 12:00pm EST: User Stories 101, with Sinan Si Alhir

They also have a series of podcasts available of past webinars that include:

How Product Management Must Change to Enable the Agile Enterprise with Catherine Connor

Integrating the Agile Development Process With the Pragmatic Marketing Framework with Jason Tanner

Agile: Friend or Foe to Product Management with Renée Thompson

Product Management: How to Increase Business Value by Transitioning to Agile with Levent Gurses

Agile Product Marketing & Management for Enterprise Software Start-ups with Aditya Bhelande

Lean, Agile, and Competitive Product Management with Sinan Si Alhir

The Basics of Agile for Product Managers with Laureen Knudsen

Agile Methodologies: How Product Management's role is shifting with Laureen Knudsen at HP

I recently had the opportunity to hear Esther Derby speak about organizational cultures at the Agile Development Practices Conference in Orlando.  One of her discussion points was about creating agile micro-cultures within an organization that may not be willing or able to accept agile practices on the whole.  Fortunately, our new organization, Data Transfer Solutions, is very much in favor of making a commitment to establishing a corporate culture that will support agile practices.  However, our team did have some experience creating our own agile micro-culture at our former organization.  Our organization seemed unable to make the cultural changes to really support agile practices.  In light of that fact, we took the initiative to create our own little culture of agility. 

We didn't know it at the time, but we were following Esther's recipe for creating a micro-culture.  Essentially, we examined how we were working, how our organizational patterns, systems, and structures enforced the way we were working, and what our beliefs and values were.  Then we discussed how we wanted to work and what we needed to change to get there.  We decided that, in general, we were acting in ways that were definitely counter to what our entire team believed and valued, which is one of Esther's indicators that you may need to change the way you are working.  We also decided that our organizational patterns and behaviors weren't working for us as a team.  So we began to create a micro-culture within our satellite office. 

We may have had an easier time creating this micro-culture because we were an isolated development group.  By isolated, I mean both geographically from our corporate headquarters, as well as on projects.  We shared no project work with other development groups within our company.  We were essentially free to operate under the corporate radar.  However, over time, our new micro-culture popped up on the corporate radar and we were asked to speak about agile practices with the rest of our organization.  Although it seemed that there was interest amongst the developers, the organization seemed (at least to us) very unlikely to change it's corporate culture to be truly supportive of agile practices. 

If you are a regular reader of my blog, you already know that our team decided not to fight the uphill battle of changing our organization and left for greener pastures.  However, if you are in an organization that seems even slightly receptive to change, you can work to make a difference in your organization.  Esther believes that small teams often have much more control than they think they do.  However, to be most effective, she recommends that teams understand what she calls "The Soup"...the stuff you can't influence.  Once a team has that basic understanding, they can focus on the things that they can influence. 

So if you're starting on your own agile journey and it hasn't received the corporate blessing, look around you and understand how your organization works.  Try to find ways to build your own agile micro-culture.  Then find ways to help your organization help you move agile practices into your corporate mainstream.  It may be that you need to take baby steps at first...little "agile experiments" that can help you show the successes and benefits of agile practices.  Take it slow, be patient, and do what Esther Derby says..."fan those tiny flames of agile hope you find in your organization and help then grow into agile bonfires."

I don't often give shout outs to software products, etc., but a few people asked about the photo collage on my recent post about the Agile Development Practices Conference. I made the collage using a cool application called Ript (free download available).  It was developed by an agile development team at Oxygen Media (some of whom we met at the conference).  The Ript dev team even has a blog with thoughts from the team.  It's an awesome little application and I plan on using it plenty in the future.  Here's a sample of what Ript can do.

I was giving some thought to how to close out agile projects today and realized that because agile projects are managed in an iterative manner, closing a project should be a simple affair with no surprises. During the lifespan of the project, agile teams should be conducting product review sessions at the end of every two week iteration with their product owners. At the review sessions, the development team should present the functionality they developed in the previous iteration. During the review the product owner and other stakeholders should have the ability to comment on the functionality developed. These reviews allow the product owner to provide iterative acceptance of developed functionality.

Agile teams should also base their work on regularly scheduled releases. These releases should be a culmination of a series of functions and features developed over the course of several iterations. These product releases will be full releases of useable, valuable features to the product owner and their organization. A release review similar to the iteration review described above can be conducted to review release functionality. The product owner will have the ability to accept the functionality within a specified time period after the release date. This provides a second level of acceptance for the product owner.

The final release of the product should follow the same pattern as the release cycle described above. In this way, the final release should really have no other fanfare than any other iteration or release (except for your team’s joy at being done with a product). Because your team has been releasing and gaining client acceptance on a bi-weekly basis, there should be no surprises in this final release. Final client acceptance should just be a formalization of the collective acceptance that has been built up over the life of the project.

There is currently a debate raging in the geospatial industry about whether or not neography is "real" GIS.  For those of you not in the industry, Wikipedia defines neogeography "as a set of techniques and tools that fall outside the realm of traditional GIS, Geographic Information Systems. Where historically a professional cartographer might use ArcGIS, talk of Mercator versus Mollweide projections, and resolve land area disputes, a neogeographer uses a mapping API like Google Maps, talks about GPX versus KML, and geotags his photos to make a map of his summer vacation. Essentially, Neogeography is about people using and creating their own maps, on their own terms and by combining elements of an existing toolset."

I refuse to be drawn into the debate about neography versus real GIS because it is a non-issue.  Technology is taking us to lots of new places and I think broadening our horizons and sharing GIS with "the rest of the world" is a great thing.  Those who want to draw divisions about whether or not something is "real" GIS are falling into what I call the High Priest Syndrome.  They want to use semantics, strict definitions, and a dogmatic view of their area of expertise to separate themselves from the "commoners".  I find this highly divisive and extremely counter productive.  Sharing and expanding horizons with newcomers to our field often brings exciting insight and fresh ideas to sometimes stagnant viewpoints about what's possible.  (OK, so maybe I finally gave an opinion on this matter and have indeed been drawn into the argument...but that's the end of that!).

I think we see this in the agile world as well.  I believe that many individuals get so hung up on using the "correct" terminology for certain agile practices (especially in Scrum) that they alienate newcomers to the agile world.  There are many people who believe that you have to keep to a strict adherence of Scrum definitions to be "doing Scrum": if you're not doing everything Scrum says to do, you're not doing Scrum.  I think this too falls under the High Priest Syndrome category. 

The beauty of agile practices like Scrum is their flexibility...you know...inspect and adapt.  We need to constantly inspect and adapt our practices to make our team as efficient and effective as possible.  I say this with one caveat: Don't inspect and adapt back to waterfall, or as Jean Tabaka calls it "Reverting to form". 

I was very glad to hear many of the speakers at the recent Agile Development Practices Conference last week echo this sentiment.  From Mary Poppendieck, Esther Derby, James Coplien and especially Andy Hunt, the message was clear: "Don't be dogmatic about your agile practices".  Andy said it very bluntly in his closing keynote and Mary said it in her opening keynote.  Mary really hammered it home by saying "Stop following best practices!  Create your own best practices and become a leader".

So, before I ramble and rant too much more on this topic, let me say this: The next time you see blog posts or articles that draw you into counter productive arguments about whether or not you are agile, or whether or not you are doing Scrum, do what Dave Bouwman has recommended...IGNORE THEM.  Use your own judgement...you know what's best for your team.  My best advice is to inspect and adapt frequently...to the situation at hand.  And remember, what worked for you last time may not work in the future, so don't rely on what may become your own agile dogma.

While Dave Bouwman and I were attending the Agile Development Practices conference last week, we were interviewed by Richard Sharpe at Enerjy.  Richard interviewed several leaders in the agile world including Alan Shalloway, J.B. Rainsberger, Jean Tabaka, Rob Myers, Jared Richardson, Tom and Mary Poppendeick, James Shore, Rachel Weston, Ken Pugh, Dave Bouwman and myself.  Richard has put together a collection of our answers on his website for viewing.  Each week, he'll be releasing answers to another question.  Here's the first set of answers to the question "What Part of the Agile Process do you think gives the developer the greatest benefit?"

Numerous people have e-mailed me asking if the proceedings from the Agile Development Practices Conference are available anywhere online.  The short answer, they're not if you didn't attend the conference.  However, several podcasts were recorded during the conference with some of the biggest names in agile today.  These podcasts are available to the public at http://www.sqe.com/agiledevpractices/Podcast/Default.aspx.  They include conversations with such agile experts as: Mike Cohn, Andy Hunt, Jutta Eckstein, Mary Poppendieck, and Lee Copeland.  Aside from the conference, a series of other excellent agile/development podcasts are available from the folks who put on the agile conference at StickyMinds.

Last week still seems like a dream to me.  It started off with two days of project kickoff meetings with a new client who is completely interested in doing their project in an agile manner.  Next, I spent two days in Orlando, Florida at the Agile Development Practices Conference.  Not only did I get to interact with the major thought leaders in the agile community, but our team's agile adoption and our switch to a new organization was completely validated by the things we heard at this conference.  By Thursday night, I didn't think the week could get much better.  But it did...

Our new company is based out of Orlando, so we paid a visit and sat in on an offsite management meeting.  It was an offsite, but like none I had been to before.  Everyone was very focussed but relaxed at the same time.  The information presented was relevant and inspiring.  You could feel the team spirit in the air.  Fortunately, I was given a slot on the agenda to deliver a brief presentation about agile practices and corporate cultures that support agile adoption.  The "brief" presentation ended up lasting almost 1 1/2 hours because of the high interest level and numerous questions and discussions the presentation elicited.  The entire management team just instinctively got it.  They immediately grasped the significance of agile practices beyond just software development and want to implement company wide agile practices.  They are so committed to the agile concept that they are considering changing the company tagline to DTS: Agile Solutions.  How cool is that?

To be completely honest, our entire team went through quite a stressful period over the past two months as we were leaving our old company.  It was a long haul, and we had to keep our spirits up and looking toward the future with our new organization. But last week made it all seem trivial.  Although it seemed like I was dreaming in agile for the past five days, I think I'll wake up Monday morning to find that we really are in a new home that truly wants us all  to succeed ...and to do it with agility.

I've just finished up attending the first Agile Development Practices Conference at the beautiful Shingle Creek Resort in Orlando, FL.  All I can say is this: If you're doing agile and didn't attend, you really need to consider attending next year.  This was hands down one of the best and most informative conferences I've attended.  Aside from the great location in sunny central Florida, this conference featured some of today's greatest thought leaders in the agile world.  There is way too much to fill you in on in a single blog post, so over the next few weeks, I'll pour through the myriad pages of notes I took and try to convey some of the great ideas that I was fortunate enough to hear this week.  But, just to give you a taste of what's coming down the line, here's a run-down of the conference highlights:

• Mary Poppendieck of Poppendieck, LLC started off the conference with a killer keynote presentation called Welcome to the Mainstream.  Yes...agile has gone mainstream, and Mary gave us a rundown of how to fail with agile...of course with  counterpoints on how to succeed.
• Esther Derby of Esther Derby Associates had a great session entitled Toward a More Agile Culture.  It was a great focused discussion about different types of organizational cultures and what is required culturally to support successful agile adoptions.
• Andy Hunt of The Pragmatic Programmers and one of the original 17 signatories to the Agile Manifesto gave a thought provoking talk about using the right side of your brain to solve your toughest problems in his session entitled Refactoring Your Wetware: Thinking Differently About Thinking.  Andy also gave a very inspiring closing keynote speech about Looking Toward the Future of Agile.
• Michael Mah of QSM Associates presented an incredible case study about Benchmarking Agile Productivity.  Michael presented an amazing set of metrics from over 7,000 traditional software projects and compared the performance of agile projects to them.  You'll be very happy to see some of the results of this case study.
• James Coplien of Nordija and the father of organizational patterns, gave perhaps the best talk of the conference on Organizational Patterns: Foundations of Agile.  Cope clearly laid out the top ten patterns of the most successful software development organizations and the values these are based upon.  If you want to truly become a extraordinary and hyper-productive agile development team, you'll definitely want to read about the patterns you need to base your practices on.
• In addition to these amazing speakers, I was fortunate enough to present a short talk about Becoming Agile at the Rally Software Development Customer Summit.  The talk centered around our team's agile adoption to date.  I'll be putting the PowerPoint online for download here in the next few days. 
• I also coordinated an Open Space session with Rachel Weston of Rally Software about Agile Contracting.  The session featured myself, Rachel, Dave Bouwman, Andy Brandt of CodeSprinters, and Zvonimir Durcevic of i-new.
• Finally, Richard Sharpe of Enerjy Software, will be posting a series of video podcast interviews from the conference over the next few weeks.  Interviewees will include folks like Jean Tabaka, Mary and Tom Poppindieck, Dave Bouwman, myself, and several others.  As Richard posts the videos, I'll provide links to them for you.

So those are the highlights.  Stay tuned for more details and commentary in the coming weeks.  And make your plans now to attend the conference next November!!!

 

Today, I spent the afternoon with a client from a large state agency here in Denver. We were onsite for a project kickoff meeting. At the meeting, we discussed several pertinent issues about the project, including our use of agile practices to manage the project. The client and our new employer are very open to our use of agile practices. However, the question arose about how to handle changing requirements over the course of the project. Now, I should state up front that this is a fixed-price contract. Essentially, we all agreed that for most changes, we would work within the bounds of Scrum and use a prioritized backlog to move items in and out of scope. However, for large scale changes to the requirements, we would probably need to use more formal channels like change orders. We discussed this for a bit, and everyone felt comfortable with this decision in the end.

However, on the drive home to Ft. Collins, Dave Bouwman and I had a discussion about change management in the hybrid world of fixed-price agile contracting. The main point was about contract negotiation over the lifespan of an agile project. Now, I know…one of the tenets of the Agile Manifesto is that we value client communication over contract negotiation.  While this may be true, there is also an element of reality that requires us as consulting-ware developers to have to deal with contract negotiations in the fixed-price world.

In the consulting world, we are frequently bound by contracts that, at some level, define the requirements we need to deliver.  As we proceed through a project using agile practices, we frequently rearrange the priorities of these requirements (or user stories).  In addition to rearranging the priority of user stories, we often find it necessary during a project’s lifespan to remove some stories from the backlog and add others.  Whether we like it or not…whether we consider it agile or something else, these changes to the product/project backlog may require change orders. Most of the time, this is not really ideal for either the consultant or the client. We’d rather just embrace the change, and move on to continue developing valuable software.

However, at most government agencies and even some private companies, there is a contracting officer, whose job it is to check the “boxes” to confirm that you delivered functionality X, Y, and Z at the end of the project. If we make a noticeable change to the requirements (especially removing one), we may need to change those “boxes” so we don’t get dinged for non-performance. Not quite agile…but a very realistic and common scenario.

So, back to the manifesto…client communication over contract negotiation, right? Well, I’m not sure that these two need to be mutually exclusive (and I don’t believe that the manifesto implies this either). I believe that they are both very relevant in the consulting-ware world. I think that if you establish an open, collaborative relationship with your client that thrives on honest communication, then contract negotiation (especially change management) can be relatively painless. If your client truly understands the agile process and feels well informed and confident about scope changes, they can become a champion for these changes with their contracting agent. They will be able to communicate in clear terms why the changes need to be affected and how these changes provide increased value and quality to their end-product. This could create an easier path to official change orders for you and your client.

I also believe that over time, your client may come to really appreciate the success of agile practices and possibly “sell” their contracting office on the virtues of fully agile contracts. If you and your team work to consistently deliver value and quality using agile practices, maybe you can start to help organizations change the way the way they view software development contracts in the future. Nothing sells better than success!