The folks over at ThoughtWorks are doing a webinar entitled Making Distributed Software Development Work next Tuesday, April 8, 2008.  From ThoughtWorks:

Join ThoughtWorks' Matthew Simons and Forrester's Carey Schwaber, as they discuss how to ensure successful software delivery when working with distributed teams.

Do you face any of these challenges in your distributed development project?
    • Disconnection on project requirements or estimation
    • Decreased visibility into project status
    • Erosion of trust among individuals in the project
If you do, you are not alone. Let’s face it; global collaboration is hard. Because software development is, at its core, based on communication. Every aspect of a project is fundamentally changed the moment that team members lose the ability to communicate face to face. As a result, it’s far too easy for a distributed software project to be unsuccessful.
And yet, the allure of distributed projects is very powerful: cost savings, 24/7 availability of development, access to talent and more. No wonder then, that Project Managers are expected to deliver results with Global teams.

Details

Date: April 8, 2008

Time: 10:00 A.M. PDT/1:00 EST

Register for the webinar here.

As part of my continuing interview series with thought leaders in the agile industry, here is an interview with Ryan Martens, CTO of Rally Software Development.  Ryan is a devout member of the software industry since the early 1980’s. In the mid-90’s, Ryan moved into consulting and re-engineering using Internet technologies with two different companies and numerous clients. His last start-up was acquired by BEA Systems where Ryan directed product management for BEA’s Portal. Since 2002, Ryan has focused his efforts on changing the software industry through Rally Software. Every day, Ryan drives Rally toward becoming a sustainable business, while working to help customers realize the benefits of software agility. Ryan is a board member on the Agile Alliance, Colorado Conservation Trust, Entrepreneurs’ Foundation of Colorado and the Knight Foundation, as well as being a husband, father and farmer in Boulder, Colorado. 

Aside from all of this goodness, Ryan is just a flat out great guy, a good friend, and very approachable.  Our team works closely with him and his folks at Rally to bring agile practices to the forefront of our company's development activities.  I'd like to offer my thanks to Ryan for all the help he's given us and for taking the time out of his busy schedule to share his insights about agile software development.

Q. You have had the opportunity to work with many software development teams in your career.  Is there something special that seems to define or set apart high-performance agile teams?

A. Cool tools/technologies, cool customers, trust and collaboration have made for fun, high performing teams in my career at 9 software companies and two consulting firms. Being successful enough to be able to continue to play the fun game was the reward. With regards to the special things that set apart high-performance teams, I do not claim to be the expert. Like most, I knew it when I was in it. But thanks to an Agile University instructor and friend, Christopher Avery, we have the research to really put our finger on answers to that question. His research (see great-teams.com) points to three top things that I would totally concur with:

• Trust
• Goodwill/Collaboration
• Clarity in Purpose

Q. The flip side of that coin is equally important.  What would say are the common pitfalls that cause agile teams to fail or be ineffective?

A. I assume you can plot teams on a normal distribution curve, and the great ones and the ones that fail make up the tip and tail of the curve. The ones that fail violate the things that make a great team. Another friend Luke Hohmann, Enthiosys.com, describes the anti-pattern as a “J-O-B.” Whenever it just feels like work, stuff-for-money, or you’re working with people who are painful, it becomes a J-O-B. When it becomes a JOB, you lose the determination to inspect and adapt agile, and you plateau as an agile amateur and ultimately fall back and typically apart.

Q. There are many agile tools in the market place today.  What are your thoughts on the necessity and value of tooling for agile teams?

A. All teams need agile tools, techniques and methods to reinforce the structure and discipline of agile. In the talk that Ron Jefferies and I gave at Agile 2007, we talked about three types of “tools.” There are tools that help you reduce the cost of iterating, tools that help increase your visibility within and across teams, and role-specific tools that help accomplish specific tasks. Of course, there is a continuum of low to high tech in all of these categories.

• Tools that help you reduce the cost of iterating a check-in, a story, or an entire increment include testing tools, mock-up tools, development frameworks, refactoring IDE’s, and testing frameworks that help you reduce your batch sizes. As your batch sizes of running tested features decrease, your agility level increases.
• Tools that help you increase your visibility across the lifecycle like task boards, agile project management and integrated build tools increase in value as the project grows larger. These tools build collaboration, measurement, discipline and trust to make performance more objective.
• Role-specific tools like backlog prioritization, specific types of test tools, and modeling tools help make steps in the agile process more effective. The need for these is varied based on the people in those roles and the technology in use of the project.

You have to think of the tools, techniques and methods as working to support building trust, collaboration and clarity in purpose as well agility.

Q. Your company actively promotes agile practices for software development.  How has Rally adopted agile practices and what value have you recognized from it?

A. As we have grown, we have matured our agile practices and disciplines to manage the growth in development, the business and our customer base. We followed an incremental adoption approach to agile, and the value we’ve recognized has steadily increased. Here are the rough descriptions of the transitions that our team went through.

Step 1 Started Out Iterating – Pull together a new team of 8 into a state of iteration “flow.” We set a two week iteration cycle and worked to stabilize the process so that we could deliver a consistent level of iteration acceptance. We used internal demos to steer our iterations and we gained increasing alignment, component-level quality and company-level visibility. However, we had little feedback that we were building something that was “really” valuable and our testing practices were not good enough to achieve 100% iteration acceptance.

Step 2 Increased our Agility to “Pull” – This came after we had a handful of customers and we moved the single team into a “pull” state. This included roadmap planning based on feedback, release planning to steer iterations and better acceptance testing tools and techniques. We used customer feedback to help prioritize and shape our backlog and better automation to reduce the size of defect pile we had to clean-up before release. We worked hard at this state to get to a zero-defect mentality both inside the iteration and with regards to overall technical debt. As a result, we achieved a consistent level of 90% iteration and 100% release acceptance levels.

Step 3 Scaled to Multiple Scrum Teams - We split the 20 person team that was working in a state of “pull” into multiple scrum teams to make meetings and communication more effective. We instituted scrum-of-scrum and product council meetings and built out the integrated build management system. We also instituted a stop-the-line philosophy with regard to broken builds. Set a goal of 90% successful fully integrated builds. We gained velocity in the individual teams, but struggled with the new hierarchy to steer a multi-team program. We broadened our product portfolio to include two products.

Step 4 Extended Agility Outside the Dev Team – We extended agility out to support and closed the loop with regard to feedback and defect management. By using our Agility Suite to link Salesforce.com and Rally, we tracked the lifecycle and cycle time of customer request. As a result, we gained customer intimacy and trust through increased communication and visibility into our backlog.

Step 5 Vision and Roadmapping – We then extended agility up to synchronize vision and roadmap across the company. Increased our discipline in business planning to help guide and synchronize our product vision and roadmap planning efforts. Also baked hack-a-thons into our regular release calendar on the last week of every release. We gained better alignment across the company and better day-to-day decision making across a distributed company of 75+ employees.

Step 6 Pull System Testing Forward into the Nightly Build - Working to move performance and security suites into the nightly process for all product editions and deployment options. Refactoring acceptance test regression suites to run in parallel and reduce run time by a factor of 10. Increasing the quality of the system and reducing cost of iterating with a faster regression suite.

Q. How does Rally gather and prioritize user stories or requirements from their large user community?

A. We prioritize at multiple levels and with multiple tools:

Daily tasks based on stand-up and any issues in production

• Iteration stories, every 2 weeks, based on iteration rank of ready items from the current release and any patch releases
• Release epics, every 8 weeks, based on value rank from roadmap, critical deals, market pressures, feature request voting by customers, hack-a-thon efforts and technical debt
• Product roadmap themes, every 6 months, based on strategic rank from market rhythms, market threats, market opportunities and the stage of each individual product in its lifecycle
• Product line resource allocation, every 6 months, based on vision, profit and loss, core purpose and business SWOT across the portfolio

Q. In terms of the scalability of Scrum and agile, what major differences have you observed between small-team scrum implementations and large distributed multi-team Scrum implementations?

A. The major difference between small teams and large distributed teams is the forced level of discipline. Many small teams can implement agile somewhat. With limited complexities, these teams can run with less discipline and fewer skilled “craftsmen” and still regularly ship quality software.

Large teams must increase their agile disciplines to manage the scale and distribution complexities or risk falling back to old ways. As a result, the level of tooling to manage cross-team communication, dependencies and signaling teams is a big difference.

Q. For organizations that are just starting out on their agile journey, what advice can you give in terms of cultural shifts they may need to make to support their agile teams?

A. Your blog post from mid-January said it best - take baby steps, celebrate the success and don’t bank all your savings from agile successes. Make sure to reinvest parts of your savings back into a continuous quest to learn and get better. This is a game of regular and continuous improvement.

Internally, we’ve seen great success by adopting agile practices using agile techniques (incremental, iterative, fully inclusive, guided by inspection and adaptation). Don’t try to bite off too much too fast.

Q. Your organization actively engages in and promotes Green IT practices.  Can you briefly discuss simple things every IT organization can do to green their business?

A. I think greening is just like adopting agile. We need to get our linear business process to become more feedback driven and sustainable. In this regard, the simplest things are not necessarily the right things. To green, you must get on a curve of incremental adoption. The right thing to do is to get folks from around the company to volunteer, set regular meetings, charter the group, baseline your issues and start picking off the visible, impactful and easy items. You need to build success and demonstrate value. It is really easy to “greenwash,” just like it is easy to “agilewash.”

Some easy things all of us can do:

• CF bulbs
• Motion lights
• HVAC timers
• PC power management software
• Building upgrades with the help of owner and city zoning
• Purchase Renewable Energy Credits for your server farm or travel
• Flex hours to support car pooling
• Work at home solutions

Q. How do you see agile practices contributing to the greening effort?

A. As I stated above, adopting agile and greening are both incremental improvement journeys, so teams that are on the expert curve to agility are in a good place to be successful in greening. The driving principles behind agile are the Lean principles of:

• Eliminate waste
• Empower teams
• Amplify learning
• Build integrity in
• See the whole
• Deliver fast
• Delay decisions

These are the same driving principles necessary to really create a sustainable company or industry. Fundamentally, I believe we have two perceptions wrong in the high-technology world.

1. We have product mentality that drives us to follow a linear product lifecycle of taking materials, making products, transferring ownership and having customers discard them as waste. By moving software to a service model driven by agile, we can shift the power to software service providers and begin to change the entire high-technology industry to a more sustainable service model.
2. We believe building software is a deterministic process and should be managed with traditional critical path methods of project management.

I have submitted this as a topic to Agile 2008. If you want to hear it, please jump in and add a comment here - http://submissions.agile2008.org/node/2100.

Q. In general terms, what do you think the future holds for agile software development?

A. Huge growth! This approach to software development is critical in a world with:

• Higher customer expectations for immediate action and quality
• Embedded computing everywhere
• The computer as collaboration environment
• Sustainable businesses networks
• More employees in software/IT because it is a sustainable and globally distributed market

A look beyond agile at the program level and into business agility and reliable innovation

• Closer connection to “the customer” through Web 2.0 communities
• Better tools to get the cost of iterating and current set-based development down
• Extended into other knowledge work areas

Well, after a rough start getting to the ESRI Dev Summit, the rest of the week was fantastic.  I had a great time meeting up with old friends and making lots of new ones too.  Thanks to the hard working folks at ESRI, the Dev Summit was a great success again this year.  If you're a GIS developer, skip the User Conference in the summer and make sure you head to the Dev Summit next year!  Tons of other people have already given their wrap-up for this year's Summit so I'll point you to some of the good one's and just provide you with some pictures from the Summit.  Cheers to ESRI and everyone involved in making this a great event!  See you all next year!

Summit Wrap Ups:

Dave Bouwman's 2008 ESRI Developer Summit Wrap Up

All Points Blog Dev Summit Podcast

Jithen Singh's Wrapping Up the ESRI Developer Summit 2008

James Fee's Reflection on the 2008 ESRI Developer Summit

Albert Pascual's 2008 ESRI Developer Summit

The (official) ESRI Developer's Summit Blog

Bryan Noyle's Agile Conversations at the Dev Summit

Donny V's 2008 ESRI Developer Summit

Clearly Vague's Day by Day Account of the Dev Summit

And here are a few pix from the Summit:

Whenever I describe agile practices to people for the first time, the response is usually something along the lines of "Seems like common sense to me."  I agree completely.  I think that the more people approach agile with the common sense approach and avoid the dogmatic side of any methodology adoption, the better off they'll be.  I recently found this quote from Buddha that really speaks to both the common sense theme of agile practices and the anti-dogmatic view of methodologies that we have been promoting at DTS Agile:

Believe nothing, no matter where you read it
or who has said it,
not even if I have said it,
unless it agrees with your own reason
and your own common sense.

This week, we had the opportunity to talk with lots of people at the ESRI Developers Summit about agile practices.  One of the popular questions we've been fielding has been about contracting in an agile environment.  At the risk of double posting the topic, check out Brian Noyle's recent post about some of the conversations we've been having.

Yesterday's keynote speaker at the ESRI Developers Summit was Alan Cooper.  Cooper is the author of The Inmates are Running the Asylum and About Face.  His talk was entitled Post Industrial Management.  Mainly, he discussed how to get non-technical people to have success and achieve their goals with software products.   He did make some very interesting and valid points regarding the management and executive view of software development.  In particular, he emphasized that organizational structure and technologies that worked in the past are failing today in the post-industrial bit-centric world.  I completely agree on this point.  Most of what passes for management today is based on industrial management, but the industrial age is over.  We need a new wave of executives to find the right organizational cultures and management tactics to support the new post-industrial knowledge workers.

He also hit on one of the topics that I really think is an issue in software management today and that is the difference between effectiveness and efficiency in software development.  I have written about this before and feel very passionate about it, and it's worth mentioning again.  Cooper provided a quote from Peter Drucker that I think really summarizes this argument very well:

Effectiveness is more important that efficiency.  Business can decline and even fail at the same time that process reform is dramatically improving efficiency by saving money for the company.

I would agree and would argue along with Cooper that ignoring effectiveness to focus on cost reduction is a primary cause of software construction failures.

Cooper also made some great analogies to describe the way software is developed.  He doesn't see software development as an industrial activity.  He believes it's more like a pre-industrial craft in that things are made one at a time, they're not formulaic, and they are complicated and nuanced.  But, he also see's it as a post-industrial craft with more pieces, built by disparate teams, with abstracted notions and massive interaction between the parts.  He described the post-industrial craft of software development as existing in a brittle environment with invisible or intangible products, and working in a world of rapidly evolving tools.  I agree with most of that, except I'd like to believe that the products we produce aren't invisible to our end users.

I really liked the points discussed above.  However, I found the remainder of his talk to be a little off-base and very biased to a waterfall or modified waterfall approach to software development.  In addition to promoting a waterfall approach, he made several misstatements about how agile teams work and plan.  His first comment was about planning.  He advocated that to successfully manage software projects, you must have detailed written plans.  He also claimed that contrary to engineers' claims, requirements don't change.  He went on to slam agile practices by saying that agile practitioners say that "We shouldn't plan because things change so rapidly".  Anyone who has managed a software project using agile practices knows this is a huge waterfallacy (a fallacy about agile spread around by waterfall advocates).  Agile teams do plan at many different levels.  In fact, studies show that over the life of a project, agile teams do more planning that traditional development teams...they just do it iteratively.

Where Cooper really began to diverge from an agile approach to software development was in his description of what he called The Software Construction Blueprint.  Here are the required elements of Cooper's "blueprint":

1. A narrative description of user personas and scenarios
2. A behavioral overview in narrative form
3. Detailed form and behavior specifications document
4. Detailed code examples showing how software will work
5. Detailed schedule and test plan

According to Cooper, by definition, blueprints are buildable and biddable.  If you build the blueprint described above, Cooper wholeheartedly believes that you can give a fixed price bid that you are confident in.  Now, I don't know about you, but I've worked on many projects that produced blueprints or whatever you want to call it, but it was heavy up-front requirements analyses.  They were not successful!  On top of that, our customers are not paying us for all of these narratives and specifications...they're paying us for working software.  Now, according to Cooper, an interaction designer builds this entire blueprint and distills everything anyone needs to know about building the software and hands off the design to a production team that actually builds the software.  Because the interaction designer does his job and divine's every requirement exactly, there should be no questions or problems negotiating the software development minefield on the part of the production team. 

I have several issues with this line of thinking.  First and foremost, I believe this sets up serious silos within the development organization.  It says that the production team has no input on design and design has no real input on production beyond initial design.  I really believe that teams shouldn't have different titles and divided responsibilities.  The team is the team, period. Break down these silos and strive for more cross-functional teams.  It builds a better understanding of the various project roles and makes for more effective teams. 

A side issue I have to throw out there is the fact that Cooper is an interaction designer and really came across as selling his services in the keynote (something I found rather distasteful).  Afterward, someone asked Cooper if he or his organization ever builds what they've designed.  He answered "No, we don't".  I won't elaborate here, but I'm pretty sure you're thinking what I'm thinking.

The bigger issue with his line of thinking is that all requirements can be defined up front and that they don't change over time.  We've all worked software projects before and we all know this isn't true.  Customers essentially have some idea of what they want, but as the software is developed and demonstrated, they begin to understand what they really want.  In agile, we can address those new ideas or changes without any worry that our big upfront design and planning would have been wasted.  But, after asking Mr. Cooper about customer involvement in the production phase of his development model, I completely understood why he believes that requirements don't change.  My question was simple, "Where in the production process do you share completed functionality with the customer and how do you manage the change that is inherent when a client begins looking at what has been developed?"  Aside from the relative hostility with which he answered this question, it was evident that in his model, there is no communication or collaboration with the customer in the production phase.  Apparently, it is possible for an interaction designer to not only define every last requirement up front, but they also have the innate capability to anticipate every change the client would make and addresses them in the blueprint.  I guess it would stand to reason that if you ignore your customers and not allow their voice to be heard in the production phase, you'd think requirements don't change too!

What really perturbed me was that Cooper said he doesn't believe that the customer even knows what they want, and that the interaction designer knows better than anyone what they need.  I take real umbrage with this assertion.  Essentially, his opinion was ignore your customers, you know what they need.  This to me is a real problem in the software industry.  This kind of thinking is exactly what leads to the 65% of features in most software that are rarely or never used (Check out the Standish Group's CHAOS Report).  Having someone of Cooper's stature stand up and advocate this is not going to do anything good for the software development industry.  And, considering the already low rate of agile adoption in the GIS development world, the last thing that we needed to hear in a keynote session were these toxic, old-school notions of software development.  I've been searching for a term to describe this way of thinking and thanks to the keynote speech at the Dev Summit this week, I think I have one now...The Cooper Syndrome.  Maybe at next year's Dev Summit, Dave Bouwman, myself, or someone else can give the agile counterpoint to the Cooper Syndrome.

If you want some more insight on the keynote, check out Brian Certain's blog post on the keynote.

I was reading some of Seth Godin's blog today and came across the following quote from him:

"Persistence isn't using the same tactics over and over. That's just annoying. Persistence is having the same goal over and over."

Sounds very agile to me.  If you have never read Seth's blog, it's an awesome read.  Check it out.

I always knew Dave was an awesome developer, mostly because he sits 3 feet away from me every day and I get to see him do some amazing things.  But today, he got some industry recognition by winning second prize in the ESRI Code Challenge with his cool AGS 9.2 Tile Server.  So congrats to Dave...if you see him at the Dev Summit, give him a pat on the back and ask him to buy you a beer...he can afford it this week!!!

I was speaking with an old colleague that works for ESRI (who, for the purposes of this post wanted to remain anonymous).  We got around to discussing what the results of the Agile GIS Survey meant and of the course the main question was "Why is GIS slow to adopt agile?".  He said he couldn't speak for the industry as a whole but he could tell me why ESRI has been a little slow to adopt it.  He related ESRI's adoption to the way Burger King selects sites for their restaurants. 

You see, McDonald's spends a ton of money, time and research on finding the best location for their restaurants.  Once they make a decision, they quickly build out the location and get down to the business of selling...well, I guess you'd call them hamburgers.  Burger King waits to see how the new McDonald's location does.  If it does well, Burger King sets up a location in very close proximity to the successful McDonald's.  Burger may get to the market a little later, but they get there (this strategy hasn't been so successful for Burger King, in fact, they've lost market share in the past few years and have fallen to the #3 burger chain after Micky D's and Wendy's).

So, according to my "ESRI friend", ESRI is a lot like Burger King and the mainstream development community is McDonald's.  He see's ESRI as very conservative in terms of adopting new technologies and methodologies unless they're well proven.  Wait until other folks figure out what works and then head in that direction.  Now, there's nothing wrong with this approach.  A lot of organizations do this, but don't count on getting out ahead of anyone this way.  In my humble opinion, I think it would be better if ESRI, or any other organization decides to lead.  Find your own location.  Don't wait for others to show you the way...it might not be the right path for you.

In light of this, I'd have to say that it was a welcome breath of fresh air to hear an indication at the Developers Summit that ESRI has been adopting some agile practices.  Hopefully for ESRI, there's no Wendy's sneaking up behind them!

Well, I actually made it to Palm Springs and to the ESRI Developers Summit.  If you're ever in Palm Springs, I have two words for you: Hotel Zoso.  The hotel rocks and it's right in the heart of downtown Palm Springs.  Stay there if you ever have the chance. 

The Dev Summit is packed this year with over 1300 developers from 690 organizations and 49 countries.  It's getting bigger every year and it's great to be here!  This morning, I sat through the Plenary Session and heard an awful lot of ESRI Kool-Aid being poured out (see Dave's post for the gory details).  Seriously, lot's of cool stuff looks like it's coming our way in 9.3 . 

Of course, my ears were listening closely for any hints of an ESRI shift towards agile practices.  And, it seems like some of the speakers threw out a few ESRI agile "code words".    The first hint was dropped by Euan Cameron, Senior Architect on the ArcGIS Explorer product.  According to Euan, ArcGIS Explorer Build 480 will be based on user prioritized needs gathered through direct user feedback.  Euan said they learned a lot from the user feedback that they're pushing into their products.  Words like rapid evolution and frequent releases also escaped his lips.  Smells of agile to me. 

Next, Scott Morehouse, ESRI's Director of Software Development, followed up with the big picture for ESRI.  Again, similar words.  "More frequent releases...modularizing for faster releases...incremental releases".  Coming out of Scott's mouth, this means a lot!

Jim Berry, the Program Manager for the ESRI Developer Network also spoke about a community approach to their development.  A lot of "ESRI and You" huggy feely kind of stuff, but still, a new road for ESRI.  They're talking about ESRI doing more active blogging and sharing with their customers. 

Now, you may not see the word agile being thrown around here by the ESRI guys, but I think we're hearing ESRI code for it.  The idea of frequent incremental releases is very encouraging.  Opening communications between ESRI developers and the rest of the GIS development community is a very good thing.  I'm looking forward to seeing where this takes ESRI in the next year, but I'm hoping it's a better place...a more agile place.

OK, so I try hard not to use my blog as a soapbox, but this occasion kind of warrants it.  Today, I was really amped to be getting on a flight to Palm Springs to get to the ESRI Developers Summit.  Got to Denver International, got my boarding pass for my U.S. Airways  flight (notice no hyperlink for U.S. Airways here), and went to the gate...and waited...and waited...and waited.  You guessed it, the flight left late.  Not sure why.  They never gave a reason.  We just left about 30 minutes late.

Unfortunately, I had a connecting flight in Phoenix before heading to the gem in the desert.  In flight, I mentioned to the flight attendant that based on our departure time, it was going to be a very tight connection in Phoenix (it was looking like about 10 minutes).  She said not to worry, I'd make my flight.  So, I get to lovely Sky Harbor International in Phoenix, run my butt off to my next flight...and see a bunch of other poor souls looking distressed at the gate (5 others, coincidentally, were also heading to the DevSummit).  I made it to my flight by 7:45 (the flight was scheduled for 7:55).  I asked the oh-so-pleasant gate agent (please read with dripping sarcasm) if we could get on the flight that was still at the gate.  An abrupt "No".  That's it, no sorry sir, no nothing...just NO.  So we're all standing there saying, "The plane is still there, you've got to be kidding!"  A second gate agent, possibly feeling sorry for us, maybe even considering that customer service is a good thing, says to "pleasant" gate agent #1, "Should we let them on?" (apparently there were options here.)  Gate agent #1: "No.  They're late."  So, what were supposed to do now?  The answer "Go to customer service...I can't do anything". 

So, off we trundle to "customer service".  After a wait in the "customer service" queue, I get to the ever pleasant "customer service" agent.  After explaining the situation, she has to confirm why my incoming flight was late to make sure I was entitled to "something".  After realizing it was U.S. Airways' fault (who else's could it have been), they were "kind" enough to offer a flight out the next morning.  "No more flights out tonight".  Correct, no flights on U.S. Airways, but there were flights on other airlines to Palm Springs (gotta love mobile Expedia!).  Now, to give you a little background here, my dad worked for Pan Am for over 30 years...I've done a ton of traveling and I know what these guys can do for you if they want to.  So, I said, "Fine, please book me on another airline."  The response "Sorry, I can't do that."  As Colonel Potter of M*A*S*H always said, bullhockey...they can and they do.  Now I'm losing it.  "Look ma'am, you knew you had several inbound passengers on delayed flights and you didn't hold the flight.  You should have held it, you can do that you know."  The incredible response  "It all depends.  If we want to make an on time departure, we can leave without you.  It's our prerogative. " My response (and loud enough for others in line to hear this) "REALLY?  So, stranding paying customers, pissing them off, making sure they'll never fly your airline is OK so long as you leave on time?"  Her response "Yes. Being on time for departures is important for us."  My response "Great, then why the freak was my flight from Denver to here not on time?".  Her response "Sir, it's not my fault".  So, I can't help it now (maybe I read too much Seth Godin for my own good). "Ma'am, it is your fault.  You represent your airline and you are the public face of U.S. Airways and the best you can come up with is 'It's no my fault?'  I'm sorry, my dad was with Pan Am his whole career, I've flown for a long time and I've never seen nonsense like this before."  She says, with a straight face (and dripping with sarcasm again), "I can't believe that.  You must be very lucky."  So I politely said "No, I've just flown on airlines that care about customer service."

So, before I ramble too much more, she graciously gives me a voucher for a $49/night hotel room at the Fiesta Inn (which apparently has a great deal with U.S. Airways because everyone on the jam packed hotel shuttle was a disgruntled U.S. Airways customer that didn't make a connection).  I looked at her and said "Excuse me, what about food?"  She says (again with a straight face), "It's after 8:00, you don't need food."  I guess the look on my face said it all, because she quickly replied "Well you've been so nice (read sarcastically again) I guess I should give you something!".  In the end, she literally threw my new boarding pass and vouchers across the counter and says "Have great night" to which I responded "You too.  And by the way, you're a gleaming example of excellent customer service", to which she sarcastically responded "Thank You."  Needless to say, I will make every conceivable effort not to fly on U.S. Airways again and to let others know they should do the same.

The only high point in all of this was the very pleasant front desk clerk at the Fiesta Inn (which isn't all that bad, and, notice the hyperlink here).  So, to at least balance my karma for the evening, I was sure to tell her that she was very nice and was the best part of my day today.  She smiled and said "That's my job".  I'd stay at the Fiesta Inn again just because of that comment and her pleasant attitude.  And that's why customer service matters.

To my fellow stranded compadres heading to the DevSummit, see you for the early flight tomorrow morning...you know who you are, and so will everyone else at the DevSummit based on your bloodshot eyes!

Dave Bouwman, Vish, and I will be heading to the ESRI Developer Summit in Palm Springs, CA this week.  It promises to be a good one this year, especially with imminent release of ArcGIS Server 9.3  Check out our new website DTS Agile and our picks for  "must-see" sessions at the Dev Summit.  We'll be blogging from the event, and are always excited to meet new people working in this exciting field. If you see any of us, be sure to come up and say hello!

If you're interested in meeting up with us, we'll be hanging at the Wyndham Hotel Monday night with James Fee and a bunch of other folks talking GIS, agile, and lots of other cool stuff.

When: Monday 3/17 @ 6:30
Where: Wyndham Lobby Bar
Who: Anyone who wants to talk ESRI or GIS
What: Dinner/Drinks/Talking

We've pulled the trigger and launched DTS Agile, a new division of Data Transfer Solutions. 

DTS Agile was founded with a vision to share our knowledge of agile software development patterns and practices with others. The team at DTS Agile is an active software development team that has completely embraced agile practices to deliver high value, high quality software to our customers. Whether we're building custom enterprise GIS systems, helping organizations fix problems that other development teams have created, or helping organizations improve the effectiveness of their development teams, we use agile practices to guide our work. We have built the agile foundations of collaboration, transparency, feedback, and reflection, into every aspect of our work; from software development to project management practices, from executive management to accounting.

Through our real world experience, we have gained valuable insights into what works and what doesn't work. We've made the mistakes and learned from them first hand. We want to share our experience through agile training, coaching and consulting services with others in the software development community so that they can break free of the detrimental patterns and practices of outdated software development methodologies and truly deliver value to their customers. 

Check out our new website at www.dtsagile.com for more information about our cool new venture.

Seems to be the week for announcing free webinars!  Here's another one from StickyMinds called Four Tips for Managing Distributed Development Teams.  Here are the details:

Date: Tuesday, March 25, 2008, 1:00 p.m. ET

Featured Speakers: Martin Van Ryswyck, VP of Engineering, Electric Cloud and Jim Bell, VP of Marketing, Electric Cloud

Description: In this presentation we will examine how geographically distributed teams can improve software production processes through asset reuse, shared infrastructure and resources, and repeatable processes. We'll focus on the impact of distributed development on the back-end processes that follow check-in of new code: the build, package, test, and deploy tasks that are often the bottleneck to timely and efficient project completion.

Register here

Hmmm...guess I posted my Link Karma stuff to soon.  Today Rally announced a new webinar with GlobalLogic called From Agile Development to Agile Deployment.  Looks to be a good one.  To register, cruise over to Rally's registration page.

Description from Rally:

"From Agile Development to Agile Delivery" will discuss the best practices and incremental adoption strategies that enable teams to take advantage of SaaS and SOA based delivery models to deliver customer value while relying on Agile development practices.

Well, the polls have closed, the results have been tallied, cross-tabulated and graphed for the Agile GIS Survey 2008 (and unlike the Democratic primary race here in the U.S., we have a conclusion).  A complete whitepaper detailing the survey results and conclusions is available here.  A summary of the survey results is available here.  A version of the whitepaper has also been published by Directions Magazine on their website and is available here.

Overall the survey was a huge success.  We gathered 347 responses from GIS professionals from 36 countries.  Here are some of the highlights:

Of 347 respondents, 32% said their organization had adopted any agile practices, 68% said they had not.  This compares to 69% of the mainstream development world that has adopted agile practices according to Scott Ambler's survey asking the same question in 2007.

But don't despair.  There is good news.  Although the general agile adoption rate is lower amongst GIS developers than mainstream developers, once they do adopt agile practices, they do so pretty much in the same fashion as everyone else does.  And more good news, of the respondents who indicated that their organizations had adopted agile practices, 86% indicated that they have used agile on at  least 2 projects.  This means that agile practices are moving beyond the pilot stage for the GIS development teams that are doing agile.

Within the GIS development population, there are definite differences in how different practices are adopted based on organization size and organizational experience with agile practices. 

Another key finding was related to coaching and training.  The survey indicated that 49% of Expert teams (those who have run more than 20 agile projects) have received agile training as compared to 0% of Rookies (1 agile project), 8% of Learning Curve teams (2-5 agile projects), and 14% of Mature teams (5-20 agile projects). Agile coaching displayed a similar trend in that 29% of Experts have used agile coaches to help improve and accelerate their agile adoption while 0% of Rookies, 3% of Learning Curves, and 14% of Mature teams have done the same.

So, at the risk of writing too much here beyond highlights, download the whitepaper and the results summary and check it out for yourself.  If you're interested in more detailed results that you can run your own analyses on, please contact me directly.

I would like to thank the following individuals and organizations for their promotion of the Agile GIS Survey: James Fee of Spatially Adjusted and Planet Geospatial , Adena Schutzberg of Directions Magazine, Hilary Perkins of URISA and DTS, Glenn Letham of The AnyGeo Blog, Ron Exler of the GeoFactor, and Agile Commons. I would also like thank Ryan Martens of Rally Software Development for independently reviewing and commenting on the results of this study.

A little link karma to be spread around on this beautiful Wednesday morning in Northern Colorado. 

The free webinars

The IT Metrics and Productivity Journal runs an ongoing Software Best Practices Webinar Series.  In the coming weeks, the following webinars look pretty interesting:

March 12: Managing Iterative Software Development Projects

March 13: Lean-Agile Software Development

March 17: Analysis of New Development Technologies

April 8: Refactoring Your Software Process Toward Agiity

April 16: Continuous Integration: Improving Software Quality and Reducing Risk

To see their entire webinar schedule, click here.

From my good friends at Rally Software Development, there are two live/on-demand webinars you can check out:

April 8 (and on-demand): Getting Started with Rally and Agile

On-Demand: How Product Management Must Change to Enable the Agile Enterprise

If you're a fellow blogger, you might be interested in HubSpot's free webinar:

March 19: Blog Marketing: Getting Found Online

..and a podcast

Check out the Grey Matters podcast featuring Lee Copeland and his Nine Forgettings.

Congratulations to Ryan Martens and his entire team at Rally Software Development on winning their third consecutive Jolt Product Excellence Award.  Here at DTS, we use Rally as our agile product and project management solution and couldn't be more satisfied.  Rally provides an excellent product and excellent customer service.  We love working with these guys!  If you're doing agile and are looking for an agile lifecycle management solution, you owe it to yourself and your organization to check out Rally's tools.

A great question that I've heard several times now is "How do you award bonuses or implement employee incentive programs in an agile organization?".  As we've been rolling out our enterprise agile strategy at DTS, we've been wrestling with this question too.  Since agile practices don't encourage heroism or the individual developer but instead focus on team accomplishments, we thought that bonuses needed to be dished out on a team-wide basis.  We've considered project based bonuses for the entire project team and we've also considered iteration based bonuses for the project team.  In the project based model, we've been considering providing bonuses if our project teams complete their work ahead of schedule, under budget, and with 100% client acceptance.  The structure of the bonus would be something like 1% of the total contract value to be divided amongst the project team as they see fit.

Our other option is to do iteration based bonuses.  This idea came to me from my friend Bruce Scott who works at a Silicon Valley company called ParAccel.  Bruce ran a few "experiments" with agile teams and iteration based bonuses.  Before I just launch into the results of Bruce's experiments you should know who Bruce is. 

Bruce has more than 25 years of experience building successful and profitable IT enterprises.  He has been responsible for product management and engineering, research, services and support at SenSage. As VP of Engineering, he improved the product strategy and engineering process, leading to strategic partnerships with EMC, IBM, HP and Tokyo Electron. He also founded and served as CEO of PointBase, a Java-based embedded database provider. Building the company from the ground up, his licensing savvy and strategic partnerships led to its successful sale to DataMirror.  Back in 1984, Bruce co-founded Gupta Corp. As VP of Database and Connectivity R&D, he developed its first database product, SQLBase, the first database server to run on a PC LAN and support the client-server architecture. Prior to Gupta, Bruce was one of four co-founders of Oracle Corp., serving as the principle engineer and architect of Oracle database's first three versions. Hundreds of thousands of Oracle users know Bruce by the product's default username and password "Scott/Tiger." So, Bruce has credibility if know what I mean.

Bruce's experiment was simple.  In the middle of an iteration that appeared stagnant or not very likely to conclude successfully, he announced that if his development team burned down the iteration to zero by then end of the iteration, each team member would receive a $1000 bonus.  Here's what the burndown chart looked like for that iteration:

What looked to be a failing iteration was rescued by providing an incentive to burn down the iteration successfully.  The burndown rate following the bonus announcement is staggering. 

The second experiment Bruce ran was to announce a $1000 bonus at the start of the next iteration.  Here's what the burndown chart looked like for that iteration:

According to Bruce, the team stayed below the ideal burndown line until 1/30 where they added another significant story. The story wasn’t completed and was removed at the end of the sprint. This was a 31 point sprint, which was the highest this team had ever done. The sprint velocity before this was 23.5!

So, judging from Bruce's experiments, I'd say iteration based bonuses look like pretty good incentives to keep agile teams going.  And, when it comes to project based bonuses, here's Bruce's take on the subject:

On the topic of bonuses per sprint or per project, I had the identical discussion with my CEO. I convinced him to do it per sprint for the following reasons:

1) A project bonus is un-Agile like. What if the scope of the project changes? This is easier and more realistic to manage on a sprint than a project basis.

2) There is a backpackers saying in regards to minimizing the weight of a backpack that says “watch the ounces and the pounds will take care of themselves.”

3) Per sprint bonuses provide more immediate rewards and have a more likely impact on velocity than a long term reward.

I'm not sure which we'll finally implement at DTS, but I'm leaning heavily toward iteration based bonuses based on Bruce's results.  If you have any opinions on the topic, or have any metrics you'd like share based on bonuses or incentives, I'd love to hear them.

OK, maybe it's just me that finds this funny, but a recent survey by Stelligent of CIO's found the following:

• - 72% of CIO's said that NO, they did not have a solid understanding of Agile Development Methodologies.
• - 72% of CIO's said YES, they are open to adopting agile methods.

Now I don't know about you, but if I don't have a "solid understanding" of something, I'm generally not inclined to be open to adopting it!  I think I'd do a bit more research first.  Could this be the buzzword effect: "We have to adopt agile...it's the latest and greatest" while in their head they're thinking "What is agile anyway? I keep hearing about it".

These same CIO's went on to add their opinions on the importance for organizations to adopt agile methods:

• - 29% said extremely important, 50% said important, and 14% said somewhat important.

Hmmm..."It's very important that we adopt something I don't really understand."  Again, maybe it's just me, but I find these results rather funny...or scary depending on your point of view! 

As we roll out agile practices through the Data Transfer Solutions enterprise, we've been taking into account our geographic dispersion.  We have ten office locations across the country in various time zones that are all working on agile project teams together.  Although agile works best in co-located teams, it is necessary for us to find a way to make it work across the miles.  It's been part of my job to figure out how to make it work. 

As I've considered different communication strategies, I've been building this little "matrix in my head" comparing the richness and risk of each medium.  By richness, I mean how interactive, collaborative, and effective the communications are through each medium.  Risk is a measure of the reliability of the medium to deliver effective communications.  There isn't a lot of rocket science here, but I thought I'd share it anyway.  Here's what I've come up with so far (and this is subject to change as we do a little more "experimenting"):

The Agilistas Group on LinkedIn has surpassed the 400 member mark!  The group includes such notable names in agile development as Mike Cohen, Esther Derby, Jean Tabaka, James Coplien, Mary Poppendieck, Ryan Martens, and Johanna Rothman as well as hundreds of other awesome agile practitioners.  If you'd like to join the group, visit http://www.linkedin.com/e/gis/43421/24A5E7397137.

And if you haven't already heard, the good folks at Rally Software Development have helped launch an Agilistas website as part of Agile Commons (thanks a million to Mike Alber and Ryan Martens at Rally).  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.

Let's face it, no matter where you work, fires flare up from time to time.  Some are serious and need to be addressed, some are just smoldering and can be put off for a short time, and some are just people yelling fire when there is no fire.  Some organizations are perpetually in fire drill mode and can't break the habit.  So, if you're an agile organization and your agile teams are committed to completing their iteration tasks, how do you fight these fires without interrupting your agile teams?  Even if you allow a buffer of time within your iteration planning for handling unexpected requests, you still run the risk of distracting your development teams with potentially harmful context switching. 

An interesting solution may be to assemble an agile fire fighting team.  Essentially, the team would be composed of developers from different project teams.  The fire fighting team would be assembled for two-week iterations (synchronized with your project iterations) and team members would rotate in and out of the team.  One team member would be the fire captain.  The fire captain is responsible for handling fire drill requests, triaging them, prioritizing them, and working with the fire fighting team to task them out. During their rotation on the fire fighting team, team members respond to urgent requests and work on them the same way they would any other task in an iteration, committing to address them by the conclusion of the iteration.  What if there are no fires to fight?  Well, don't get too excited...it's not off to the beach for the fire fighting team.  If there are no fires, team members can address defects that may exist on their current project backlogs, they can work on documentation tasks (I knew you'd love that), or they can use the time as part of their hackathon innovation allowance. 

My personal preference is that organizations work as hard as they can to move beyond the fire drill mode.  I think it is harmful to your development teams, reduces overall quality and value you are delivering to your customers, and ultimately it will impact you organization in a negative way. That said, if you can't wean yourself off the fire drill mentality, consider putting together a fire fighting team.

I've heard people say that scrum teams don't have a heart.  We plow through backlogs with our heads down.  We finish a project.  We start another and plow through the next backlog.  Story, plan, task, sprint, demo, retrospect, repeat.  Story, plan, task, sprint, demo, retrospect, repeat.  Where's the heart?  When do scrum teams look beyond these super focused iteration based tasks and think about innovation.  I agree with this assessment.  I think that agile and scrum teams can get stuck in this rut.  Well, we've all heard about the Google 20%...20% of time spent working on innovation.  I like that, but can most organizations really afford 20% of our time to do free thinking?  Probably not, we're not all making billions of dollars like Google.  But that doesn't mean we can't do something about this dilemma.  Personally, I like something like a hackfest or hackathon.  Maybe after 6 weeks of focused development, your team gets a week to do some focused play.  A one week iteration...tell us what you're going to work on...be innovative, do something cool and commit to it.  At the end of the week, same old same old...do a review.  Everyone DEMONSTRATES their cool idea.  Not a diagram, not a slideshow...demo something you can show us. 

I think that unless you're completely dominant in your market space, you need to be doing something like this to keep you innovative and on the competitive edge.  It's the old innovation curves again.  You want to always be anticipating or defining what the next thing is.  If you don't, you slide down the laggard side of the innovation curve and risk becoming irrelevant.  If you slide down that curve, it's very difficult to get back up to that next innovation curve.  So, give your teams time to innovate...it's good for your organization's future, it's good for your customers, and it's good for the professional growth and health of your development teams.

On a daily basis, agile teams should be answering three basic questions: (1) What did you work on yesterday? (2) What are you working on today? and (3) Do you have any impediments to accomplishing your tasks?  That third one is a key question, and one that is answered differently depending on the maturity of your team.  What is an impediment anyway?  It can be a multitude of things, from organizational issues to technical resources, from physical impediments to technical ones.  But how good is your team at identifying impediments and voicing them?  I think that depends on the maturity of the team.  There are always the easy impediments that are surfaced when you first start doing agile.  It's the subtle impediments that are tougher to identify.

I heard something recently from one of our agile teams when I listened in on a few of their daily stand-up meetings. For three meetings in a row, the same developer reported that he worked the same task all three days and was planning on working on it again.  One of the other developers picked up on this and said, "You only estimated 6 hours for that thing.  Are you having trouble with it?  Is there something we can do to help you out?"  There are two things I really liked about this comment.  First it showed concern about the estimate, but there was no blame attached.  It wasn't "Hey, you said it was going to take 6 hours and now you're 3 days in.  Are you really working or are you playing around?"  It expressed real concern.  And secondly, it asked the right question: "Are you having a problem with accomplishing your task?".  Even though the first developer wasn't reporting an impediment, the second was making sure than there wasn't an impediment.  This led to a discussion between the developers about why this task was taking so long.  It turned out that the first developer was waiting on live data (not staged) from one of our clients and couldn't make much progress without the live data.  I was really glad to hear this conversation take place between the developers.  It clearly illustrated the maturity of the team members to work collaboratively to identify impediments to reaching their iteration goal.