Happy Halloween!  After a full night of Trick-or-Treating with our kids, I thought I'd share a grab bag of Scrum tools with my fellow Scrummers.  I've said it before, I'm not a huge fan of tools, but sometimes they can be helpful.  Scrum tools run the gamut, from simple index cards to full blown enterprise management solutions.  Here's a list of Scrum tools our team has used, from basic to elegant.  We have found success with all of them.  We've outgrown some, but I think they are all useful and effective in one way or another.

Backlog Index Cards: You can use simple index cards and a small box to write your user stories on. Use 3X5 cards to keep your user stories short and to the point.  Store them in a simple index card box, arranged by priority.  During your sprint planning sessions, re-prioritize your cards if you need to. Move the cards you select for your sprint backlog into a sprint box (or better yet a task board).  Voila, instant backlog management tool...cost, about $3.29 for 500 user stories!!!

Sprint Task Boards: Create a simple board to post your sprint backlog cards on (we made ours out of cork).  Divide the board into five columns: User Story, To Do, In Progress, To Verify, and Complete.  Create a set of task index cards that describe the sprint backlog tasks associated with each user story you selected for the current sprint.  Put these in the To Do column next to their associated user story.  As you progress through your Sprint backlog items, move the task index cards along the columns until you are done with all your sprint tasks.  It's a very visual way to keep track of your team's Sprint progress. Check out Mike Cohn's page on Task Boards for several examples of different task board variations. 

Planning Poker Cards: Planning poker is a method of team-based, collaborative estimating. In planning poker, each team member uses a deck of numbered cards to assign story points to each user story in the backlog.  For a detailed description of planning poker, check out PlanningPoker.com .  When our team first started playing planning poker, we used simple index cards with large hand-written numbers on them.  We now use a deck of professionally made cards that we received when we attended Mike Cohn's Agile Estimating and Planning class.  You can purchase your own planning poker decks from Crisp.  If you're not estimating with planning poker, you owe it to yourself to try it.  Plus, it's fun.  My favorite card: infinity (yes, I'm a consultant).

 

Scrum Backlog Spreadsheets: When we first started out, we used a simple spreadsheet template we found online to manage our product backlogs, and our sprint backlogs.  The more we used Scrum, the more the spreadsheet grew in complexity to include time tracking by team member & task, sprint dashboard reports, risk logs, impediment logs, and sprint retrospective notes.  As our projects became more complex, we needed to manage multiple release plans, multiple projects and multiple dispersed team members.  We tried using Microsoft SharePoint to manage our spreadsheets in a distributed environment, but it too became unmanageable. Quite simply, we reached the limit of what the spreadsheets were able to do for us.  Our scrummasters were spending far too much managing the spreadsheets.  But, for smaller projects, spreadsheets should work just fine.  Your can download our last incarnation of our Scrum spreadsheet here. 

Enterprise Scrum Software: As our spreadsheets became too unruly to manage, we evaluated several COTS products to help manage our large enterprise Scrum projects.  We ended up selecting Rally Software as it most comprehensively met our requirements.  For more about Rally, check out my post Tearing up the spreadsheets....our move to Rally Software.  We've been very happy with Rally and plan to continue using it in the future.  It's very flexible and extremely scalable.

One of the critical factors in the success of agile adoptions is the organizational culture in which agile teams function.  In his blog Agile Software Development, Dave Nicolette stated that "an agile team is most effective when it is part of an agile organizational culture".  I agree completely, but just what is an agile organizational culture anyway?  There are probably lots of different answers to this question and all may be equally valid.  But at the heart of the matter, an agile organizational culture is one that supports the freedom of agile teams to do the best work they can in their efforts to deliver quality software quickly. 

There are plenty of large companies out there practicing agile in many different forms.  They all have components of what most would consider an agile organizational culture.  I've blogged about Netflix, whose CEO describes a culture of "freedom and responsibility" within their organization.  I've also discussed the strides Microsoft has made in terms of supporting their Patterns & Practices lab in their efforts to become agile. 

Ken Schwaber points out the example of Google in his book Agile Project Management with Scrum.  Google sets aside time for Team members to pursue activities that are outside of their current Scrum Teams and that benefit the Google enterprise. Google gives team members 20% of their time to coalesce into interest groups where they can work together. This time can be spent working with peers in sustaining and enhancing their functional expertise, or researching and prototyping new ideas. Google developed Gmail this way.

An agile organizational culture has helped in successfully scaling agile practices across large distributed teams at Yahoo!.  Yahoo! is now 2 ½ years into its adoption of Scrum, and has upwards of 100 teams and 1200 people (and steadily growing) using Scrum in the US, Europe, and India. Scrum is being used successfully for projects ranging from new product development such as Yahoo! Podcasts, which was built by a distributed team split between the U.S. and India and won a Webby Award, to heavy-duty infrastructure work on Yahoo! Mail, which serves 250 million users each month around the globe. Most (but not all) of the teams using Scrum at Yahoo! are doing it by the book, with active support from inside and outside coaches.

The reason I'm listing these case studies is because they are remarkable companies, doing remarkable things by organizationally and culturally supporting agile practices.  I used them a few weeks ago at a company offsite meeting. I was trying to illustrate what agility looks like from a cultural and organizational perspective.  I was trying to demonstrate what it would take for our company to truly adopt agility and provide a supportive environment in which it could thrive.  However, a comment I received from one of my colleagues stopped me in my tracks.  "Sure it works for them," he said, "they're huge.  They can do anything they want to.  We can't do that here.  We're not Microsoft or Google!"  I was flabbergasted and didn't know how to respond at first.  I am a firm believer that you can do anything if you put your mind to it.  I feel that way personally, and I feel that organizations should think that way as well. 

I think that a fundamental failing of organizations today is a self-limiting attitude of complacency that seems to exist at many companies.  Striving for mediocrity.  "Accepting" our limitations.  "We can't do that because we're not Google".  It's easy for companies today to live in the middle ground.  Average companies, with average organizational cultures, producing average products.  As Seth Godin says, most companies "...smooth out the edges and go for the center".  I can't accept that.

My question back to the naysayers is "WHY NOT?"  Why not do something remarkable?  Why not change our organizational culture to become remarkable? Google, Microsoft, Netflix, Yahoo!... they all became successful precisely because of their ability to say "Why not?".  They became successful because they understood the value of organizational culture. They provided an atmosphere for free thought and forward progress.  The decided not to live in the corporate middle-ground.  I'm not saying that every company can do what Google, or Yahoo, or Netflix has done, but we can certainly learn from them. We can learn to change our culture to support agile teams.  We can decide to do something different...we can become agile organizations.  If one of the key criteria for the success of agile adoptions is an agile organizational culture, then I'd like to propose its antithesis: One of the main reasons for the failure of agile adoption is organizational complacency.

After writing my post about agile in the fixed-price world, I received numerous comments and e-mails about the topic.  It seems like selling agile to the customer is a very common concern amongst agile practitioners, especially in fixed-price situations.  While it seems  like no one has a real magic bullet to help us navigate the fixed-price world, there is quite the conversation going on in the agile community about this topic.  If you're interested in more opinions about selling agile to your customer, check out some of the following links:

How to Sell Agile to the Customer  A discussion thread on Facebook in the Agile and Lean Development Community group.   Also, I highly recommend joining this group if you're interested in agile practices.

Changing the Game: Making Agile the "Default Methodology" A short post by my colleague Dave Bouwman describing a company's view on presenting agile practices at a short list interview as their default methodology.  And it worked.

Winning a fixed-price RFP with an agile proposal and There is no such thing as fixed scope by Eduard Liebenberger

Fixed bids, agile projects by Oren Eini

Optional scope contracts by Kent Beck

Since this appears to be a topic of concern for most agile practitioners, I'll keep posting any new resources about this issue as I find them.  Thanks to everyone who has contributed to this growing list.

This week I was asked to give an extremely brief description of agile practices and Scrum.  I  had about 30 seconds to respond.  I think I did pretty well under pressure and came up with something along the lines of:

"It's a framework of practices...no, more like guidelines, that help us deliver useful, valuable increments of functional software to our customers on a very frequent basis, like two weeks, in a completely transparent environment.  We do it by constantly re-prioritizing requirements and reviewing our incremental progress with our customer. We also continually  inspect and adapt our development practices to increase both our efficiency and our our effectiveness."

Three sentences, 22 seconds.  Did I capture the essence of agile and Scrum?  I hope so.

Just what is the essence of Scrum anyway (and no, it's definitely not a new fragrance for agile developers).  HL Arledge took a shot at it on his blog recently.  My challenge to my fellow scrummers is this: Come up with your best description of agile practices and scrum in 3 sentences or less.  Post them in the comments section of this post.  In your post, feel free to link to your blog, your company, your product or your dog, if you'd like. Give yourself a shout-out.

The best elevator speech about agile and scrum wins a $10 gift card to Starbucks.

Earlier this year, Dave Bouwman and I took a course in Agile Estimating & Planning taught by Mike Cohn.  It was an excellent course, but I felt I needed a deeper understanding of the subject matter.  Fortunately, Mike wrote a book about the same subject (Agile Estimating & Planning) and it is an excellent primer and team reference for estimating and planning using agile practices (as the title obviously infers).

Who should read this book?  Everyone on your team should read this book. It is relevant to your developers, your ScrumMasters, your managers, and even your sales team.  If your team hasn't read this book, or at least parts of it, give it to them today.

What’s inside?  The book is broken into 7 sections. Mike starts off with a good overview of the purpose of planning, as well as an excellent account of why traditional planning methods (AKA waterfall) fail.  The solution: an Agile approach to estimating and planning. 

The next section, Estimating Size, walks us through the complex issue of how to estimate using size instead of the typical duration.  This is a critical distinction in the way Agile teams estimate their projects and Mike does a great job of walking us through the process; it includes specific techniques for estimating, as well as the distinction between estimating in story points and ideal days, and how to choose between the two.

The third part of the book is about planning for value.  This includes several chapters on how to prioritize your backlog items.  Mike describes specific prioritization considerations including thematic prioritization, financial prioritization, and desirability prioritization.  This section of the book also covers how and when to split user stories as they rise to the top of the prioritized backlog.

Section four covers the topic of scheduling.  In this section, Mike presents the essentials of release and iteration planning.  In addition, he details how to derive your team's velocity from metrics gathered on historical data.  If you don't have historical data, don't despair, after 3 or 4 iterations, you'll have a good idea of what your velocity is.  Other topics covered here include how to buffer your estimates by either feature, schedule, or a combination, as well as planning multiple-team projects.

The fifth part of the book is about how to monitor both your release and iteration plans.  It covers some of the basics such as burn-down charts, parking lot charts, iteration task boards, and how to track effort expended.

The last two sections are kind a "Why Agile Planning Works" conclusion.  It includes reasons why agile planning works as well as a case study of the planning and estimating process.

Why it’s on my bookshelf?  Since our team started using Agile practices and Scrum, one of the key questions that consistently arises in any discussion we have with our managers and other development teams is "How do you guys estimate and plan?".  Or more precisely, "Do you guys plan?".  Yes, we definitely plan.  And this book is kind of the how-to for agile estimating and planning techniques.  Our team has used many of the techniques described by Mike in this book with great success.  As a project manager, I found this book absolutely priceless.  It allowed to me to understand ways to gather meaningful (as opposed to useless) project metrics.  As we move forward developing new business using agile practices, I have gained a great deal of confidence in our ability to more accurately (not precisely) estimate our efforts.  And finally, I have referred several people to this book whenever we get the questions mentioned above.  I recently gave a presentation at a company offsite where I knew the planning question would come up. Using information gained from this book, I was easily able to show the different horizons that our agile team plans at, from the detailed iteration level all the way up to the overarching strategic level. 

If you're practicing Scrum, or any other agile methodology, you owe it to yourself and your team to check out this book.  If you're about to start practicing Scrum, do yourself a big favor and read this book first.  It'll save you a lot of trouble down the road if you start using the techniques described in this book right from the start.

Here’s the skinny on the book:

Title: Agile Estimating and Planning

Author: Mike Cohn

Year: 2005

Publisher: Prentice Hall PTR

Length: 368 pages

ISBN-10: 0131479415

ISBN-13: 978-0131479418

List price: $49.99

As part of our move to using Rally Software as our agile management tool, we asked for a trial subscription to Rally's Web Services API.  We decided to give the API a test run by integrating a defect reporting function into our custom ESRI ArcGIS application for a large enterprise project.  Mike Juniper and Jeff Germain, two of our GIS software engineers, put the API through its paces to see what it could do.  I had the chance to discuss the API with Mike and ask him 10 questions about it.  Here are Mike's answers:

1. Can you tell us a bit about yourself and your development experience?

I started learning VBA about 9 years ago as a secondary part of my job. A few years ago, programming became a more central part of my job and I switched to VB6 because we had an unused license lying around and I wanted to learn something new. About a year ago, I took my current job as a GIS Software Engineer and switched to VB.NET.

2. What is the Rally Web Services API?

It’s an API that allows you to integrate Rally components into other software systems.

3. How long have you been using the API?

I’ve just used it for a small part of one project. I’ve really just spent a total of maybe 12-16 hours figuring it out and using it in our application. I investigated the API, figured out how it worked, and put together some sample code, which I handed off to Jeff Germain. He took it and ran with it and built a framework for using it in our application. I then built the command and the UI.

4. What made you decide to use it?

We wanted to provide a way for our customer to be able to report software defects from within our custom ESRI ArcGIS application. We wanted their defect reports to integrate right into our own Rally instance and auto-populate our defect backlog.

5. Can you describe what you did with the API?

We created a command button that opens up a form, which allows the user to provide information about the defect and submit it to Rally. Here’s some sample code showing how to log into the Rally service:

Public Shared Function GetService() As Rally.RallyServiceService

' Instantiate the service

Dim rallyService As New Rally.RallyServiceService

' ===All API calls require basic authentication===

'Set the service - not necessary if you get wsdl

'''''rallyService.Url = "https://rally1.rallydev.com/slm/webservice/1.03/RallyService"

'Login to service using http basic authentication

Dim credential As New System.Net.NetworkCredential("<username", "<password>")

Dim uri As New Uri(rallyService.Url)

Dim credentials As System.Net.ICredentials = credential.GetCredential(uri, "Basic")

rallyService.Credentials = credentials

rallyService.PreAuthenticate = True

 

'Configure the service to maintain an http session cookie

rallyService.CookieContainer = New System.Net.CookieContainer

'======

Return rallyService

End Function

Here’s some code showing how to get a reference to particular project:

Public Shared Function GetProject(ByVal projectName As String, ByVal rallyService As Rally.RallyServiceService) As Rally.Project

If String.IsNullOrEmpty(projectName) Then Return Nothing

Dim project As Rally.Project = Nothing

' Get the workspace from the subscription

Dim workspace As Rally.Workspace = GetWorkspace(rallyService)

' Querying for objects directly seems to be faster in most cases

Dim queryResult As Rally.QueryResult = rallyService.query(workspace, "Project", "(Name = """ & projectName & """)", "", True, 1, 20)

If HasErrors(queryResult) Then

     Throw New Exception("Error querying for project '" & projectName & "'" & FormatWarningsErrors(queryResult))

Else

     For Each projectItem As Rally.Project In queryResult.Results

          If projectItem.Name = projectName Then

               project = projectItem

               Exit For

          End If

     Next

End If

' Return value

Return project

End Function

To create a defect, you’d do something like:

Dim defect As New Rally.Defect

' Set the properties

' Create the defect on the server

Dim createResult As Rally.CreateResult = rallyService.create(defect)

Create returns a Defect on success and an OperationResult on failure so you need to examine the returned object to see what happened.

6. Had you not use the Rally API, what were the alternatives you would have considered to achieve the same results?

At the time, we were having users submit defects to a Microsoft SharePoint portal. We probably would have continued doing that and someone would have had to manually transfer or import them into Rally.

7. How would rate the ease of use of the API?

It was really easy to use. I hadn’t really used a web service before except in a class I took a while ago. But I was able to dive right in and start using it almost immediately.

8. Did you find any difficulties or problems using the API?

One thing that tripped me up is that sometimes you’ll have a ‘shell’ object and sometimes you’ll have a ‘full’ object. It’s not always clear to me which one you’re going to get ahead of time. But if you’ve got an object and the only property that is populated is the ref property, you’ve got a shell object. You can get the full object by doing something like:

      defect = DirectCast(rallyService.read(defect), Rally.Defect)

9. How has what you built helped your Scrum team and/or your customer?

We used to have a several different ways of collecting defect reports and they weren’t integrated. Now all our defects are in one place in our Rally Software as defect backlogs related to specific releases and iterations and it’s very easy for our customer to report new defects.

10. Can you envision other potential uses of the API for your current or future projects?

I haven’t given this much thought…. The web app is so good that I would think anyone who has access to it would primarily use that. However, the web services API allowed us to only expose exactly what we wanted to our customer without using another Rally login.

Thanks to Mike Juniper for all of his great answers and insights into the Rally Web Services API.  If anyone else out there has experience with the Rally Web Services API (good or bad) we'd love to hear about what your doing with it and how it has impacted your development environment and/or your customer satisfaction.

Interested in Agile Development? Each day, Agile Daily identifies the top 15 Agile Development stories and blogs of the day.  It's pretty new, but it looks interesting.  Kind of like technorati for Agile development stories.

Here are a few other agile development aggregators that I frequent:

• Agile Movement
• Agile Planet

If you know of others that are worthwhile, please feel free to share in the comments section of this post.

 I was reading an interesting story about the famed American financier, banker, and philanthropist J.P. Morgan today.  It went something like this:

A man approached J.P. Morgan, held up an envelope, and said, “Sir, in my hand I hold a guaranteed formula for success, which I will gladly sell to you for $25,000.” J.P. Morgan replied, “I do not know what is in the envelope, however if you show me, and I like it, I give you my word as a gentleman that I will pay you what you ask.” The man agreed to the terms, and handed over the envelope. J.P. Morgan opened it, and extracted a single sheet of paper. He gave it one look, then handed the piece of paper back to the man and promptly paid him the agreed-upon $25,000.  Here's what was on the paper:

1. Every morning, write a list of the things that need to be done that day.
2. Do them.

Remember this simple story when you look at your backlogs and have your daily scrum.  Simple but effective, make a list...do it!  I think J.P. Morgan would have loved Scrum. 

Being in the GIS industry, I'd be remiss if, once in a while, I didn't write a post about cool stuff  in the geospatial arena.  Over the past few years, I've watched the incredible shift from desktop GIS to web-based mapping engines like Google Maps and numerous others.  It's so exciting for me to see a larger audience actively engaging in geospatial awareness at a level most GIS professionals only dreamed of just a few years ago.  So, I wanted to create a quick list of my favorite Google Maps Mashups and share them with you.  Here are the top 10 in no particular order:

1. Map My Ride:Combines my two favorite passions, Maps and Cycling.  If you're into running, check out Map My Run as well.
2. Runstoppable:Combines my two second favorite passions, Maps and Running
3. WikiMapia: The user community can enter info about different places.  I love the whole Wiki concept.  Combining it with geography is awesome
4. FlickrVision: Combines two of my favorite sites, Flickr and Google Maps 
5. AP News: Recent AP News headlines on a map showing where the story is from.  Maybe Miss Teen South Carolina could find out where "The Iraq" is now.
6. Wines and Times: Find wineries and wine events anywhere in the U.S.  Great, easy to use interface.  If you prefer beer, check out Beer Coastr.
7. Platial: A great social mapping site
8. Flight Tracker: Real time flight status and location of any commercial flight.  Geeky...not sure how useful it is.  But cool.
9. The Great Whale Trail Map: Follows the migration of humpback whales.  Nothing too gee-whiz about the site, but I love humpback whales and think this site helps raise public awareness about the unfortunate whaling that still occurs in the Southern Ocean Whale Sanctuary.
10. MapleCroft Maps:  Awareness building via visual data representation. What is really cool about their maps, besides the tremendous breadth of issues they cover, are the additional resources linked to the map.  Includes more than 30 topical maps on various issues such as carbon resources, climate change, corporate governance, greenhouse gas emissions, natural disasters, pandemics, renewable energy use, aid, child labour, digital inclusion, displacement, education, HIV/AIDS, landmine risk, malaria, military expenditure, political risk, poverty, tuberculosis and water.  Simply amazing!  (Saved the best for last).

If you have a favorite Google mashup (or any web mapping site) I'd love to hear about it.

A new site called Agile Support was launched today.  This is a site for individuals to discuss agile methods, for downloads of various resources, and, if you register, to host blogs and other content development by individuals wishing to do so in an online community setting.

From the Agile Support site:

Agile methods are simple to understand, but difficult to practice and perfect. At Agile Support, we provide an open public forum for practitioners, experts, coaches, academics and newbies to all learn from each other. We also provide for-pay and invitation-only private areas for discussions, downloads, tools, and other types of collaboration and support.

OK folks, I've done some banging around and received some excellent links from others about agile practices and fixed-price contracts.  Looks like I'm not the only one asking this question.  Unfortunately, there doesn't seem to be too much good news out there, but here are some links to other articles on the topic:

The Dire Consequences of Fixed-Price Contracts on Dr. Dobb's by Scott Ambler

Fixed Price, Fixed Date Contracts at Engage by Ken Schwaber

Agile Fixed Price Contracting on InfoQ by Deborah Hartman

Fixed Price Contract & Agile Software Development: an "experience in process" report by Christine Moore of Caribou Lake Software

Why Fixed Bids are Bad for Clients on Scrum Alliance by Andy Brandt

Agile Fixed Price Projects Part 1: The Price is Right by Pascal Van Cauwenberghe of Nayima

Agile Fixed Price Projects Part 2: Do you want agility with that? by Pascal Van Cauwenberghe of Nayima

The Illusion of Fixed-Price Contracts by Simon Baker on Agile in Action

More on Fixed Price Agile on The Webfarm Blogs by Paul Webb

I'm sure there are plenty more out there as well.  If you have some good links about this topic, please feel free to post a comment with the link.

This week I had to deliver a talk about Enterprise Scrum at a corporate offsite.  We were trying to sell Scrum to our entire organization.  After the presentation, the questions starting flowing.  Most, I could easily answer.  However, the tricky question of how to work a fixed-price fixed-date contract in an agile manner came up. 

Scott Ambler had a good post on this topic and he states that:

"Fixed-price projects are a common practice in IT, either as the result of a fixed-cost competitive bid or as the result of budgeting pressures on internal software development projects.  Organizations often prefer fixed-price projects in an attempt to decrease their financial risk. Unfortunately, the exact opposite seems to happen in practice. Everyone seems to know this, but we somehow can't find a way to get out of this rut."

This is something I've been wrestling with for quite some time.  In fact, one of my office's main projects is a severely under-budgeted fixed-price fixed-date project and we have been struggling to manage it using Scrum.  At this point, we have forgone prioritizing the backlog with our client, because according to the contract (and our client), we have to deliver everything...therefore everything is a priority.  We also have to deliver by specific dates and with specific budgets for each release.  Essentially, we're using Scrum to manage our bi-weekly tasking, but that's about it.

What I'm wondering now is, can Scrum really work for fixed-price contracts?  I'm not sure.  In a fixed-price scenario, we'd really have no other way to work than to do heavy up front requirements analysis and design so that we can "accurately" bid the contract.  That would mean reverting to Scrum within a waterfall model (if we were to even try to do the project in an agile manner).  But then there's a Catch-22.  Every developer knows deep down that at the start of a project, there's no way to accurately estimate the duration of any development task.  The true complexity of any requirement is never really known until you start working on it.  No matter how in-depth the requirements are, there is always some ambiguity.  When a contract is fixed-price fixed-date, we go against all better judgement and provide cost estimates and delivery dates.  We revert to waterfall thinking.  And in the end, we usually go over budget, and our customers probably don't get what they really want.

So my fellow scrummers, I have three questions for you:

1. Given a project that requires you to work in a fixed-price fixed-date environment, would you take the project or not?
2. If you took the project, how would you effectively use scrum or agile practices to manage it?
3. How do we, as Scrum and agile practitioners, educate potential clients about the perils of fixed-price fixed-date contracts?

Agile practices go far beyond simply following the "rules" of Scrum.  To have agile really be successful, it takes organizational and cultural shifts that support the agile practices.  Vish, one of our developers, found this video about Microsoft's Patterns and Practices Team and how they worked within Microsoft to affect the changes necessary for agile to succeed.  The video follows Ed Jezierski and Peter Provost as they give us a tour of the working environment for their agile team.  Their work environment truly reflects and supports their agile efforts.  Granted, we don't all have the resources Microsoft has to build such nice digs, but there are lots of very good ideas in there about how agile teams work.  There is also a good section near the end of the tour where Ed and Peter discuss Microsoft's adoption of agile and the success they've been having with Scrum.  Check it out, it's well worth the 15 minutes.  Here's the link to the video: mms://wm.microsoft.com/ms/evnet/PatternsPracticesLab_Tour_s_ch9.wmv

It seems everywhere we look today in the world, there is a maze of jargon and buzzwords that can hinder the work we do.  Today, my team doesn't "have the bandwidth to work on our end-to-end scalable solution for our users".  What the heck does that mean?  I think it's manager-ese for saying that we don't have enough people to do our work this week.  We're bombarded on a daily basis with this type of jargon that doesn't do anything but make things sound more complicated than they really are.

Agile and Scrum are not immune from the jargon effect.  Sprints. Retrospectives. Burndowns.  Product  Owners.  ScrumMasters.  We have plenty of words to throw around to sound impressive.  The Scrum vocabulary may be useful in setting it apart from other agile practices (two more good buzzwords).  It may even be useful in helping communicate abstract concepts (three more) using a common lexicon.  However, we can't get too hung up on the terminology we use.  Sometimes, it seems that we get so wrapped up in using the "right" terminology, that we forget that deep down, it actually means something.  That loss of meaning gets propagated (another good one) throughout our organizations, usually in the upward direction.  The danger is that when we don't speak in simple terms and resort to using jargon, people who do not truly understand the jargon use it incorrectly.  This usually means our managers.  Case in point: About 4 years ago I worked for a manager who had no clue about GIS or software development and we all knew it.  To amuse ourselves, we'd make up acronyms and new "tech terms" that we made sure he overheard.  Believe it or not, we'd hear him using our "tech terms" in management and team meetings.  It made for good fun, but it's actually a serious problem in organizations today. 

Ultimately, it doesn't matter whether you call your remaining work your product backlog, your task list, or that bunch of stuff we need to do...it doesn't matter.  At it's heart, it's still just a list of things you and your team need to complete.  So make sure that if you're going to use jargon, you know what it means.  Better yet, try to avoid using jargon as much as possible and start speaking like a person.  It might make things simpler for everyone.   

I was reading a blog post last month by Dave Bouwman about agile adoption in the GIS industry. He posed a very good question:

"…65% of the software industry have adopted some agile techniques and 40% have adopted an agile methodology. So why are we not seeing more discussion of agile in the geospatial industry? Is the GIS industry still caught in the waterfall?"

I've been ruminating on that question for a few weeks now. Dave and I have discussed it several times with no real answer yet. Then, a few days ago I read a post by Andres on BlinkGeo that posed the question: "Does the GIS needs analysis model need to be updated?".  Another good question.  So I began thinking about why the GIS industry is having so many problems adopting agile practices in general. I was also considering Adres' question.  What does the GIS industry turn to as the authoritative needs analysis model? 

When I travel, I usually take several random books from my bookshelf to read on my trip.  This time I picked up Roger Tomlinson's book Thinking About GIS: GIS Planning for Managers. (For those of you not from the GIS world, Roger is considered to be the "father of GIS" back in the late 70's). This book is regarded in the GIS world as "the" how-to book for large-scale GIS implementations. While I was stuck in a Wilmington, NC hotel room, I thumbed through some of the pages and immediately the light went on in my head. Tomlinson's GIS Planning Methodology is a ten-stage process that essentially says we need to define all of our system requirements up front and do detailed planning before we can think about implementing a GIS. Hope you didn't miss that...TEN STAGES! Mr. Tomlinson goes on to state that "Because GIS planning is usually not a short-term effort, it typically represents a serious commitment of time and money. It can take from six months to a year to look at the overall needs of a large organization." Six months to a year....astounding! The book goes on the espouse a typical waterfall approach to GIS project planning and hardly touches on what it takes to actually implement a GIS.

Now, I respect Mr. Tomlinson because he's a legend in the GIS world.  But I have serious problems with his planning methodology. While it is very comprehensive, it takes too much time for up-front planning and leaves us without a GIS system for at least 6 months. Following this planning methodology, it would be difficult to show any value for our initial investment in GIS for quite some time.  Plans and documents do not represent value.  A working GIS, even a partially working GIS, represents value (or incremental value).  In addition, Tomlinson's approach has us spend so much time planning up-front, that changes to the plan become very expensive down the line. There is a law of diminishing returns with regard to planning. When we reach a certain point, we need to stop refining our planning and get to work. Any additional planning is wasteful. In fact, if we follow this traditional approach to planning and design, we can be assured that we will probably spend up to 50% of our project doing planning, change 35% of our requirements along the way, and using only about 35-40% of the system functionality. In his defense, Roger does say we should plan comprehensively and implement incrementally (but I’m not sure his definition of incrementally meshes with the iterative nature of agile practices).

An agile approach views requirements as inventory. If the requirements are not going to be used, the time spent planning for them is a waste. So, if we have several planning horizons (from nebulous requirements we'll consider way down the line, to fine-grained requirements we'll develop in our next iteration), we can begin delivering value from our GIS much sooner.  As we progress through our implementation, we can continue to refine the coarser requirements only if and when we are actually going to implement them.  We may find down the line that we don't need some of the coarse requirements we thought were important at the outset.  Because we used agile practices and didn't plan for them in detail , we wasted little or no time if we discard these requirements. 

I wrote about effectiveness versus efficiency in my last blog post. I want to emphasize the point that the GIS world needs to become more effective in what we produce. To do so, we need to stop relying on outdated academic texts about GIS implementations. We need to look for better ways to bring GIS development in alignment with the broader software industry. In short, we need to start employing agile practices for GIS development...and we need to do it as soon as possible. Maybe it's time for some unknowns in the GIS world to start blowing away the industry by using agile practices and making some noise. And maybe it’s time we start Re-Thinking About GIS.

I've been stuck in airports all day today between Denver and Charlotte but all has not been lost.  While waiting around for my flights, I've been reading The 4-Hour Workweek by Timothy Ferriss.  Although most of the book is dedicated to illustrating ways you can improve your work life and your personal life, one section of the book is focused on the difference between being effective and being efficient.  According to Ferriss, effectiveness is "doing the things that get you closer to your goals."  Efficiency is "performing a given task (whether important or not) in the most economical manner possible."  He asserts that "being efficient without regard to effectiveness is the default mode of the universe."

We can learn a great deal from these brief statements, especially as it relates to implementing agile practices.  Although agile practices allow us to become very efficient, we must be sure to reap the true benefit of these practices by becoming extremely effective.  Scrum, by its very nature promotes effectiveness.  When we continually prioritize backlog items at the start of each iteration, we are increasing our effectiveness.  We are continually working on the most important items that get us closer to reaching our goal.    Backlog items that are unimportant or no longer relevant are eliminated, further increasing our effectiveness.  In addition, the inspect and adapt mantra of Scrum helps us become more effective (and efficient) as well.  By constantly reflecting on our practices and adapting them as necessary, we identify our inefficiencies and eliminate them.  By the same means we discover our strengths and exploit them to become even more efficient and effective.  Ferriss sums it up best by writing "What you do is infinitely more important than how you do it.  Efficiency is still important, but it is useless unless it is applied to the right things."

Dave Bouwman sent me a great post today about Agile vs. Traditional Development Cost Models.  It seems the boys over at LosTechies.com have done some good thinking about the value vs. cost argument when it comes to agile practices in software development.  Check out the post at: http://www.lostechies.com/blogs/joe_ocampo/archive/2007/09/20/agile-vs-traditional-development-cost-models-maybe.aspx

I was about to assemble a toy monster truck we bought for our two boys today, when I noticed an amazing disclaimer on the side of the box.  "Due to continual changes to our products, the colors and specifications of our products may vary.  Product may differ from photos shown.  Allow +/- 5% variation in size due to the manufacturing process of finished products."  I had already paid for the toy and was expecting the box to contain the truck pictured on the outside.  I was pleasantly surprised to find that the colors, specifications, and size were just what I was expecting. 

However, can you imagine being the customer for a large software development project and reading a disclaimer like that in your final software documentation?  You'd already paid for the software a year earlier.  You and your development team spent 2 months uncovering what you thought were "all" of the requirements and specs for the software.  You nodded in agreement, the developers nodded in agreement.  They went off and developed your software for 10 more months.  You had a plan and knew exactly what you'd be getting next year when you opened the box, right?  Wrong! You opened the box and it didn't look anything like what you had asked for last year!

Luckily, using agile practices like Scrum, customers and product owners have a chance to continually see their software product during development at the end of every 2-4 week iteration.  Any changes to the original specification are made with complete transparency (usually by the customer or product owner themselves).  There shouldn't be any surprises at the end of a development project.  AGile customers should never have to worry about opening their box and finding a pink polka-dotted Malibu Barbie Beach Cruiser instead of a Blue Crusher monster truck.

I am an avid cyclist and a rabid cycling fan. I was looking at a photo today of Team CSC during a Team Time Trial at last year's Tour de France. It occured to me that the Team Time Trial (TTT) may be the perfect example of a cross-functional team. For those of you not familiar with the TTT, it is a bicycle race where teams of cyclists race against the clock to complete a specified race course. The TTT is usually held as a single stage of larger 2-3 week races like the Tour de France. The time for the team is based on the team's last rider to cross the finish line. Teammates work together by rotating through the lead position and resting in the draft of the other riders when they are not leading. In this way, the task of setting the pace is shared. What's amazing is that the riders on the team are usually specialists in different areas of cycling: they are climbers, sprinters, domestiques, individual time trialists, or general classification guys. But in the TTT, they put their specialties aside and all ride for one common goal: to cross the finish line with the best team time. If the slowest team member falls out of the group during the race, they wait for him, and help him get back up to speed. Once they're back together, they can achieve their maximum efficiency as a team again. The TTT team truly operates in a cross-functional manner.

One of the main downfalls of the waterfall approach to software development is it's insistence on functional specialization. In waterfall, the popular belief is that only an analyst can gather requirements, only programmers write code, only DBA's work on database problems, and only QA analysts can perform testing. This thinking leads to projects becoming stalled when a functional specialist in unavailable. Scrum is just the opposite. The focus of Scrum is on cross-functional teams. Scrum absolutely relies on each member of the Scrum team to do their share of the work. The team pulls together to accomplish one common goal. This means anyone on the team can and should work on tasks that may not be within their expertise. Usually there is someone on the team with functional expertise to lead a specific task, but anyone on the team can do the work. In Scrum, it is never an individual who is responsible for the team not finishing their work, it is the Team that did not finish their work. When the Scrum team wants to reach it's maximum efficiency, all Team members do whatever it takes to complete the work of their current Sprint. To that end, Scrum Teams need to become totally cross-functional to operate at their maximum efficiency. In that sense, it seems that cycling's TTT teams may be the ultimate cross-functional Scrum Teams.