In our quest to make our new office build-out as Green as possible, our team took a field trip to the New Belgium Brewing Company offices here in Ft. Collins (luckily for us it's just down the road from our new office!). For those of you not familiar with New Belgium, they are a nationally recognized leader in sustainable industry.  In fact, NBC Nightly News did a story on New Belgium's sustainable approach to business not too long ago.

We were very fortunate to have Matt and Penelope Gilliland give us a tour of New Belgium's office space and brewing operation.  The office spaces at New Belgium contain so many materials that are either recycled, re-used, re-purposed, or made from renewable resources that it's almost overwhelming.  Here are just some of the green office solutions we got to see:

• Desks made from former bowling alley floors and Fed-Ex shipping tubes
• Conference tables made from recycled keg caps
• Marmoleum tables from Forbo
• Sound dampening wall and ceiling panels made of dried compressed grasses
• Recycled carpeting from Flor
• Bamboo flooring
• Chairs and stools made of re-purposed bicycle components
• White boards made from recycled fiberglass
• Recycled sheet metal and magnet bulletin boards

Aside from the office materials, the brewing process is incredibly green as well.  They have truly gone beyond just recycling and are actively closing the loop on waste in their operation.  New Belgium has its own onsite process water treatment facility. This allows them to clean the water used for brewing and other purposes throughout the facility.  In a series of ponds, bacteria feed on the organic waste in the process water and clean it.  A byproduct of this process is the production of methane. New Belgium captures this methane and pipes it back into their building where it fires a combined heat and power engine that produces both electrical and thermal energy. This powers about 10-15% of the brewery and closes the waste loop by turning a potential wastestream into a useful commodity.

In addition to the methane power they generate, New Belgium buys 100% of the rest of it's electric power from Fort Collins Utilities as wind power.  They actively work to reduce their power consumption by using plenty of windows, skylights, and sun tubes for natural lighting.  When lighting is needed, it appeared that they had motion sensors on many of their lights to turn them on automatically only when needed.  To reduce their power load for cooling their beers, they use large induction fans to pull in the cool Ft. Collins air in the winter. 

All in all, we were absolutely impressed and amazed at the effort New Belgium has made to become a leader in sustainable business practices.  I can write a ton more here about their sustainable practices and how well New Belgium treats their employees (free bikes after a year, a trip to Belgium after 5 years!!!) but I'll try to keep this relatively short.  We didn't get a chance to speak with their IT folks about what they're doing to reduce their impact, but I plan to follow up in the future to see if we can get any ideas on that front as well.  And yes, we had a great time...and drank some beer at the end!  Here are a few shots of the team checking out the brewery.

Mike Juniper, Vish, Jeff Germain, me, and Dave Bouwman in the brewhouse

Dave nearly took this cask of beer home with him!!!

Talking sustainable industry (and beer) with Matt Gilliland of New Belgium (second from left)

Matt Gilliland demos the cool touch screen process controller.  From this single panel, any aspect of the brewing, fermentation, delivery, and storage can be controlled.  Talk about the killer app...and the killer job.  We were all a bit jealous of Matt!!!

The obligatory beer tasting with Mike, Matt, and Dave.  The barstools are made from old bicycle rims and assorted bicycle parts.

It looks like agile practices in the GIS world are about to go mainstream.  ESRI, the industry leader is GIS software, has recently hired Dirk Gorter, formerly of Symantec Corporation, as a member of their senior corporate management team in the newly created position of director of product management. His charter is to implement new processes that will help ESRI create innovative GIS software products that integrate into the wider business IT solution.

In the ESRI press release, Gorter commented that "GIS technology is increasingly being integrated into mainstream business operations within an enterprise-wide IT strategy. This new wave of users have requirements that can only be met by innovative software designs. 

The press release continues saying "Because of his wide experience in both medium and large software companies, Gorter's focus is on implementing a product management process that is similar to the agile product development process commonly used by software development teams. In this process, the initial steps used to achieve a result are analyzed, expanded, and reemployed for successive iterations."

Gorter said "I will be employing a similar process here at ESRI. By using agile product management methods, we can implement a process that is very effective in understanding market needs and defining product requirements. The results will be products with new capabilities that can help GIS departments transform to a more pivotal role within their organization and better meet the expanding needs of their client base."

I think this is incredible news for the GIS industry.  Both Dave Bouwman and I have written posts asking when the GIS community will start realizing the benefits of agile practices.  I believe that with ESRI taking such a definitive stance in favor of implementing agile practices, that this could be the impetus the GIS world has been waiting for.  If the market leader in GIS software is going agile, hopefully the rest of the GIS market will follow their lead.  I am very excited about the future of GIS development and ESRI's agile adoption.  I'm hoping it truly brings GIS development into the mainstream of agile software development.

Rachel Weston and I have have started a new hive on Agile Commons called Agile Contracting.  It's a dedicated space for the agile community to discuss and share ideas about agile contracting in a non-agile world. 

We'll also be organizing an Agile Contracting discussion at the Agile Development Practices Conference in Orlando, FL, December 3-6.  If you're interested, please contact Rachel or myself as we are trying to organize this discussion as one of the Open Space sessions on Thursday, December 6.

I'm probably not the first one to post this, but Scott Adams did a Dilbert strip today about agile that's pretty humorous.  Check it out:

For Immediate Release
Date: November 19, 2007
Contact: Allen Ibaugh, President and CEO, aibaugh@edats.com

 Data Transfer Solutions (DTS) is pleased to announce the opening of its newest regional office in Fort Collins, Colorado. The new Fort Collins office will focus on GIS Application Development as well as Agile Consulting and Coaching. Key staff in the Fort Collins office are Chris Spagnuolo (Senior Project Manager and Office Manager), Dave Bouwman (Senior GIS Software Architect), Jeff Germain (GIS Software Engineer), U.G. Viswanath (GIS Software Engineer), and Mike Juniper (GIS Software Engineer), all of whom were formerly with the Sanborn Mapping Company.

The new Fort Collins development team brings an unparalleled depth of experience, know-how, drive, and excitement to our growing GIS Application Development Team. They also bring in-depth first-hand knowledge of Agile practices and the Scrum methodology to our organization.

About Data Transfer Solutions

In 2004, DTS was started to provide clients with a variety of capabilities: GIS and Internet Mapping, Web and Database applications, Asset Management, and Video and Multimedia production. The core team members at the Orlando office have worked together for over 8 years and have developed a trust and rapport which guides the growth of the company and our interaction with clients.

The company has expanded to include regional offices in: Charlotte, North Carolina; Denver, Colorado; San Antonio, Texas; St. Louis, Missouri; and Jacksonville, Naples, and Tampa, Florida.

We love a challenge and often come up with unique solutions as we work with the client; an example would be the straight-line diagramming tool we have designed for the Colorado Department of Transportation.

Our uniquely diversified team offers solutions that can encompass the full depth and breadth of a project. We can help you expand your vision of a project, get you up to date with the latest technology, and add a creative spark to any endeavor.

Orlando Headquarters
Data Transfer Solutions
4037 Avalon Park Blvd East
Orlando, FL 32828

Phone: 407-382-5222
Fax: 407-382-5420

Website: http://www.edats.com/
General info: general@edats.com
Sales: sales@edats.com
Careers: careers@edats.com

I've recently started a new group on LinkedIn called Agilistas.  The Agilistas group is a collaborative community dedicated to evangelizing and advancing Agile practices in software and product development.  If you'd like to join the group, click here or copy and paste this link http://www.linkedin.com/e/gis/43421/24A5E7397137 in your browser.  If you can't access this page, feel free to e-mail me and request to be added to the Agilistas group.

If you aren't familiar with LinkedIn, here's some info about it:

LinkedIn is an online network of more than 16 million experienced professionals from around the world, representing 150 industries.  LinkedIn is free to join

When you join, you create a profile that summarizes your professional accomplishments. Your profile helps you find and be found by former colleagues, clients, and partners. You can add more connections by inviting trusted contacts to join LinkedIn and connect to you.

Your network consists of your connections, your connections’ connections, and the people they know, linking you to thousands of qualified professionals.

Through your network you can:

• Find potential clients, service providers, subject experts, and partners who come recommended
• Be found for business opportunities
• Search for great jobs
• Discover inside connections that can help you land jobs and close deals
• Post and distribute job listings
• Find high-quality passive candidates
• Get introduced to other professionals through the people you know

OK, OK...yes it's cliche, but we're realizing already that it really isn't easy being Green.  We decided that we'd build our own developer rigs to save money and to build some killer rigs at the same time.  What we didn't plan on was the sheer amount of packaging that would accompany our new equipment.  The packaging you see in the photo of Mike Juniper below is from the components of only one machine.  Multiply that by five machines for our small team.  That's a lot of waste for a bunch of electronics that fit neatly inside a 2-cubic foot case when assembled, don't you think?

We tried to recycle everything we possibly could from this mountain of packaging.  To our dismay, we discovered that our local recycling center doesn't recycle styrofoam so we're trying to find someplace to take it (if you're from Northern Colorado and have suggestions, please pass them along).  But, we did recycle all of our cardboard, paper, and plastics.  It would be even nicer if we didn't have to recycle at all, because as William McDounough and Michael Braungart point out in their book Cradle to Cradle, recycling is slow motion waste.  But for now, we feel that at least we're not adding to another landfill pile.

And yes, we've been making sure we turn off our machines every day.  And since we're working from my home right now, we're employing my 1-1/2 year old son to to turn off all of our monitors every night.  You can't get them started too young these days!

Dave Bouwman and I had lunch with some friends from another GIS company yesterday.  They wanted to talk to us about our experiences with agile and Scrum.  They're very interested in implementing Scrum as their "methodology" of choice for their development teams.  But, they kept alluding to the fact that they needed to come up with an "official" date to get started.  The conversation continued and I finally asked my burning question "So, what's holding you guys back from getting started?"

The answer was that they needed more time to get their backlog together and have it be adequately defined.  I thought about that for a while and made a few suggestions that I think any teams can use to quickly get started using Scrum.  First and foremost, I think teams shouldn't worry about making their Scrum start "official" or sanctioned or even extremely well defined.  Many very successful Scrum teams started completely under the radar by implementing some simple elements of Scrum that made them more effective and efficient.  I also think teams shouldn't worry about getting it "right" the first time.  Remember the Scrum mantra "Inspect and Adapt"?  If you start off and don't get it right, inspect, adapt, and keep moving forward.

OK, so what to do about your first backlog, right?  If you really want to get started quickly, assemble enough of a backlog for maybe 2 sprints.  Get your Team started on those backlog items, while the ScrumMaster and Product Owner hash out the details for a more comprehensive backlog.  If you'd like to do more planning and feel better about your backlog, build a backlog for a single release.  Let your Team get started on that backlog while again, the ScrumMaster and Product Owner build out more release backlog items for future releases.  Finally, if you really want to assemble a detailed backlog before your Team starts working, consider a Sprint Zero.  Make Sprint Zero a one-week Sprint where the ScrumMaster, the Product Owner, and the Team work on assembling a detailed backlog.  You can also use Sprint Zero to put anything else in place that you think you need to support your Scrum implementation.

When you're assembling your first backlogs, keep in mind that you don't need to put excruciating amounts of detail into your user stories that are farther down the line.  The level of detail in your user stories should be proportionate to how close you are to actually working on the story in question.  The further in the future the user story is the less detail it should contain.  Remember that one of the benefits of Scrum is the reduction of time wasted on requirements that may not ever be implemented.  It is more likely that a user story that is one year out will not be implemented than one that is just two weeks away.

So, what are you waiting for?  Pick a project, big or small, get some quick backlogs together, and start scrumming today.  It's never too soon. 

One of the key tenets of Scrum is the team's absolute, uninterrupted focus on the current sprint tasks.  One of the key responsibilities of the ScrumMaster is to ensure this focus and to fend off unnecessary interruptions.  It sounds easier than it is.  As a ScrumMaster, I have had the distinction of experiencing first hand the difficulty of defending our team's focus during a sprint. 

Case in point: Our team was working on a very focused and successful sprint when we were approached by a former colleague.  He wanted us to begin working on an internal development project immediately and stressed that it was of ultimate importance to the organization.  We would need to cancel our current sprint to accommodate his request.  After a bit of probing about the "importance" of this project, it became very clear that this wasn't as high of a priority as he thought it was.  In addition, I had previous experiences with said colleague and knew that his tendency was to focus too much on relatively unimportant tasks. 

After some deliberation, I made the decision as ScrumMaster to tell him that we would not be canceling our current sprint to work on his request.  Instead, we would prioritize his request in our backlog and get to it in our next sprint.  I assured him that the two developers that would work on his request would be 100% committed to his tasks during the two-week sprint.  His tasks would receive the same uninterrupted focus as our present tasks were enjoying.  After explaining this to him, he acquiesced and accepted a delayed start for his tasks.

We did indeed work on and complete his tasks during our next two-week iteration.  In fact, when we were done with our sprint, he was surprised to find that all of his functional requests had been completed (of course, it was no surprise to our committed team).  At the conclusion of our sprint we found out that his team was not ready to implement our new functionality.  Neither the servers we needed nor the necessary software infrastructure was available to deploy the application.  Nearly 3 months later, his non-agile team was finally ready to deploy our functionality.  So, his high priority request really turned out to be very low priority in the end.

The moral of this little story is that ScrumMasters need to know when to say "No."  Sometimes, there may be a very valid reason to cancel your sprint to address very high priority requests.  But, ScrumMasters need to use a lot of discretion and ensure the validity of these "high" priorities.  It is extremely important not to interrupt your teams for just anything.  In this case, had we interrupted our Sprint to fulfill this request, we would have shifted our focus from a highly productive Sprint to address a low priority need.  In the end, we did the right thing by saying "No."  We completed our sprint very successfully and satisfied our paying client and our team remained focused and effective. 

Well folks, we did it.  We sprinted out the door, had a few beers, and showed up for our new jobs this morning.  Well, sort of...we're working on getting our office space later this month, so we actually showed up at...well, my house.  But it was very cool.  We spent the day building out our developer boxes and doing plenty of smiling and laughing.  Aside from our team, we had plenty of help from my four year old son and our dog Kahlua.  If you're at all interested in what we're building, we're using Scott Hanselman and Jeff Atwood's Ultimate PC setup.  Check out both of their blogs to find out what and how we're actually building them.  Dave Bouwman will also more than likely be giving a more technical blow-by-blow of our assembly on his blog (update: here's Dave's post on the dev rigs we put together).

Anyway, we'll be spending the next few days doing some more set up and getting up to speed on our new project load.  We already have plenty of projects lined up to keep us very busy.  We'll of course be using Scrum and agile practices to guide our development process.  We'll be using Rally once again to help manage our workflow, backlogs, defects, and tests.  We'll also be working very hard to keep our entire buildout (both IT and brick-and-mortar office) as Green as we possibly can.  Stay tuned for more on our team's transition to a new way of working agile.

I was reading an article by Garr Reynolds a few days ago.  He was talking about photos he had seen from the Cassini mission to Saturn.  One photo was of Saturn, looking back towards Earth.  Earth was this tiny little dot way off in the distance.  Garr made a statement that really resonated with me, especially in light of events which I will describe in a moment.  He said, "We don't usually think of our world from another perspective." 

Several weeks ago, I decided that I needed to look at my small world from another perspective.  I had decided that my attachment to my organization was becoming something that I needed to seriously reconsider.  I guess you can say I decided to inspect and adapt at a very extreme level.  I decided that what seemed to be working were our agile practices and our team. What didn’t seem to be working, from an agile perspective, was our organizational culture.  As it turns out, the rest of the development team was thinking the same thing.  In the end, we were all offered positions with a new organization and made the very scary decision to sever our attachment to our organization. 

Our organization responded very maturely by keeping all of us on for two weeks to wisely assemble a transition plan for our projects, etc.  To ensure that we provided our organization with the most value for the time we would invest over the next two weeks, we did what any Scrum team would do...we built a backlog and planned a Sprint.  The lead for the Transition Team acted as our Product Owner and did a great job prioritizing the backlog with us.  We held daily Scrums to keep everyone apprised of our progress and any impediments to getting what they needed.  The process provided complete transparency and visibility into our transition.  While our final Sprint ensured that our team acted as professionally as possible throughout the transition, it also provided an acceptance mechanism for our organization to document that we delivered everything they needed to be successful in the future.  In the end we completed all of our Sprint tasks and got acceptance on all of them as well (check our last Sprint burndown chart below).

Although it was an awkward situation, we did it.  We had closed out our final days at our organization doing the most valuable work we could do using the agile practices that we are completely committed to.  So, there you have it: The end of the first chapter of our team's agile journey.  Our agile journey will continue somewhere else now, still as a close-knit team...ever agile!

It's not often that I look to military commanders for leadership inspiration.  I find that most military leadership takes the form of traditional command and control.  It's even less often that I'd consider military examples to illustrate effective leadership models for ScrumMasters and agile "leaders".  However, I was reading about General Matthew Ridgway today, and it occurred to me that he could be viewed as the military equivalent of a servant leader.  Ridgway is widely regarded as the man responsible for salvaging any hope for United Nations troops in the Korean War in 1950. 

What was so interesting about Ridgway was his vision of leadership.  At the time, the model of military leadership in Korea was General Douglas MacArthur.  MacArthur believed that great commanders could impose their will on their troops, and because of the greatness of the commander, the troops would be victorious.  But, by 1950, the troops had lost morale and were losing the war under MacArthur's command.  When Ridgway arrived, his leadership model was far more egalitarian.  He wanted his men to find something special within themselves that made them effective as soldiers.  He felt that it would be the ability of the troops to find ways to be better soldiers that would make them effective, not their faith in him.  He truly believed that it was his job to help his men find that something within to make them the best that they can be.

So, how does any of this relate to Scrum and agile?  While I personally find Ridgway's end goal distasteful, his leadership model as mentor and teacher, not commander, is a good model for agile leaders.  As ScrumMasters and agile leaders, it is not our job to mandate or command our teams to perform work.  It's been demonstrated time and again that this is not effective, and can even be detrimental to otherwise productive teams.  Instead, it is our job to help our teams become the best that they can be.  We are there to help them find the qualities and practices that suit them best as a team.  We are not responsible for solving our team's problems.  But we are responsible for teaching them how to solve their problems.  We're responsible for giving them whatever they need to become self-managing, effective teams.  We need to become true servant leaders.

In my never ending search for the holy grail of agility, the agile contract, I came across a post today from Mishkin Berteig on Agile Advice loaded with links to more agile contracting ideas.  The post includes links to contract presentations, data, and posts from Mary and Tom Poppendieck, Alistair Cockburn, and Martin Fowler just to name a few.  Definitely worth a read.  Check out the post at Agile Advice when you get a chance.

My good friend and co-worker Vish recently wrote a short blog post about some cool and funny charts from Kathy Sierra's website Creating Passionate Users. Kathy seems to have an uncanny knack for capturing the essence of a problem or issue and creating some pretty cool and simple charts to illustrate her point. One that I find most interesting is her "How to Be an Expert" chart.

`

This chart doesn't need a whole lot of explanation (and that's why I like it so much). I think this chart can apply to every aspect of your life if you want it to. However, I see it as particularly useful for development teams on their agile journeys. When our team first started out, we hit home runs on our first two Sprints. We delivered everything we committed to. But on our third Sprint, we missed the boat big time! We could easily have said "We suck at this! We give up!" We could have become frustrated, dropped out and decided, we can't do this agile stuff, it just doesn't work. In that case, we'd have fallen below the Suck Threshold and probably have gone back to doing things the way we use to do them...waterfall.

However, after our third Sprint, we had a very thorough Sprint Retrospective to find out what was different. What did we do wrong in Sprint 3? What did we do right in Sprints 1 and 2? What did we need to change? Inspect and adapt...always. So, with our new found knowledge, we went on to a relatively successful Sprint 4. We continued on for another 6 Sprints, pretty much hitting our mark, but missing slightly on occasion. At this point, we could very easily have decided "Now that we can do it, we'll just keep doing it the same way." We'd have risen above the Suck Threshold and we'd probably keep completing our Sprints with relative success. But, if you've read my posts before, you know that our team doesn't particularly like settling for mediocrity. I firmly believe, and so does our team, that we should always be striving to become better at what we do.

As a relatively young agile team, we're still learning a lot about each other and how we work. But I love the fact that our team is constantly trying to push us to that next level...as a team. We're always asking the question "Is there a better way to do this?” We are constantly inspecting and adapting. I think we're getting closer to that Kicking Ass Threshold and becoming experts. But if I know our team, even when we cross that line, we'll still be asking ourselves, "Can we do this better?" and I think we'll always answer with a resounding "Yes!".

Last night, I had the pleasure of speaking about our team's agile success at Rally Software's Open House Event.  I am very grateful to Ryan Martens and Zach Nies for inviting me to speak at their event.  As impressed as I am with the services that Rally provides for agile teams, I was even more impressed and inspired when I heard Ryan (Rally's CTO) speak about their commitment to the greening of the IT industry.  Rally is completely committed to reducing their carbon footprint, closing the waste loop, and promoting sustainable or restorative practices in the IT world.  I commend them for their internal efforts and for evangelizing green IT practices to others in the industry.

I wholeheartedly agree with Ryan's stance on Green IT and believe that if all of us in the IT world, from the smallest one man shop to the largest of the uber corporations pitch in, we can make a difference and begin to reverse to devastating effects of global warming.  Our five person development team  will be designing a new office space here in Fort Collins, Colorado in the coming weeks and we plan to use as many green resources as we possibly can.  However, it doesn't take a complete office redesign to begin reducing your team's carbon footprint.  For ideas on what you can do to start engaging in sustainable and restorative IT practices, check out Ryan's blog and resources at his Greening of the Software and High Tech Industry hive in Agile Commons.  I've said it before, I'm a true believer that we can do anything if we put our minds to it, so please join the new industrial revolution and help do your part to reduce waste in the IT industry.

Here are some resources to check out to get you on your way to green IT practices:

Natural Capitalism by Paul Hawken, Amory Lovins, and L. Hunter Lovins

Cradle to Cradle by William McDounough and Michael Braungart