I've been spending the past few days working in Cupertino in the heart of Silicon Valley.  As I look out my hotel room window, I can see below me the headquarters of Apple and Symantec.  This evening, I took a short drive to see the headquarters of Adobe, Google, HP, Intel, Yahoo and a few others (OK, I was bored and a little geeked out by being here).  Spending time at the epicenter of the tech community had me asking the question, "If agile has really gone mainstream, how many of these tech companies are using agile practices, and if they are using agile, how are they doing?"  When I got back to my hotel room, I Googled "agile adoption rates" and came across a survey that Scott Ambler did in March 2007 about the rate of agile adoption.  Scott received 781 responses to his interview and published his findings on his website and in Dr. Dobb's.  According to Scott, his key findings were:

1. 69% of respondents indicated that their organizations are doing one or more agile projects.  Of those that hadn't yet started, 24% believed their organizations would do so within the next year.
2. 44% indicated a 90%+ success rate at agile projects, 33% indicated between 75% and 90%.  It appears that agile seems to be working out.
3. Co-located agile projects are more successful on average than non-co-located, which in turn are more successful than projects involving offshoring.
4. 98.6% of agile teams worked adopted iterations, and 83% had iteration lengths between 1 and 4 weeks.
5. Smaller teams had higher success rates than larger teams.
6. 85% of organizations doing agile had more than one project completed, so it's gone beyond the pilot project stage in most organizations.

Of course, this led me to my inevitable question that has been dogging me for some time.  If the adoption rates are so high amongst the mainstream development community, why hasn't the GIS development community gravitated toward agile practices?  I know I keep asking this, but it really worth exploring.  To those of you out there in the GIS community, I ask you: should we conduct a similar survey to Scott's and find out just what the state of GIS development looks like?  I'd like to hear your thoughts on this as I am seriously considering undertaking a survey like this for the GIS community.

While I was flying out to San Jose this afternoon, I was re-reading Garr Reynolds' new book Presentation Zen.  If you haven't read this book yet, run and out and get it now.  It is the antidote to death by PowerPoint.  One thought that struck me for a second time in Garr's book is the idea of the "beginner's mind" or the child's mind.  The beginner's mind is a concept that comes to us from Zen teachings that, according to Garr, says "like a child, one who approaches life with a beginner's mind is fresh, enthusiastic, and open to the vast possibilities of ideas and solutions before them".  Garr goes on to expound that "when you approach a new challenge as a true beginner (even if you're a seasoned adult), you need not be saddled with fear of failure or of making mistakes."

We can do very well on our agile teams if we  approach our development tasks with the beginner's mind.  Developers are, believe it or not, creative people.  If we all decided to think with a beginner's mind about the solutions we develop, we might be able to create extraordinary software.  OK, maybe not always extraordinary, but we might provide innovative solutions that were unexpected.

We can learn even more by adopting the beginner's mind when we approach how we work.  We should always be open to different ways of doing things and not be afraid to make mistakes.  In our agile practices, in our planning meetings, and in our retrospectives we should think like beginners about ways we can do things differently.  If we use the beginner's mind, we can stop constraining ourselves to the "rules" of agile and really think about creative ways we can work better, smarter, and faster.

The opposite of the beginner's mind is the expert's mind.  If we approach things with the expert's mind, we think we have all the answers and know the ways things ought to be done.  I believe the expert mind leads to "methodologies" and "processes" instead of practices.  The expert mind assumes that if we know the way things should be done, we can follow the stepwise recipe for success.  I think there is a contingent out there today in the development world that works using the expert mind.  They approach projects with a methodology and try to enforce strict processes to achieve success.  Follow the logical steps and you'll deliver the product at the end.  You know what I'm referring to...we call it waterfall.  It comes from the expert mind that says that the path to success is predefined by years of experience.

I personally believe that success depends on each agile team's particular situation and the creative solutions those teams devise to complete their tasks and improve the way they work.  And, as I said earlier, this creativity relies upon adopting the beginner's mind.  So go ahead...let go.  Let the child inside you help you and your team be the best (and most creative) you can be.  

I was watching an old movie last night that I think is hysterical called "What About Bob?" starring Richard Dreyfus and Bill Murray.  Bill Murray plays a guy with tons of phobias.  Richard Dreyfus plays his doctor who is teaching him about taking baby steps to overcome his fears.  Bill Murray has one particular phobia about riding in elevators.  At one point in the movie, he decides to finally try getting on an elevator and says "Baby steps onto the elevator...baby steps into the elevator...I'm in the elevator" (the doors close) "HELLLLLLLLLLP!!!!!".

Seeing that movie was the perfect impetus for me to write this post.  I've been doing a lot of thinking lately on how to take our company through the agile adoption process.  I'm thinking baby steps (minus the "Help!" scream hopefully).  Over the past few weeks I've spoken with a number of leading agile proponents about what they would do to adopt agile in an enterprise and the answer has been a resounding "baby steps".  I'm glad to hear that because that's how our small development team first adopted agile ourselves.  I don't believe that an organization can just throw the magic agile switch and change things overnight.  I think that agile has to be grown organically in a series of steps that help organizations successfully adopt and accept agile practices. 

The first step our team took was just getting into the agile "flow".  We instituted some basic practices to get our team into a good rhythm and to introduce agile concepts.  We decided to begin two-week iterations on a single project.  We already had some half-way decent requirements definitions for the work.  But, we didn't start prioritizing, building user stories, assigning story points, playing planning poker or anything else.  We just started with a simple, two-week iteration in which we tried to decide what we could complete during that iteration.  We planned the iteration collaboratively and really committed to completing everything we bit off for that iteration.  We also started the practice of a daily stand-up, an iteration review, and a retrospective.  That's it.  We did that for quite some time until the team was comfortable with the flow of an agile, iterative development style.  It was working well, and it seemed to fit for our team.

Once we became comfortable with our new agile practices, we started to slowly introduce others into the mix.  We began re-writing our requirements as user stories.  We started playing planning poker to estimate story points.  And, we began to track our velocity.  As the ScrumMaster, I started to really protect the team from distractions and did everything I could to remove impediments for them.  Again, that was it for quite some time.  When we were feeling good about those, we introduced our client to the idea of prioritizing his backlog of user stories (it was a fixed-scope fixed-price contract, but we thought this was a good exercise to learn from anyway).  We also started to really emphasize acceptance testing.  Once we were alright with this set of practices, we took a look at what we should be doing on the actual development side to become more agile.  We introduced continuous integration, daily builds, lite versions of paired programming.  Again, just a few small practices that helped us slowly become more agile.  Our next step was release planning.  Around that time, we introduced some tooling for managing the projects (Rally) and we also began doing serious defect tracking and fixes with some tooling as well.  We had also decided to start implementing agile practices on some other projects that our team was responsible for.

When we felt that we had a handle on our own team, we started to evangelize to our peers and our organization.  The organization caught on after some convincing and started sending other project managers to Certified ScrumMaster training.  We were going to start sending members of our team out onto other project teams to help coach and guide them in their adoption of agile practices.  However, we left our old organization before we got to realize the full enterprise adoption of agile, but we were well on our way to getting them there.

Now, with our new company, we get to do it again...and we're much smarter from our previous efforts.  And our new company has an organizational culture which is very supportive of agile practices.  As we move through our adoption process, I'll keep you posted on our progress, but I'm pretty sure we'll be taking baby steps first.  Baby step into the flow...baby step into agile practices...we're doing agile development!!!

I recently came across a quote from one of my favorite authors, Pearl S. Buck.  She said:

         “One faces the future with one's past.”

Short, sweet and to the point.  The quote really struck a chord with me because our development team recently learned this lesson the agile way.  Last Friday, we completed the second iteration of an enterprise GIS development project and conducted a sprint review with our client.  To our dismay, we seemed to have been off the mark in terms of what the client was expecting.  The client seemed disappointed and our team was as well. 

After the review, we conducted a team retrospective and the main topic was "Why did we miss the mark so badly?".  It was the right question to ask and sparked a very open discussion.  We discovered that we had not adequately uncovered the business cases behind the user stories, that we had a communications gap with our client, and that we didn't do a thorough review of the client's existing application.  We then asked the question "What do we do to fix this?".  We decided that at the following sprint planning session, we would discuss the user stories with our client again.  We decided to hit the problem head on and increase our communications with the client and thoroughly review the existing application.

On Tuesday, we held our scheduled sprint planning session with the client.  We gave our apologies for our missteps, emphasized the value of agile for helping catch this issue quickly and initiated a great, open, and collaborative planning session.  To our pleasure, the client had identified the same set of issues as our development team had  and came prepared to give a demo of the existing application.  They were also very patient answering the questions our developers had about the user stories. In the end, everyone walked away from the sprint planning meeting feeling that we were back on track. 

We also walked away with the feeling that our agile practices had done their job.  They helped us raise any dysfunction to a visible level very quickly, and also allowed us to resolve those issues very quickly.   If we had been developing in a traditional waterfall fashion, we could have been 6 months into development along the wrong track before anyone realized there was a problem...and by then it would have been too late.  We would have had angry clients, a discouraged development team, and a failing project.  Instead, we face our future with the full understanding of our past mistakes, a satisfied client, and a motivated development team.  You live, you learn...

Hear about the latest Agile best practices from Rally and GlobalLogic. In this webinar, you'll learn practical tips about how distributed Agile-based methods are being successfully employed today.

When: Wednesday, January 30, 11:00 am Mountain Time

Register now

It's not often that I write about geography or maps, but our team here at Data Transfer Solutions primarily develops Geographic Information Systems (GIS) software for making maps.  But we're not the only ones making maps these days.  There is a little, otherwise nondescript, bird known as the white-crowned sparrow that doesn't need any help at all from software or computers to make maps.  These little birds summer in Alaska and winter in Mexico and the southwestern United States.  And scientists have recently proved that during their long migration, they navigate using maps.  Yes maps...and they create the maps themselves! 

According to a recent article in Smithsonian Magazine, a research team captured a group of adult and juvenile these birds in Washington State and flew them to New Jersey.  After placing radio collars on their backs, the birds were released.  The adults headed straight toward their usual wintering grounds in the American southwest.  The juveniles, who were making their very first migration, head due south toward Florida. 

How did the adults know where to fly?  The researchers say that the sparrows instinctively fly due south on their first migration and along the way, they build a mental map of their wintering grounds that allows them to return there from any other location.  The adults had a mental map of their flyway and were able to follow it to return their wintering grounds.  So, how's that for an avian cartographer (that's a bird map maker to the rest of us)?

Something our team has wrestled with over the course of our agile adoption is how architecture and framework development fit into our Scrum process.  We strive to deliver an increment of functionality to our client at the conclusion of each sprint.  However, in many of our early sprints, we have to do architecture and framework development.  The things we develop on these types of architecture/functionality tasks are not really useable by our clients and we really can't demo them either.  Brian Noyle recently wrote a post on his blog asking a similar question.

So, we've decided that the best of course of action is to strike a good balance between architecture/framework and functionality development.  In earlier sprints, we've accepted that architecture/framework will be a big part of what we're working on.  But we've also become cognizant of the fact that we need to show something to the client in terms of functionality.  So, we usually comb through the backlog and pick the highest prioritized backlog item that we can complete early in the first sprints, while still doing the architecture/framework tasks we need to get done.  In this way, we ensure that the client sees forward progress that they can touch and understand right out of the gate, and we build the architecture and framework to support future development efforts on the project.  As we progress through our development, architecture/framework tasks become fewer and our delivery of functionality increases steadily.  In graphic form, it looks something like this:

Jim Coplien is a leading voice in the agile community, especially in the area of organizational development.  He is considered the father of Organizational Patterns, and is one of the founders of the Software Pattern discipline.  He is currently Second Mate (a curious and only indirectly meaningful title) at Gertrud & Cope in Denmark.  He is also the co-author of the widely acclaimed book Organizational Patterns of Agile Software Development.  Cope was also a founding member of the Hillside Group along with such visionaries as Kent Beck, Grady Brooch, Ward Cunningham, Ralph Johnson, Ken Auer, and Hal Hildebrand. Here is the conclusion to my interview with Cope.

Q.  You spend a great deal of time talking about organizational patterns in agile software development.  Can you briefly explain what organizational patterns are?

A. An organizational pattern is a recurring configuration of organizational structure (more precisely, organizational form) that bodes for quality of life. Organizational patterns are the foundations of culture. Anthropology has long understood this, and at least one classic of modern anthropology — Kroeber's Patterns of Culture (1948) — takes this stance. Patterns fit together into something called a pattern language: a collection of patterns designed to fit together to give rise to a certain culture or organizational style. Any organization aspiring to the cultural trappings and mores adopts the patterns of that culture.

Neil Harrison, Brendan Cain and I collected good organizational patterns of software development over a period of about ten years through a program of empirical research with real-world teams. We incorporated other patterns written by Ward Cunningham, Alistair Cockburn, Steve Berczuk, and others. Kent Beck has often pointed to those patterns as the foundation of XP, and Jeff Sutherland points to that work as the origin of daily Scrums. In a broad sense, our current collection of patterns (Organizational Patterns of Agile Software Development) is the foundation of contemporary Agile values and practice.

Q. What patterns would say are the most important in successful agile teams and organizations?

A. Neil and I have our favorite Top Ten list of patterns. But here, let me instead go back to your earlier question. Whereas Jeff talks about failure modes, Scrum more directly talks about helpful structures that reflect the deeper patterns beneath them. If we turn around Jeff's pitfalls, we come up with patterns like:

Function Owner and Component Owner

Unity of Purpose

Small Teams

Firewall

Domain Expertise in Roles

Engage Customers

Team Pride

But, what makes a pattern important is that it speaks to the team. Each team will find a different set of patterns that apply to its needs, and any given team would choose a different set at different points in time. They're about inspiration rather than prescription.

Q. Are there specific techniques organizations can use to assess their current patterns?

A. The foundation of the organizational patterns in any organization lie within its communication network. I like to use a facilitated role-playing exercise to unearth the communication pathways in an organization. You can use that information to visualize the organization's structure. That structure often makes many patterns obvious, and the exercise itself makes yet other patterns obvious. It's very illuminating for organizations that do this! I offer a service to facilitate such an exercise and to do follow-up analysis (see Getrud and Cope for more information) , as does Neil Harrison in the U.S.

This technique is one form of retrospective. More broadly, retrospectives are the keystone to process improvement. I don't mean the quickie two-hour "check-ups" at the end of a sprint, though those are O.K. I mean the kind of retrospective that Norm Kerth talks about in his book: an off-site, three-day head-holding and soul-searching session. We use the role-playing technique as one tool in such retrospectives, but there are many other tools and many resources to help you come to terms with your current situation.

Q. How difficult is it for the average organization to identify deficiencies in their patterns and adopt or create new patterns to reach their desired state?

A. As difficult as it is to do a retrospective. That may sound easy or hard depending on who you are, and both answers are right. If an organization has the courage and will to change, then the organization can easily assimilate to the tools of introspection and deal adeptly with its shortcomings. If an organization is rife with fear, is insecure, or is stubborn, then it may never come to grips with change.

The "difficulty" here isn't so much about technique as it is about will. An external facilitator can help organizations see themselves in a new kind of mirror.  That mirror helps them see the patterns they have as well as the patterns that they need. Having seen themselves as they are, they can effect changes. I can't change organizations. Only organizations can change themselves. But I can facilitate by bringing tools to bear, and by asking hard questions that keep organizations honest about themselves. Sometimes, facing truth is the hardest part of change.

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

A. That's a pretty open question... Niels Bohr said to be careful about predicting things, particularly if they involve the future. I've thought a lot about this from an unusual perspective.

Most movements in CS have the same distinctive phases. It starts with a brief period of birth pangs in times of broad skepticism, and then takes hold with early adopters. Some of them report success. Then there is a time of rapid, blind growth. Some time during this growth, the backlash starts, and it continues to build until another movement overtakes it. The backlash never quite comes to closure but casts enough aspersions on the movement to make room for the new one. The structured analysis movement followed this, as did ISO 9001, as did component-oriented software and, to some degree, object-oriented software; patterns certainly suffered this fate.

Agile is a bit different because it looks like something new but is in fact almost completely a conscious re-packaging of known ideas. Its early phases reflected the same reactions as any new movement: skepticism, followed by a few good successes, followed by phenomenal growth. Some of the earlier movements were the same way, in the sense of lacking novelty, but were less conscious about it. I think the prime movers behind Agile embraced the security of a more proven position, fueled by a moral code that precipitated largely from the pattern movement (Brian Foote's "aggressive disregard for originality").

I'm not sure that Agile could have been born without the sober context of the pattern movement that provided the empirically grounded dialectic from which it sprang. XP pretended that it had found a magical potion that created something new, a gestalt out of just the right mixture of techniques, but few people believe that (I certainly don't) and the premise has never been established. Scrum swings the sabre of common sense. That's a humble, believable — and powerful — sabre.

To me, this means that the Agile backlash will look different. Instead of there being aspersions cast broadly on the notion of Agile development, doubts will arise about the less mature or mis-applied and in any case more specific practices. This is happening with TDD now ( a good procedural design technique mis-applied to OO) and I'm happy to be on the leading edge of that effort, together with some good researchers who can back up their claims with real studies. There's a good group of people out there actually trying and measuring things, like Angela Martin and Pekka Abrahamsson and Maria Siniaalto. I don't remember anyone inside the community taking the devil's advocate chair during components, OO, or patterns. That smells of something different and wonderful.

I recently had the opportunity to hear Jim Coplien, one of my primary agile influences, speak at the Agile Development Practices Conference in Orlando, Florida.  I was so inspired by Cope’s presentation at the conference that I wanted to share some of his thoughts with the broader agile community.  The best way I could think of to do that is to let Cope speak for himself by way of an interview.  So, as the first in a series of my new Agile Minds interviews with today’s thought leaders in agile development, I’d like to present Jim Coplien.

For those of you who have not heard of Cope, he is a leading voice in the agile community, especially in the area of organizational development.  He is considered the father of Organizational Patterns, and is one of the founders of the Software Pattern discipline.  He is currently Second Mate (a curious and only indirectly meaningful title) at Gertrud & Cope in Denmark.  He is also the co-author of the widely acclaimed book Organizational Patterns of Agile Software Development.  Cope was also a founding member of the Hillside Group along with such visionaries as Kent Beck, Grady Brooch, Ward Cunningham, Ralph Johnson, Ken Auer, and Hal Hildebrand. So without further ado, here's part one of my interview with Cope.

Q. Cope, 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. I suppose I could offer the obvious and usual answers such as the presence of a good communication network; and, in fact, that is a key facet of software development I've scrutinized for most of my career. But if I look at the really fun teams and fun times, I think they all shared one rare quality: that they had a life. They got outside the office, traveled, went to the pub or restaurant together now and then, and did dangerous things like read books — even non-technical ones. That is, they countered the usual stereotype of being a nerd.

It's true: for many of them, their social circle wasn't much different than the people they worked with, but the connections and their nature varied from the office environment in subtle ways. Normal teams may have good interactions among themselves; in the exciting places there's more interaction across teams. Normal teams get together for a code jam; exceptional teams get together to support one of their colleagues at her art exhibition.

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

A. I don't know how important this consideration actually is. There is a common misperception that goodness is the absence of badness. I don't think one aspires to excellence by avoiding pitfalls; I think you avoid pitfalls by aspiring to excellence. To just avoid errors is to muddle along. One corollary to this perspective is that there are ten times as many ways to do things wrong as to do things right, so it is more efficient to enumerate the desideratæ of a good team than to list things to avoid. Human minds — including the collective human mind of a team — crave such efficiency.

So if I were to list common "pitfalls," more of them are sins of omission rather than sins of commission. If you look at Jeff Sutherland's seven failure modes of Scrum, all of them are of this nature: lack of a product owner vision and product backlog; failure of the team to properly break down backlog items; the team is not properly sized; the ScrumMaster doesn't do his or her job; the team isn't skilled; the product isn't demonstrable; or failure to have adequate resources.

Q. It seems that many organizations focus on processes and process improvement in the hopes of fostering high-performance development teams.  However, many of these organizations seem to fail when process becomes too important.  Why do you think this is the case?

A. Again, it could be for many reasons. First, you don't want the absolute maximum of performance; it's about balance. I received a wonderful little mail from one of our CampScrum colleagues the other day, Anders Jutebrant Ivarsson of Ascom:

I [recently] picked up the latest issue of a popular Swedish sailing magazine. There was an interesting article about Roger Nilsson, a famous and experienced sailor that recently was a member of the crew at Orange II, a huge sailing catamaran that set the world record sailing around the world in approximately 50 days.

In the interview, Roger says:

"The most common failure other sailing crews do is that they focus on top-speed. When sailing around the world, that is not important. It will just wear out your crew and equipment. It is by achieving the highest average speed you become a winner!"

This reflects a well-known principle of good process improvement: things need to be in statistical control before you have a foundation for improvement. I advised one of my clients just yesterday to get their Scrum team velocities more consistent before trying any improvement (except those improvements aimed at consistent velocity: better enabling specifications to support estimation; shorter sprints; use of story points instead of absolute hours). Many people jump into Scrum thinking that it will make things better for them, and too many of them end up in disaster. The reason? Scrum is a disciplined process improvement program which itself should build on a stable foundation, and they lacked a stable foundation. Scrum won't give you a good connection to your customer; it depends on having one. Scrum won't give you good configuration management; it depends on having it already. The same is true for automated check-in tests, domain expertise in the team, and a couple dozen other things.

Another important factor here is that processes are a bi-product of a system's structure, so they are at best a second-order factor in organizational improvement. If you change process without changing structure, the structure will win out and the processes will backslide to where they were. It's like dieting: going on a diet is like a process change, a set of rules you apply for a specific partial ordering of tasks called meals. But to lose weight, you need a deeper life-style change: exercise, changes in self-esteem—and maybe dieting, too.

Q. A belief amongst many traditional organizations is that by creating things like mission statements, they somehow instill values into an organization.  Again, this seems to be a major point of failure in many organizations.  How do you believe successful organizations sustain positive values that percolate throughout the entire organization?

A. There is no universal answer. Just as each culture and each company has its own values, it has its own way of diffusing value change. And the techniques vary from value to value.

Trust is a key value in Agile development. Diana Larsen tells us that you build trust in others first by demonstrating trust in others: that at least will help them trust you, and helps people open up to be more trusting in general. This is particularly true when managers demonstrate trust in their employees. How? Sometimes, by giving them enough rope to hang themselves and then rejoicing in their success. It also comes from a culture of appreciation and a discipline of consistency. In all of these issues of appreciation, consistency, and giving up control, it starts with one random act of kindness. It's not something you can plan; I think most of it comes from examples. I think that's true of all values.

I know that there are management teams that believe that such leadership comes by creating posters of values or by giving employees wallet cards with the corporate values on them. People tend not to follow lists; they follow other people. A leader is someone who has followers, and followers arise from trust. In a healthy organization, everyone takes their share of some leadership role at some time as the organization explores and adjusts the value space. An organization that tries to "install" values from a list usually does so because of misguided well-meaning, but it can also telegraph management fear or an attempt by management to master plan things.

That's not to say that vision or positive values are unimportant. There is a proverb that says, "Where there is no vision, the people perish." The values must be lived, and they must be lived in a culture that sustains quality of work life for the employees while helping make the world a better place with quality products or services. A manager who lives great values has monumentally more impact than one who posts values on a plaque or in a mission statement.

The long lists of rules at Hogwarts in the latest Harry Potter movie come to mind.

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. Take it one step at a time. Evolution, not revolution. Some organizations get there by revolution, but it's rarely because anyone advised them to take a revolutionary approach. If the culture is ripe for a revolution, it will happen. In that sense revolutions are easy to make happen, though it's hard to quickly arrive at a positive result. It's evolution that takes hard work and discipline, which is why people look for a revolution instead. Patience is a virtue. (And I want it NOW!)

Stay tuned for the conclusion of my interview with Cope tomorrow...same place...pretty much same time.

Tomorrow, January 17th, Dave Bouwman will be giving a talk at Denver University on using Agile methodologies to manage GIS projects. The talk will be part of Dr Joseph K. Berry's  Special Topics in GIS lectures.  Although this is part of a course, the public is also welcome to attend. Dave will also be posting the slide deck on his blog at www.davebouwman.net.

If you are in the Denver area and interested in attending, here's the course URL: http://www.innovativegis.com/basis/courses/GM_topics08

Dave Bouwman and I recently did a podcast interview with Directions Magazine.  Today it's been posted as the top story on the Directions Magazine website.  If you're not familiar with Directions Magazine, it is one of the top industry magazines in the geospatial industry. Check out Directions Magazine and the podcast at http://www.directionsmag.com/article.php?article_id=2657&trv=1. 

I think I may have found a great mascot for the agile movement.  It may not be the most attractive mascot, but it definitely inspects and adapts in a pretty extreme way.  It's the mangrove killifish.  In a recent discovery late last year, biologists in Florida have found that the mangrove killifish spends a few months every year living in trees.  The fish normally lives in muddy ponds, but when these dry up, hundreds of killifish gather inside of rotten trees until rains fill their ponds again.  To do so, they completely adapt their biology to breathe air instead of water.  They actually alter their gills to retain nutrients and water and excrete waste nitrogen through their skin.

Besides the remarkable biological adaptation, they make a "cultural" adaptation as well.  The killifish are normally aggressively territorial, but they curb their aggression to co-habitate inside of cramped tree trunks to survive.  I've worked in a few places in my past that could have done well by employing this little trick!  On a strange little note, they're also the only known vertebrate that can reproduce without the need for a mate.

So, how's that for an agile mascot!?!?  Any votes out there for the killifish?

P.S. I promise a more useful post tomorrow...an interview with James Coplien, the father of Organizational Patterns.

I was recently spoke with Ron Exler of The GeoFactor about agile practices and GIS.  He wrote a post based on our discussion that raises some good questions about agile GIS.  You can check out the full post at Ron's site The GeoFactor.

A friend of mine, Brian Noyle, a Solutions Architect at Idea Integration, has started writing a blog about .NET and GIS development.  He had a recent post that discussed GIS and agile.  The focus of the post was on the assumption that perhaps too much agile lingo is being bandied about the GIS world right now and not enough GIS folks are walking the agile talk they're spouting.  He could have a point...and it may be happening in more than just the GIS world.  Check out Brian's full post and his new blog at http://briannoyle.wordpress.com/. 

As I've been contemplating moving agile throughout our entire organization here at Data Transfer Solutions, I've been considering the usefulness and effectiveness of an Iteration Zero.  Many agile teams use what's known as Iteration Zero to put the necessary systems in place to enable the delivery of value to the customer.  It's essentially the getting started iteration.  It takes place before any development begins.  I think Peter Schuh described Iteration Zero very well in his book Integrating Agile in the Real World.  Peter says:

"An iteration zero does not deliver any functionality to the customer. Instead the project team focuses on the the simple processes that will be required for the adoption and use of most agile practices. From a management point of view iteration zero may include:

• - Initial list of features identified and prioritized.
• - Project planning mechanism identified and agreed upon.
• - Identification of and agreement upon a team customer, essential stakeholders, and business users and the nature of iterative planning process, such as the time of planning meetings and the length of iterations."

I personally think that the use of an Iteration Zero is very pragmatic and I think that Peter's idea of what Iteration Zero looks like is very realistic.  I believe that in the real world of software development, customers aren't really ready to jump right in and start on a sprint from day one.  Many of them don't entirely understand the Scrum "process".  Most of them don't truly understand their requirements.  I think an Iteration Zero can be useful in educating the customer (and coming to an agreement with them) about the agile planning process.  I also think it can be used to develop the initial prioritized backlog for the project.  Now, I'm not advocating heavy up front requirements gathering here, but you do need some time to create effective user stories to start working from. From a management point of view, check out Agile Support's post on Iteration Zero as it exists within their Agile Contract Engagement Roadmap as seen below:

Aside from the project management side of Iteration Zero, I think there can be a good case for the development team to engage in Iteration Zero as well.  I think that as we switch between projects, we also tend to switch technologies or development platforms.  To do so, development teams may need time to stand up a new database server because the new customer uses Oracle and the last customer needed SQL Server.  Hopefully you have both running so you don't need to worry about things like this, but you get the point.  Sometimes the development team needs some time to get things set up to support the project before they start delivering potentially shippable product increments each sprint.  For a quick idea of what another agile team has done during Iteration Zero, check out Energized Work's post on their Iteration Zero.

I'd like to know your thoughts on Iteration Zero.  Does your team use an Iteration Zero?  If so, what kinds of tasks do they typically include?  And most importantly, do you find them useful and effective in delivering value to your customers?

There are a few webinars coming up in the next two weeks that should definitely be worth your time.  Two are marketing webinars (and after my recent agile marketing post, I hope you take a look at them).  One is an agile webinar.

Seth Godin: How do you avoid the meatball sundae?

The first is by one of the people who truly inspire me to do things differently, Seth Godin.  From Seth's website:

In this brand new presentation, bestselling author Seth Godin outlines 14 trends that are changing businesses forever. He talks about how the new marketing landscape represents nothing short of an industrial revolution, and highlights the organizations and brands and products that are taking this new world by storm. By the end of an hour, Godin will have you looking at the world you live in very differently... the new rules create new winners (and losers) and there's no time to waste.

Sign up for Seth's presentation here.

HubSpot: Press Releases for Modern Inbound Marketing

This webinar is being given by Mike Volpe.  Mike Volpe is the VP of Marketing at HubSpot and has over a decade of Internet marketing experience.  He is a frequent blogger on the acclaimed HubSpot Internet Marketing Blog.  From HubSpot:

Press Releases are no longer just for the traditional media.  Today press releases are key opportunities to reach your market directly - effectively and inexpensively.  This webinar will cover how and why to write and distribute press releases for modern inbound marketing.
- Review the major reasons to distribute press releases
- Learn how to optimize press releases for SEO (search engine optimization)
- Learn how best to distribute press releases
- and more!

Register for the HubSpot webinar here.

4 Secrets from Agile Masters for Increasing Your Personal Agility and Performance

This is being presented by Christopher Avery, an Agile University Trainer for Knowledge Team Leadership.  From Agile University:

So what have I learned in twenty years of studying the personal agility of agile masters?

In brief:

1. Personal Responsibility beats Job Accountability every time. When individuals opt-in, engage, and own their actions and consequences, truth happens fast! You don't need to focus on "driving accountability" when people are owning how they execute.
2. Climbing in the same boat together drives mutual coordination. A keen sense of shared responsibility is the single greatest predictor of teamwork, collaboration, and partnering.
3. Tapping into the power of peer motivation. Teams perform to the level of their least invested members because those members bring everyone else down. Always.
4. Making and keeping agreements that support flow. Agile masters ask for, make, and keep responsible agreements with everyone around them.

Register for the Agile University Webinar here.

Over the past two months, our development team has gone through a lot of changes...from joining a new company and setting up a new work environment to learning new technologies to serve our new clients.  In general, we were a desktop-based shop that focused on the ESRI desktop stack.  However, many of our new clients require web-based mapping applications.  As such, our team is currently climbing a very steep learning curve to work with a new set of technologies in a new environment.  More to the point, there are way more unknowns in what we're currently doing than we've ever dealt with in the past. 

One of the issues this has raised for us is how valid our current user story estimates are.  Right now, everything seems more complex because we are researching just about everything we're doing.  Will the story points we assign to a user story today be valid in 6 months when our tasks become commonplace?  Can we use our current velocity based on our learning curve to provide estimates for new work? We have lots of questions running through our heads right now and we're coming to grips with some of the answers.

Earlier today I was speaking with Ryan Martens, the CTO and Founder of Rally Software Development, and I asked him what he would do in this situation.  Ryan presented two solutions, both of which I think are very useful and effective for resolving our estimating issues.

The 3-Month Sliding Window Approach

One way to address the learning curve is to use a 3-month sliding window approach.  In this approach, recent history is more important than long-term history.  Go ahead and give the user stories the story points you think they deserve based on your current level of knowledge.  But, as you go forward use the past 3-month's worth of estimates to derive your team's velocity.  Keep the 3-months of estimates and velocities sliding forward so that as you move forward and learn more, your estimates and velocity are based on your most recent metrics, not on those gathered during your earlier stages in the learning curve.  The further along in your technology transition you progress, the more stable your estimates will become.  Once your transition is complete, your estimates and velocity should be far more valid than they were at the beginning of your transition.

Factor Out the Learning Curve

Another way to deal with the learning curve is to just factor it out of the equation.  Split the new complex user stories into two pieces: the research component and the actual development component.  Add research spikes to your iterations to learn how to do whatever it is you're getting up to speed on.  Once you figure out how to do it, then estimate the user story in another iteration.  The isolated user story estimate should be closer to a valid value than if you considered it together with your research task.

Whether you realize it or not, every time you interact with a customer, whether it's personal communications, websites, blogs, or emails, you're engaging in marketing (check out Seth Godin's post on this topic).  And so is everyone on your team.  This may seem like an obvious statement but it's crucial for Scrum teams and agile teams to realize this given their high level of interaction with clients and customers.  Every time you conduct an iteration planning meeting, or a sprint review, or even a daily stand up, you're marketing.  Your clients and customers are always listening to what you say and how you say it.  Think about this when you're designing your corporate website, writing a blog post or dealing with a customer service issue after you've delivered a piece of software.

This all came to mind this morning when I was calling our local communications provider Qwest.  I went to their website to find the phone number for their customer service line.  You'd think this would be right there on their main page.  Nope.  Not even a customer service link!  It took me 5 clicks to get me to an overly complicated customer service page that still didn't provide a phone number.  Instead it gave several different "Contact Us" links depending on your request type. My point here is not about website design, but about what this says about Qwest's commitment to customer service.  To me it says "We really don't want to talk to you if we don't have to". 

In addition to our difficulty in locating the correct number, we have received quite a run around trying to set up our T1 lines, our static IP block, and our phone lines at our new office.  We have received so much conflicting and confusing information from Qwest that after two months, we still don't have our T1 lines in.  After today's call to Qwest, it looks like we're finally on the right track.  But all of this poor interaction with Qwest has left us pretty disappointed in both their company and their product. 

Unfortunately, due to semi-monopolistic telecom policies in the U.S., we have to work with Qwest to get what we need (although Skype is a pretty good alternative these days).  But your clients and customers probably don't have to deal with you or your company if you do a lousy job communicating.  So remember, every interaction you have with clients and customers is a marketing opportunity.  Every person on your agile Scrum team, from the senior project manager to the intern developer is a marketing agent.  We need to realize that to keep our customers and clients satisfied, to keep them coming back to us for more work or providing good word of mouth about our organizations, we all need to be effective communicators and marketers.  We need to constantly go that extra mile to provide the best customer service possible.

By the way, the main Qwest customer service line is 1-800-603-6000...but expect to be bounced around quite a bit depending on your request...my record is 8 transfers in a single call!

My cohort in agile development, Dave Bouwman, and I recently completed an interview with SearchSoftwareQuality.com's Tech Target managing editor Jack Vaughn.  The interview was about tooling for agile software development.  While we try not too spend too much time focussing on our tooling, we have found that it is useful and helps us in our streamline and better support our agile practices.  The complete article features opinions about agile tooling from other agilepractitioners as well.  Click here to check out the whole article at Tech Target now.

Last month, I was reading Andy Hunt's blog and came across this interesting quote from Pablo Picasso:

"You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve."

This is a really interesting quote in light of some of the reading I've been doing lately on multi-tasking, context switching and work interruptions.  Multi-tasking, context-switching and interruptions can be the biggest killers to the effectiveness and efficiency of agile teams.  According to David E. Mayer, who is a cognitive scientist and director of the Brain, Cognition and Action Laboratory at the University of Michigan, "Multitasking is going to slow you down, increasing the chances of mistakes.  Disruptions and interruptions are a bad deal from the standpoint of our ability to process information." 

Unfortunately for most of us in the software development world (and the "new" world at large), we have a plethora of technology at our disposal that we heavily rely upon to "manage" our multi-tasked lives.  We firmly believe that Outlook, our Blackberries, iPods, Instant Messaging, multiple monitors and other cool things will help us get through our days more effectively.  The truth is, they don't.  They provide too many distractions from what we get paid to do...develop software. 

A recent context switching study conducted by Microsoft Research and the University of Illinois examined diaries of the daily tasks performed by a variety of users.  What they found was that 45% of the reported tasks in the diaries were project-related or routine tasks that were part of the users jobs.  That figure would be astounding on its own, but when considered along with the tasks that comprise the other 55%, you'll really be amazed.  23% of the daily tasks were related to e-mail and 13% were related to tracking their multiple tasks.  That's 36% of time spent managing email and tasks!  The remainder of the tasks were pretty evenly split between phone calls (8%), meetings (6%), and personal time (5%). 

I have personally fallen prey to this same pattern, especially with regard to emails.  I've tried several solutions to the issue including e-mail free Fridays, closing Outlook, disabling my IM client, turning off my cell phone, etc.  They've all been somewhat effective in creating more focus on my work.  However, the most effective solution I have found to my email "problem" came from Tim Ferriss' book The 4-Hour Work Week.  It's very simple.  Check your email twice a day.  I check mine at around noon and 4:00 (I don't check it first thing in the morning).  If you're going to do this, set up an email auto-response in your email client that says something like mine does (thanks to Tim for the "template"):

"Due to my high current workload, I am checking and responding to my e-mails twice a day at 12:00 P.M. MST and 4:00 MST.  If you have an urgent request that cannot wait until those times, please call me on my office phone at (123) 987-6543. Thank you for understanding this move to more efficiency and effectiveness.  It helps me accomplish more to serve you better."

It sounds a bit extreme, and I received more than my share of concerned comments when I first implemented my lean e-mail diet plan, but over time it worked.  You may not be able to use this idea, but the general advice I'm trying to get out there is, don't rely on technology to manage your multi-tasking.  It never works.  Instead, focus on managing those technologies so that they don't interfere with your effectiveness and efficiency.

I was recently reading a short story by Jorge Luis Borges called "Funes the Memorius". It’s a story about a man with the strange inability to forget.  He remembers every detail in his life, but he can't distinguish between the trivial and the important.  He can't prioritize and he can't generalize. This made me think about product owners I’ve worked with in the past. They could not distinguish between the trivial and the important. They could not (or would not) prioritize or generalize.

I have worked with product owners in the past that considered everything a priority. That’s not reality and it certainly doesn’t help the development team focus on delivering valuable functionality quickly. So, how do we deal with a product owner that can’t make these distinctions? How do we help them understand their own priorities? It’s a tricky proposition, especially in the consulting world. It’s hard to tell a client that something they want isn’t important or isn’t of high value. But, you’ll run the risk of having a dissatisfied customer if you simply go along with the “everything is a priority” mode of thinking.

Here’s some practical advice to help you help your product owners prioritize. First and foremost, understand that there is no exact science to prioritizing. With that caveat, one of the techniques we have used that seems to be effective is an adaptation of Karl Weigers’ benefit-penalty prioritization method.  We combine this with a version of the planning poker game and call it "prioritization poker".  Using this technique, we ask our product owner and other stakeholders to walk through a list of established user stories. We then ask them to estimate the benefit that the user story will provide on a scale of 1 to 9 (1 being of no real benefit and 9 being the highest benefit). We then do the same thing again, except we have the product owner and stakeholders assign an estimate of the penalty for NOT implementing the user story, again on a scale of 1-9 (1 being of no penalty and 9 being the largest penalty).

We then add the numbers together to get a total value for the user story. Lower total value numbers are great indicators of what Wiegers calls “gold plating”…you know, those 65% of requirements that are rarely or never used when an application is complete. To understand how the user stories relate to each other in a real prioritization scheme, we add all of the total values for the user stories to come up with a total value for the entire application. We then divide the user story value by the total value to arrive at a value percent. We then sort the user stories by the value percent to identify the most valuable user stories to be developed. In table form it looks something like this:

Well, another turn of the calendar page and it's 2008 already.  I wanted to extend my thanks once again to all of you who have supported and encouraged me in the past year.  I'm very excited about the New Year as we have many things happening here at Data Transfer Solutions and in the broader agile community.  First, a quick update on our office build out.  We've moved our development team out of my living room and are currently in our temporary digs until our future office is done being built out.  So far, we're loving the dev rigs we've built out (many thanks to Scott Hanselman and Jeff Atwood for the Ultimate PC build out specs) and the office space is bright, cheery and conducive to an agile team. Check out the new setup below:

Our new space is currently in the design phase and we are working with some great architects out of Boulder, Colorado (Wolfe Lyon Architects).  Our new office will be built using renewable resources and Green energy and IT practices.  It is also being designed around an agile philosophy and will feature open development spaces, lots of windows, glass partitions where needed, a multi-purpose conference room, and even a place for us to store our bikes inside!  The developer desks will be self-contained and set on wheels to facilitate pair programming and a variable configuration of the developer work area.  We're very excited and are looking forward to a move in date around March 1. We'll host an open house sometime after that, so be on the lookout for invites!

Another thing we're excited about for 2008 is the enterprise adoption of agile practices at Data Transfer Solutions.  We'll be working hard to introduce the rest of the DTS organization to agile practices.  I'll keep you abreast of our progress here on my blog.  Hopefully, we'll find some good knowledge to pass on to you as we move through our agile transition. 

In addition to adopting agile practices, DTS will also be providing agile coaching, consulting, and training starting in 2008.  We are actively working with our business partners to develop GIS specific agile training materials, as well as honing our own coaching skills to help others successfully adopt and refine their agile practices.

I'll also be working hard to provide new and interesting content for this blog.  In 2008, GeoScrum will feature two new interview series: Agile Minds and The Agile World.  Agile Minds will feature a series of interviews with today's top thought leaders in the agile movement including Mary Poppendieck, Andy Hunt, Esther Derby, James Coplien, Johanna Rothman, Jutta Eckstein, Mike Cohn, Ryan Martens, Jean Tabaka, Oksana Udovitska and many others.  The Agile World will feature a series of interviews with GIS developers, managers, and industry leaders about agile practices and agile adoption in the GIS world.

Dave Bouwman and I have also been busy being interviewed as well.  We've recently completed several interviews speaking about agile adoption at DTS, agile tooling, agile contracting, and agile practices in the GIS world.  As these become available on line, I'll post links to them here on GeoScrum.  The first interview was just released today.  It is on agile tooling and is available online now at TechTarget.

Finally, the Agilistas group on LinkedIn is currently up to 234 members. We will continue to grow this group and have plans to release an Agilistas website sometime this month, so stay tuned for details.  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.

So here's to a happy, healthy, and agile 2008!