Teams.  What are they and how do they work?  They're groups of people working together collaboratively toward a common goal.  They're held together by strong bonds of commitment, trust, and loyalty.  The stronger the bonds, the better the teams.  But sometimes, there's a hidden glue that nobody ever realizes is there.  Sometimes, that hidden glue is a single person on the team that really keeps it driving ahead.  And most of the time, nobody notices who that person is until they're not there. 

There is a team that I've talked with recently that learned this lesson first hand.  They were an 8 person team stocked with developers, testers, and UI specialists of varying skill levels.  One of the more junior developers didn't exactly have the mojo when it came to coding, but he was very instrumental in keeping the wheels turning.  He took an active role as the "semi-scrummaster" on the team because the actual scrummaster traveled a lot.  One day, their organization, in their infinite wisdom, decided that the junior developer wasn't doing enough development work according to his job description and "downsized" him.  After he left, the team noticed that they weren't accomplishing as much during their iterations and that the value they were delivering to their client had diminished somewhat.  The client wasn't as happy as they had been.  After 3 iterations of subpar performance, the team did a retrospective and after some serious soul searching, they realized that the downsized junior developer was the guy keeping the team on track and focused. He was the hidden glue. 

So, my point here is to understand that every player on a team has his or her role in keeping the team successful.  Some of those roles are obvious and readily apparent. But some are subtle, barely noticeable roles that really keep things well oiled.  Don't ignore your hidden glue. Try hard to identify it and understand what is, because once it's lost, you may not realize what a good thing you had until it's too late.

I recently had someone pose a question to me that got me thinking about the scalability of agile success.  Here was the question: "I'm part of large organization of over 1,000 people.  Our small team of 40 has been using agile with a great deal of success.  Now our company wants to me to extrapolate the successes we've enjoyed from agile (efficiency, value, profitability) to the rest of the company.  Do you think the agile success of 40 people can be extrapolated to over 1,000 people?”

It's a great question and I don't think there is an easy answer to it.  Speaking from my own personal experience, it's been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people.  There are many challenges as you scale agile up.  Agile practices depend heavily on collocated teams that are cross-functional in nature.  When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you'd like them to be.  This is just the nature of large organizations.  This can have an impact on communications and coordination of work across dispersed teams.  Another success factor that's related to this in larger organizations is the use of matrix management.  Teams in large organizations are usually composed of a mélange of team members who, because of matrix management, report to and are managed by different parts of the organization.  This can lead to the fire drill mentality and "resource ownership" issues.  This can quickly degrade the level of commitment and the quality/value of functionality that the teams deliver. 

Other obvious factors that can be relevant when scaling up are the development and testing environments.  Teams need to be able to continuously integrate their work and have a common infrastructure that supports this across a large organization.  Teams need to know quickly whether or not the work they've done is negatively impacting the rest of the codebase.  This is no small matter and can really improve or decrease the effectiveness and efficiency of agile development teams.

There are probably many more factors that are related to scaling agile up, but to me, the ones mentioned above seem critical.  Personally I don't think you can simply extrapolate the success of smaller agile adoptions to larger organization-wide adoptions.  I think that each has its own distinct set of challenges that make it difficult to draw a line and say we had X amount of success here, so that means we'll have 10X success when we scale this up.  However, that is not to say that large organizations cannot enjoy the benefits and successes agile practices offer.  They just have to approach it with a different mindset than smaller teams or organizations.  In fact, many large organizations have really recognized tremendous gains using agile practices.  If you're interested, there is a great case study available about BMC Software adopting and scaling agile practices throughout a very large organization.  It's available here.  It's well worth the read and gives some great insights into how large companies adapt to make agile work for them.

In a follow up to my recent post on Agile Adoption failures, CAI and the IT Metrics and Productivity Institute will be presenting a webinar called Top 10 Pitfall in Agile Software Development on August 21, 2008.  Here are the details:

Over the last few years, the adoption of agile methods has rapidly spread and agile methods are now state-of-the-art. Many teams, projects and even organizations around the world are using Scrum, XP, Crystal Methodologies, or other well-known or self-made agile methods.

However, not every organization and project is succeeding in making agile work.
What makes an agile project successful? And how can we recognize common pitfalls or "smells" that prevent or limit success with agile?

With her experience in helping projects all over Europe establish the agile value system, Jutta Eckstein will use this webinar to highlight recurring common pitfalls that teams often fall into when applying an agile approach.

Learning Objectives:

• How to make failure transparent,
• How to recognize typical pitfalls
• How to prevent failure,
• How to set up teams for success
• Concrete proto-patterns for success

Intended Audience:

• Project Managers
• Change agents and promoters of agile methods such as coaches, ScrumMasters, consultants
• Project managers, product managers, development team managers
• Executives
• All participants should be experienced in applying agile methods.

Click here to register for the free webinar.

For more info on other webinars in the Software Best Practices Series click here.

Lately I've been hearing feedback from lots of different people that they've "adopted" agile and it's just not working for them.  This always causes me to pause, step back and ask a few questions.  Here's the list that usually runs through my head:  How did your company adopt agile: top down mandate or grown organically?  Was your adoption done in stealth mode or full fledged "Hello world, we're going agile"? Do you have real executive support for your agile adoption? What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? Has your staff received any kind of agile training? How many projects have you run in an agile manner? How long ago did you start doing agile? 

I run through these questions because I think each one represents a potential failure point for agile adoptions.  Let's take a look at each one. 

1. How did your company adopt agile: top down mandate or grown organically?  This is really important.  In the teams I've talked to and worked with, it always seemed that agile was adopted better when it was grown organically not when it was mandated.  The mandate approach assumes command and control and never leads anywhere good.  People need to want to do agile.  So how do you get people to want to do agile?  Show them small successes.  Let a single team or a few small teams start doing agile.  Then, as they show successes and learn some of the lessons, other teams pick up on it and want to do the same.  The teams that went first, help the teams that followed adopt agile and they pass on the lessons they've learned. In other words, you can't just throw the agile switch and voila...everything is good.  Mandated adoptions often fail because there is no magic switch.  People resist change when it's mandated.  They embrace it much better when it's grown out of proven success.
2. Was your adoption done in stealth mode or full fledged "Hello world, we're going agile"?  The CEO or COO stands up and proudly announces "Hello world, we're going agile" and then thinks in the back of his mind "I hope this voodoo works".  And, because there was such a public announcement of the company's intent, there is extreme pressure to "make it work".  This pressure leads again to command and control thinking of "make this stuff work" or we're going to be embarrassed.  On the flip side, if you start in stealth mode, you work projects internally using agile practices but say nothing of it until the project is over.  When you client asks "How were you able to deliver value in a timely manner?" you can answer "With agile practices".  Because there is no external pressure to live up to some expectation, stealth agile teams have an internal commitment to making agile work for their own good without being forced to do so to meet some external expectation.  Once they gain the successes on stealth projects, they'll be more comfortable with announcing that they develop in an agile manner to the world.
3. Do you have real executive support for your agile adoption?  Lot's of executives have "heard" about agile and want to do it because everyone else is.  But, they don't really understand the level and type of commitment an organization must make to truly adopt agile.  If you haven't already noticed, one of the key things an organization needs to let go of when they adopt agile is the command and control structure.  It's a very hard hard thing for most executives to let go of, and many never fully commit to and support a more servant leader approach to management.  Failure in agile adoptions occur when lip service is paid to "supporting" agile practices, but business goes on as usual: The command and control structure remains, long winded requirements documents are requested to support the inevitable scope disagreements we'll have with our clients, deliverables-based contracts and project tracking remain, and percent complete and earned revenue calculations are the only important project metrics.  If organizations can't come around to supporting agile practices and drop their old "bad" management habits, agile adoptions are doomed to failure. 
4. What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule?  If you're going to adopt agile, you need to consider the types of projects you're going to run agile on.  That means thinking about contracting in a whole new light.  If you're trying to use agile practices on a fixed scope project, expect to fail outright.  Fixed scope is the antithesis if agility.  If you're running on a fixed-price project, better chance of success, but only if scope is not fixed.  Fix your price and your scope:  FAIL.  And fixed-schedule, another bad option.  So, if you're trying out agile on a project that has not truly been contracted to run agile, expect failure.  The answer is to work with your clients to educate them and develop agile contracts that both you and them can work with and live with.
5. Has your staff received any kind of agile training? "OK, so we're going agile.  Here's the 2-hour overview.  Go out and be agile!".  One month later: Fail.  Why?  Agile is not easy.  It sounds easy and can be explained quickly.  But, there are many subtleties and nuances to agile.  For teams to really grock the whole agile thing, you need to invest some time and money for training.  An agile team needs to learn how to plan in a whole new way, how to develop user stories, how to develop tasks, how to assess themselves and their practices.  And, they need to learn about the heart of agile: commitment.  Unless teams deeply understand what makes agile tick, they're going to have a difficult time being successful at it.  A two-hour "Welcome to Agile" powerpoint ain't gonna do the trick.  Sending teams to something like scrum master training is well worth the time and money you'll spend on it.
6. How many projects have you run in an agile manner and how long ago did you start doing agile? My advice here: give it room to breath.  It takes a few turns around the block to get agile running smoothly.  Teams need time to gel, get to understand agile and learn about themselves (see recent post on this topic).  Like I said before, there is no magic agile switch.  It takes time for agile teams to become successful.  The more time you allow it to run, the more likely it will be successful in the long run.  Too many teams hit the first agile bumps and hurdles and instead of trying to learn from them, they pull the plug and declare their adoption of agile a failure.  There are many stages an agile adoption goes through and some can be painful from many points of view.  Slow down, take a deep breath, and keep trying.

So, what should you do if your agile adoption is "failing"? Here's a hint: Agile is HARD.  Ask yourself some of the questions above and see what might be causing the failure.  I believe that too many organizations only half-heartedly adopt agile and pull the plug far too early before it has a chance to prove itself.  Give agile a try, give it some time, and think hard about the six questions posed above before you pass judgement on your agile adoption.

One of the key benefits of agile and Scrum is the growth and maturing of the teams that work together.  The longer a team works together, the more it learns about itself and its members.  The team learns what works well for them and what doesn't and they use this information to adapt their practices.  This learning is central to the continuous improvement of practices that drive the engine of great agile teams. 

However, a problem exists in many organizations (especially consulting organizations) that may denigrate the effectiveness of this core agile practice.  I'm talking about short duration development teams.  If you've worked in the consulting world, you've been there before.  Teams are assembled in a mix-n-match fashion  to tackle specific contract jobs.  Many of these jobs are short term, just a few months in duration.  Then, the team is disassembled, put back into the "resource pool" and reassigned to other jobs with new teams.  Sometimes teams get to hang together on the next job, but many times, they are separated and placed on new teams with new team members.  The problem I see with this is that these teams don't work together long enough to really learn about what's working and what's not.  They don't gain the benefit of working agile and finding ways to improve their practices.  I think that in addition to not gaining the valuable learning experiences, shorter term teams don't have the chance to really gel as a team.  By the time they become familiar enough with each other and build an good level of trust and loyalty to really make strides in improving their practices, they're torn apart and reassigned. 

My preference would be to see teams work together as cohesive units for long periods of time.  This allows the team time to grow and mature together.  It builds trust and loyalty within the team that leads to a team's commitment to building the best products and developing the best practices they can as a team.  These teams have the time to do some real learning and real improvement.  Our team here in Ft. Collins has worked both ways and I'd have to say, we've made much greater advances when we worked together as a team for longer durations than when we've been split up amongst several smaller teams for short term projects.

Well, it took longer than we expected and involved battles with contractors, landlords, and a communications company (Qwest), but we're finally in our new space.  We built it out to support our agile development style.  Basically, it's one big room for our Dev Lab, a nice conference room, two project/daily scrum rooms, and an escape pod for privacy.  Here are some pics so far.  We have a little bit left to build out, namely doors, glasswork, and cabinetry, as well as furniture, etc., but you get the picture.  I'll post more when we have the space completed.

The Conference Room looking into the dev lab.  There will be glass doors and a frosted glass whiteboard filling the gaping hole in the wall:

The Conference Room: Corks floors, Darth Vader ceiling and wired for the eventual 54" flat panel monitor on the big brown wall:

Our "Big Room":  The Dev Lab, set up for maximum collaboration

One of the Daily Stand Up rooms: We built two rooms for daily scrums, project planning meetings and reviews.  We also have a small "Escape Pod" for privacy or a place to get some peace and quiet.

Ok, I don't know about you but after hearing so much about it, I finally jumped into the Twitter pool.  Only problem is, I'm not sure if I really feel like swimming.  In case you don't know what Twitter is, here's the lowdown.  Some call it microblogging, others a social network of sorts.  Essentially, you can say whatever you want in 140 characters or less...and people can follow what you have to say via Twitter clients, RSS, SMS, etc.  Here's some of the captivating content folks were providing today on Twitter:

srdny76 I just learned I was steps away from a vegan ice cream parlor yesterday! Yay! There's a vegan ice cream parlor!

caseypatton ate some sweet, sweet moe's bbq tonight.

CheesecakeBree Tired... but I have a few things I need to do before bed. (It's not late enough for me to fall asleep anyway.)

girliegeek if your friends won't tell ya you got spinach in your teeth, WHO WILL?

Truly scintillating, I know.  But, I'm trying to figure out how useful Twitter can be beyond reporting the mundane details of your life for all the world to see.  At first I thought, maybe this is a good replacement for instant messaging.  You can type something in and instantly message, well...everyone else on Twitter (or at least those who want to follow your life).  Is this effective communication?  Not sure.  Maybe, just maybe Twitter can be put to good use after all.  Good meaning: productive, useful, not wasting your time, not tying you to technology when you can be doing something else with your time (work or dare I say, even fun stuff like going outdoors!).  Here's my list of potentially good uses for Twitter:

1. Emergency response: People can use the relatively low bandwidth messaging of Twitter to send messages to entire response teams instantaneously.  No mixed messages.  No dropped calls. Everyone on the team gets the Tweets (it's what Twitter posts are called).  Very effective, and they can be tagged with locations as well.
2. Conference back-channels: OK, so maybe not super productive, but if you're at a conference, you can provide live commentary about the speakers, their lame PowerPoints, their incorrect statements, bad haircuts...you name it.  Not only are you sharing with other conference attendees, you're sharing your commentary on the conference with others who may not have been able to attend.  Plus, it's great for adding some fun and excitement during really bad PowerPoints (it worked really well at Where 2.0 recently).
3. Task tracking: OK, not exciting, but useful...use it track your daily work tasks.  "Started working on foo functionality"..."Finished working on foo functionality".  Boring to the world, useful to you.  Plus, if you're team is all following, it provides instant status updates on your tasks...and you thought daily stand ups gave good visibility into task status!!!
4. IN/OUT of office: OK, another not real sexy use, but it's good for in/out of office status with location info.  Especially good when you're on the road. 
5. Promoting you blog posts: Slightly self serving, but effective.  You can let people know when you have a new blog post up.  Hopefully, you're blog is compelling enough to have established a good subscriber base and you don't need to resort to this tactic...but worth a try if you're trying to build your blog base.  Probably good for directing traffic to a website too. I'll test this out and let you know how many people visit this blog and our website after posting the addresses on Twitter.
6. News Reader:  Some online news sources now issue Tweets.  Good for those people who like their news items short and sweet...can you say Short Attention Span Theater? Check out CNN, BBC and many others.
7. Quick feedback: On project teams, use it to do voting.  Post an idea and ask your followers or team members to vote on it or comment on it.  Really good for geographically dispersed teams.
8. Live coverage: For real time events or for folks who do field work, provide live coverage of what's going on to your followers (OK, a lot like #2, but I'm trying to get to 10 here to make this whole argument worthwhile).
9. Release/Build notifications: Notify team members or customers/clients of current software releases or builds.
10. Job candidate backgrounds:  Alright, this one may be borderline, but if someone is interviewing with you for a job, check to see if they Twitter.  If they do, check their Twitter feed to find out a little bit more about them.  You may not want to know that they are part of the Society for Creative Anachronism...but hey, it could be useful.

Whew, made it to 10...didn't think I'd get there.  I'm sure there are plenty of other good uses for Twitter and I'd like to hear them if you have some ideas.  Hopefully, Twitter works out better than instant messaging.  When I think about IM'ing, I think about people taking longer to say less (just pick up the phone and talk to me).  I think Twitter is potentially more useful than IM but we'll have to see where it all goes.  However, if I have to constantly wade through Tweets like these:

PhilippaJane trim milk hot chocolate and marshmellows- helps me through today

I might be more inclined to spend my time checking out I Can Has Cheezburger...it's much more entertaining.  BTW, if you want to follow me on Twitter, check me out at http://twitter.com/cspag...but I'm not promising anything!!!

I've been thinking a lot about the collocation of agile development teams (or any development team for that matter).  Some people argue that collocated team members are essential to successful software development while others argue that it doesn't make any difference.  The more I think about it, and the more we operate with geographically dispersed teams, the more I'm starting to believe that collocation matters. 

Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL.  While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications.  The difference is that in the Ft. Collins office (and I'm sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members.  You know, the kind of discussions that happen spontaneously.  When these happen, a lot of project information gets passed between team members that doesn't get transmitted to other remote team members.  There is no malicious intent to not communicate.  It's just that the impromptu discussions don't usually inspire anyone to dial in to a teleconference number and all that...precisely because they are impromptu. 

On the flip side, the scheduled daily stand ups, planning meetings and reviews all happen when they're supposed to and everyone communicates on those calls.  However, I have found that something is lacking on those calls as well.  When a team is all together in a room, there is definitely a different dynamic than when there are "voices" on the phone.   Body language plays a huge role in communications and tells a lot more than than what people are saying.  However, what I find really absent is the sense of team and camaraderie that exists in a collocated team.  There are many "physical" exercises  that we used to do for planning meetings and retrospectives that have been lost due to collocation.  I found those really useful and without them, I think our planning and retrospectives are less effective than they could be.  Maybe we just need to adapt those exercises to be more amenable to the space between our team members.

All in all though, I think I would definitely be in the camp of folks who believe that collocation really does matter.  It build a better sense of team, increases both verbal and non-verbal communications, and really fosters a more collaborative work environment.

I'm on my way home to Ft. Collins, CO and thought I'd take a few minutes to jot down my overall impressions of the Where 2.0 Conference this week in San Francisco.  In general, I found the conference to be very interesting.  Interesting mostly because it offered a different perspective for me about the new world of geography on the web.  You see, apparently, I am what is now called a "Paleogeographer"...you know, someone who actually has a background in geography and GIS.  I'm OLD (well, not really, but in the world of Where 2.0...I'm old).  Then there are the "Neogeographers", folks who have recently discovered the value and linkage between social networks, photos, and other "data" and geography, or more specifically, location. 

I'm not crazy about the two terms "Paleos" and "Neos", and I'm not crazy about the apparent dividing line between the two "camps".  The terms were thrown around a lot this week, and I don't find them to be constructive in the slightest.  I really think both sides have a great deal to offer and would be well off to start collaborating with each other to bring the "Geoweb" to it's full potential.  While it was interesting to watch this little battle of the camps play out at the conference, I think the smarter kids in the room get it that we all need to collaborate to bring out the best of both worlds and go well beyond where "Where" is now.  To some degree, I think this is starting to happen.  We saw Jack Dangermond CEO of ESRI (a "Paleo") share the stage and talk about new collaborative efforts with John Hanke of Google Earth (a "Neo").  It was a big step and one that I think both the "Paleos" and the "Neos" should try to emulate.

One of the things I liked about this conference is that it showcased the simplicity of design in web based geographic applications.  Not simplicity in functionality....simplicity in design.  Many of the demos clearly illustrated the simpler is better mantra.  One- or two-click answers to specific questions.  Good interface design, ease of use...front and center.  I think many of today's GIS "web developers" could take a page out of this book and put it to very good use in simplifying and streamlining our sometimes cumbersome and bulky web-based mapping applications.

One of my concerns at the conference was that although there were many interesting applications demonstrated over three days, many of them started "looking" the same by the end of the conference.  What I mean is, there appear to be many solutions for the same simple problems: connecting social networking to mapping, geotagging photos, Google Maps/Virtual Earth pushpin applications.  While I find tons of value and potential in all of these areas and am very excited about the possibilities that can be derived from each of them, I'm having a hard time distinguishing one effort from another.  This is clearly my opinion only, but it really reminds me of the dotcom boom all over again.  Lots of people scurrying to a happening party, all hoping they're going to be the next big thing, but all solving the same problem.  I personally believe that what we'll see happen over the next few years is a proliferation of "location based" and "location powered" sites all offering very similar solutions.  Natural selection will weed out the top solutions who will survive (or be subsumed by one of the big boys) and the rest will quietly fade away.  Seems like the new progression of lifecycle models ever since the dotcom boom.

What I am excited about is the rise of numerous crowd sourced data projects.  It has always been my contention that local geography and micro/personal geography was missing from most standard "geographies".  These localized, micro-geographies can't be built by just anybody, they have to built by the people who live, work, and play in those locales if they are to have any meaning and relevance.  So, I'm very psyched to see lots of local crowd sourced projects encouraging exactly this sort of behavior.  I think in the past two decades, people have lost their sense of "place" and their connection with their own geographies and these efforts are breathing new life into communities by helping people reconnect with  their local geography.  I know this sounds very touchy-feelie, but it's important and I'm glad to see it happening.

Finally, I'm really excited about some of the Open Source platforms and frameworks being developed for "GeoWeb" applications.  I think that the growth in this area will help fuel serious innovation and advancement in web-based mapping applications.  I don't mean to slight ESRI here, but their sometimes cost-prohibitive license model has effectively priced out smaller organizations, agencies, and consumers from playing in the world of the Geoweb.  I think that to some degree, this has had a chilling effect on innovation in the Geoweb space.  I think this is what really has spurred folks to start building open source frameworks for Geoweb development.  As a consulting geospatial development shop, I'm really excited about putting some of these open source tools to work for our clients.  I think that for us, the combination of ESRI's suite of tools in addition to these open source tools will give us a complete range of solutions we can offer to clients with a wide range of pricing and licensing options.  I believe in the end, this allows us to provide the right solution to any client in a cost effective manner.

THE DESPERATE PLEA: As an aside, I have to address presentation styles once again.  This is not really a rant or anything specific to Where 2.0, but as usual at a large conference, we saw our fair share of RBP's: Really Bad Powerpoints...and Keynotes (Apple people, you're not immune from this).  So, once again, I am making a plea that anyone...ANYONE...who is going to give a presentation to please, please, please read Garr Reynolds' most excellent book on presentation design and skills called Presentation Zen.  It's short.  it's concise. It WILL help you.  And we'll all be much happier at conferences if you do.  End of rant...apologies...kiss kiss hug hug...we're good now.

So, that's my take on Where 2.0.  We hope to be at Where 2.0 again next year and I hope we see more "Paleos" there next time.  Not because I want to hang with my Paleo-homies, but because I think there is a lot we can lean if we all start working and living together with the new breed of Geoweb developers.  See you next year.

If you were unable to make it to Where 2.0 in San Francisco, lots of the talks have been recorded and are available on Blip.tv.  If you want to check out the videos, cruise over to http://where.blip.tv/.  And, if you're looking for another excellent wrap-up article, check out my compadre Dave Bouwman's site...he's got a few good insights about the conference up there too.

(Sorry so stale:  had no connectivity in the past few hours).  Well, just like Wednesday morning's sessions, it was hard to find much to write about in the final afternoon of Where 2.0.  There was one standout presentation by Chris Spurgen of the Walt Disney Company.  He gave a really rousing and cheeky review of the best geo-hacks in history.  Essentially, it was a very entertaining look at Mercator (the man) and his genius of projection as well as the history of the biggest hack in geography...the ability to calculate longitude while sailing.  It was awesome and Chris really had the audience very engaged.  I wish I could say the same for the final speakers of the day but I can't. 

Fortunately, the day ended on a great note after an eye opening walk through downtown San Francisco.  Dave and I met up with an old friend and ate some of the best sushi we've ever had in a small sweaty local sushi bar on Market Street called Sushi Zone.  In a nod to the coolness of some of the new Google Maps goodness, here's where you can find Sushi Zone if you're ever in SF:

Lior started off with "Slides are bad, simple ideas are good, demos are better, launches are best.  So here are 9 launches in 9 minutes:"

New way of thinking at Google: Google Maps is Google on Maps.  Shift is from simple map applications to really being Google on maps. 

Not a launch, but check out the popular maps panel on the left side of Google maps now.  Places of Interest on Google Maps. 

Check out the new more button: Adds Wikipedia entries (Launch 1) or photos (Launch 2) to maps via dropdown selection boxes

New: Explore this Area tool in the left panel when you search/zoom to an area (Launch 3).  Ties map to photos, articles, YouTube videos, and user created maps in the content panel.

New: Real estate on Google Maps. (Launch 4)

New: Mapped Web pages on the Map (for this and real estate, use the Show Search Options link) (Launch 5)

New: News on Google Earth...spatially enabled news feeds placed on the maps.  Click the icon...pop up the news story (Launch 6)

Ability to all data for any kind of content aggregated to single geographic features (includes user created content). (Launch 7)

All open through the Google Maps API as of today (Launch 8)

As of 1 hour ago API is available as Flash (Launch 9)

Wow...he did it...9 launches in 9 minutes!!!

Juan Gonzales, Planet Eye.  Some very cool clustering and visualization for travel based geography.  You can share your own travel data and photos on a really nice Flash web map.  There is some very smart clustering going on as well.  To build some of their data, Planet Eye is doing some serious crawling to scrape GeoData and effectively index it.  Planet Eye has also developed a proprietary technology for maintaining an efficient GeoIndex regardless of the size of the database.

Well, I would have liked to have written a post about each speaker today...but there just wasn't much to yap about.  In my opinion, there were really only two compelling talks so far this morning.  The first was from Mikal Maron of Mapufacture and Jesse Robbins of O'Reilly Radar.  They gave a really great talk about crowd sourcing data for disaster response and recovery.  They showed some great examples of where this has been very effective (Myanmar Cyclone, China Earthquake, SoCal Wildfires) and some where it hasn't been so great (Steve Fossett search).  But overall, I think this has some great application for doing really good and important things with crowd sourced data.

The other good talk came from Jennifer Kilian of Frog Design.  She talked about the importance of design not so much from the traditional "form follows function" point of view, but from the "form follows emotion" point of view.  She presented a very compelling case study about Merian GPS (a Euro product) that, in my opinion, showcased a product that exhibited near perfect design.  And the most important part: It wasn't design for design sake.  It really fully considered the user experience and was built around that.  I think that the world of "paleo" GIS can really take a lesson from this.  We seem to always design from a function point of view with very little consideration of design.  Whether we want to believe it or not, design matters.  In the new world of Web 2.0 (well, new to the GIS community) design considerations will be just as important as functional considerations.

So, design and disaster...two words that could have described the rest of the morning session.  Lack of design consideration was evident in most of the other presentations this morning...and well, I won't say anything about the disasters.  (Oh and the wireless has been very spotty today, so sorry if my updates aren't as frequent as yesterday).

If you were unable to make it to Where 2.0 in San Francisco, lots of the talks have been recorded and are available on Blip.tv.  If you want to check out the videos, cruise over to http://where.blip.tv/. 

Pat McDevitt, TeleAtlas. Navigating the Future: Mapping in the Long Tail

All navigation is local.  Where is RELATIVE.  It seems the big companies don't map smaller, localized "where".  Why not?  They're hit based, it's too expensive to map the niches.  Pat explained it as hit based vs. niche based mapping.  Who's who in the mapping playground:

• Hit based: TeleAtlas, NavTech, UK Ordnance Survey
• Niche Based: Platial, Open StreetMap, Loopt

The niche based mapping effort is being done by...you guessed it...YOU.  How is this happening?  It's all part of the map creation long tail.

The Long Tail of Map Creation

1. Create your own content. 
2. Compile verify and normalize 3rd party data.
3. Develop enabling tools and do more of #2. 
4. Filter user and community content.

The enabling and compiling steps allow micro-interest mapping.  That means my 70 year old Dad could add content that is relevant to him thanks to steps 2 and 3.  So, where is long tail going?

In the long tail, filtering technologies will be very important in the future.  This brought up the whole Paleogeography v. Neogeography debate (man...I hate those two words...but that's another topic for another post). Really, the debate is about collaboration or competition in creating map data/content.  I think it should be collaborative and so did Pat.  He showed a great quadrant figure to describe how can all work together (read as: Can't we all just get along?).  In Pat's words, Paleo should focus on protocol based visible and verifiable data.  Neo focuses on low protocol low visible/verifiable.  Low protocol/high verifiable/visible data will be created through customer feedback to paleo companies.  If all of these areas come together, paleo and neo can come together and produce really great, unique content and geography for a very long tail in the map creation playground.  I'm not sure I entirely agree with this assessment, but it's a good start. 

POST SCRIPT: I really wanted to do a post on Jeremy Bartley's talk on ESRI's ArcGIS 9.3 but he totally got robbed.  He got 5 minutes and barely got a demo in. He talked quickly (very quickly) about ESRI's REST and JavaScript API's, showed a quick demo of Google Maps and VE integrations....and he was off the stage.  I felt really bad for him.  If you go the ESRI User Conference this year or the Dev Summit next year, connect with Jeremy.  He's a great guy and has some awesome ideas.

Vincent Tao, Director of Microsoft's Live and Local Search and Virtual Earth gave an absolutely awesome presentation this afternoon.  First he spoke about Where is the "where?".  Essentially, he see's location as nothing but an index to information.  As such, he said that we need to move from organizing spatial information to organizing information spatially.  Next, he discussed how people look for information indexed by location?  Here's his lowdown:

First look: Entry points to location data?  (Or where is the "where?")  Specifically, he was talking about location based services vs. location powered services.  So, what does that mean and what's the difference: People come to social network sites for socializing, not for location information.  The location component is value-added.  In general, most location services are powering today's hot social sites.  This is not location based services...this is powered by location services.  Big differences...and most people are using location powered services, not location based services.  So, the where is not so much at "mapping" sites as it is at sites we use every day.

Devices (what do people use to get their location data): PC queries at 71% represent the largest slice of pie.  Cell phones are 5% of the pie, phone data (i.e. mobile browsers) is at 2% but with a growth rate of a projected 71% in the next year, in vehicle navigation is at 1% with a 20% projected growth rate next year, and the remainder is still from print (you remember...those paper map thingies?).

Next, Vincent moved to show all of the way cool stuff coming (or just released) in Virtual Earth.  Microsoft views VE as an enabling platform.  As Vincent said, "We don't want one earth...we want you to create an ecosystem of millions of earths."  So here's the coolness of VE on it's way or here already: 

• VE for Mobile Search: Image mapping + real-time traffic + new voice search (recently released and very cool...I've been using it and it works great).
• VE for Messenger: Not enabled in U.S. yet, but coming
• VE add-in for Outlook: Can tie in to appointments...provide auto-reminders for meetings based on distance from meeting location and real-time traffic updates.  "Better leave for your meeting now...major traffic on I-5!"
• VE and SQL Spatial coming in June.  We're all anxiously awaiting this one!
• 500 world wide 3D cities...adding 200 more in the next year!
• Automated image processing to remove moving objects from VE tiles.
• Automated 3D city model generation: Major Secret Sauce here, but they're cranking out cities very quickly.
• V2 Cities: Upgraded textures and quality.  Much closer to reality with trees and everything...automatically!  Some of the demos he showed were almost indistinguishable from real photos.
• And, the coolest of the cool...VE and crowd sourcing: Your own photo experiences....we're talking 3D vertical photo rectification here folks!!!  Yeah...slightly impressive.  Can't wait for this to come out.
• Beyond your photos:  Dynamic real-time shadows in 3D cities.  It's done and it's coming.

Years ago, I worked on a project that attempted to integrate GIS data into the heads up displays of U.S. Army helicopter pilots.  The technology has come a long way.  Tom Chruchill from EarthData demoed some killer apps for augmented reality for the Denver Police Department helicopter pilots. We're talked fully annotated, vector-feature enhanced heads up displays.  He's also putting together some killer geobrowsers.  Check out his stuff at http://www.earthscape.com/.

Johann showed some very cool hardware from GeoTate that will automate the geotagging of photos via small GPS devices in cameras...they fit in phones, watches, credit cards and other small stuff too.  They have some simple hardware components for hardware manufacturers to embed in their  solutions.  Definitely keep an eye on these guys...this is going places.  Johann predicts that with GPS enabled cameras, geotagging in Flickr can grow from the current 6.5 million manually geotagged photos to over 50 million automatically geotagged photos...that's huge!!!

What FireEagle does:

• Share location online
• Control data &privacy
• Easily build location services

FireEagle works like a brokerage. It bridges the people getting location and the people using location.  It allows users to control how much information is stored and shared.  Tom demoed how Dopplr integrates with FireEagle and controls privacy and access to user entered data.  Essentially, they are using OAuth to manage security for FireEagle.  Here are some cool things people have been using FireEagle for:

• Navizon combines GPS, WiFi and phone positioning
• Loki combines GPS-like location, local search and one-button access to location-based content
• ZoneTag take a picture with you phone and instantly geotag it and upload to Flickr
• BrightKite allows you check into a place an upload text or photos about that place.  Location based social networking.
• Plazes recognizes where you are on a laptop or phone and provides contextual info about where you are.  Create and share activities tagged with location.

Check out Duncan Davidson's live photostream from Where 2.0 on Flickr.  You can even see the back of my head and Dave Bouwman's head as we pound through the Open GeoStack workshop (hmmm...why are we not in focus?).

Greg Sadetsky of Poly9 demonstrated FreeEarth, a 3D web based globe like Google Earth.  Difference from Google Earth: It lives on the web.  No download...no install.   It uses Flex/Flash.  Check out a live app built with it called Wild Sanctuary. It was built by Poly9 and 30 Proof.  Wild Sanctuary showcases the Free Earth Globe integrated with very interesting soundscape information and sound clips.

Other highlights:

GeoAlert: Emergency alerting system.  Built on their FreeEarth platform.  Does automated emergency alerts with some geoprocessing, including plume modeling, automated selection and notification of residents in the plume area etc.  Very cool application with real value.

MapMakr:  Bringing map making to every day business users using open source tools.  Developing robust web-based map creation tools.  Launch is scheduled for Summer 2008.

John Hanke, Google.  "300% growth in places with annotations on the web in the last year.  Geotagged web content is rapidly growing."

Highlights

Announced launch of new GeoSearch API official today. 

"The Power of Open": Announced KML as official open standard from OGC (actually happened about a month ago). 

The "Dark Web" of the GeoWeb...GIS data.  The web hasn't had easy access to it.  What is Google doing about it?  Reaching out to an obvious partner...you got it...ESRI.  Jack Dangermond joined John Hanke on stage to discuss context of GIS data on the web.  Jack: "The GeoWeb is evolving.  We are engineering ArcGIS Server 9.3 to be more pluggable for mahups, etc."  How? "Open MetaDirectory Services, KML OpenService to allow integration with web/consumer apps, building Javascript, REST, and Flex API's so 9.3 can be mashed up." 

Jack did a bunch of "mashup" demos with John using KML and several web services.  A very cool one was about climate change from The Nature Conservancy.  They also showed wildfire mapping in California with realtime information updates and dynamic evacuation routing.  It was good to see some real analytics and contextual GIS on the web.  While all the cool new social media mapping stuff on display at Where 2.0 has been interesting to see, these demos appealed to the GIS Analyst deep inside of me.  The work Jack demoed was very meaningful and that's what really matters. 

Sean Gorman, FortiusOne.  Building GeoCommons, a place to explore, create, and share geographic data on the web.  Built a great interface for finding and sharing geo-data called Finder!.  It's in Beta and you sign up and get on it today at http://www.geocommons.com/beta/ .  Also adding other apps to provide cartographic tools for putting together your own data with GeoCommons Data (called Maker!) and for collaboration and sharing your data and maps (Atlas!).  Very cool and very interesting.

Adrian Holovaty of Everyblock spoke about EveryBlock and lessons we can all learn about web mapping sites.  Essentially, EveryBlock is a news feed for your block.  EveryBlock pulls from various news and public sources and makes them searchable/mappable/deep linkable in a very localized area.  Very cool stuff.

Highlights:

"On the web, not of the web": Too many sites that have maps on them don't interact with the rest of the web.  Ask yourself this question: "Will my site work without maps?".  Make everything deep linkable...it matters.

"Move beyond points": Not many mashups use lines or polygons...too many are point focused.  If you're data applies to areas or "lines" use them...don't take the easy way out with points.

"Roll your own maps":  Sometimes Google Maps and VE aren't really what you need in your app...it's one size fits all mapping.  Why do we accept Google/Yahoo/VE as default maps?  You wouldn't use a Wordpress template for your corporate website would you?  Roll maps that enhance your data visualization, not Google's.  Take control of your maps.  EveryBlock is using MapNik and OpenLayers to roll their own stuff.

Mikel Maron presented some cool hacks at Where 2.0 this morning.  Here are some highlights:

BBC Bangladesh River Journey:  Hacked maps, twitter tweets, Flickr all in one place.  The expedition crew used a satellite phone, GPS,  and a laptop and dynamically built and updated the journey website.  The crew geotagged all posts and pictures.  When they submitted their Tweets/pics, a custom API parsed nanoformats out of the Tweets and Flickr photos using nanoformat parsing suite.  This built the maps very simply and quickly for the expedition crew.  For all the details on the API they built, and ways you can remix it, check out http://bangladeshboat.welcomebackstage.com/. Here's the site, it's pretty cool.  By the way, check out the cool hack to get the Google bubble to live outside the map.  This was a major hack that free's the bubble to exist anywhere on the page and exceed the map div.

UNDP Environment Projects:

The UNDP had tons of projects and didn't have them mapped.  To easily map them, Mikel built a simple API that allowed end users to go from RSS -> Mapufacture --> GeoRSS.  If staff had the credentials, they could edit the feeds.  Mapufacture ingested the RSS, geotagged it and pushed out GeoRSS.  That was hack #1.  Hack #2 was a lightbox using Lightbox 2 to drop the map on top of the webpage to maximize map real estate without completely obscuring the webpage.  Hack #3 was to add different icons for each category or class of project and have a TOC that allows the user to toggle the contents of the map.  Very cool stuff.  Check it out:

Very cool things at Web 2.0 this morning.  The first session was on MapStraction and Open StreetMaps.  Here's a quick skinny on what we're hearing so far.

MAPSTRACTION: Presented by Andrew Turner

What is MapStraction?  Basically it's a common API for most of the Javascript providers out there.  Why is it cool?  Write your code once, use it many times with any providers like GoogleMaps, VE, Yahoo Maps, Mapquest...you name it.  Why it's really cool: You can set up your app to allow users to "swap" between providers on the fly.  Why would  your users want to do this? Different map providers have different coverages depending on where you're at.  It gives total flexibility to your provider model.  Oh yeah...and it's FREE.

OK, so what is the functionality included in Mapstraction: It's mostly least common denominator functionality like markers,  lines, polygons, overlays, tiles, events, filtering routing, geocoding.  What is doesn't do: search, WMS, break terms of service, support every library's niche feature set.

Mapstraction looks really easy to use.  Here's the simple Mapstraction recipe for building it out:

• Include Javascripts
• Create HTML map div
• Create Javascript Mapstraction object
• Center map
• Add controls
• Add features
• Add events

Here's a quick Mapstraction sample showing multiple providers on a single page...all from the same code supplied below:

 function londonJavascriptNight(map) {
        // create a lat/lon object
        var myPoint = new LatLonPoint(51.520832, -0.140133);
        // display the map centered on a latitude and longitude (Google zoom levels)
	map.setCenterAndZoom(myPoint, 12);

        // create a marker positioned at a lat/lon 
        var marker = new Marker(myPoint);
        // add info bubble to the marker
        marker.setInfoBubble("Hello London!");
      
        // display marker 
	map.addMarker(marker);
      }

      var gmapstraction = new Mapstraction('gmap','google');
      londonJavascriptNight(gmapstraction);
      var ymapstraction = new Mapstraction('ymap','yahoo');
      londonJavascriptNight(ymapstraction);
      var mmapstraction = new Mapstraction('mmap','microsoft');
      londonJavascriptNight(mmapstraction);
      var osmapstraction = new Mapstraction('osmap','openstreetmap');
      londonJavascriptNight(osmapstraction);

      // synchronise center of gmap and mmap with ymap
      var ycsync = function() {
        var center = ymapstraction.getCenter();
	gmapstraction.setCenter(center);
	mmapstraction.setCenter(center);
	osmapstraction.setCenter(center);
	center = undefined;
      };
      // synchronise zoom of gmap and mmap with ymap
      var yzsync = function() {
        var zoom = ymapstraction.getZoom();
        gmapstraction.setZoom(zoom);
	mmapstraction.setZoom(zoom);
	osmapstraction.setZoom(zoom);
	zoom = undefined;
      };

      var ymap = ymapstraction.getMap();
      YEvent.Capture(ymap, "onPan", ycsync);
      YEvent.Capture(ymap, "endPan", ycsync);
      YEvent.Capture(ymap, "endAutoPan", ycsync);
      YEvent.Capture(ymap, "changeZoom", yzsync);

OPEN STREETMAP: Presented by Steve Coast

Open StreeMap is a way cool project that is building a crowd sourced map of worldwide streets.  Totally a grass roots remapping of things.  Essentially it uses the general public to build new street maps using GPS traces and public domain imagery.  The stuff looks great and it is much more current than any of the other providers right now.  Currently it's pretty Euro-centric (seems to be a big hit across the pond).  But, they do have US Data from Tiger data that is being updated and corrected as people add new stuff.  I even checked out our local digs and it seems that bike paths and some foot paths in Ft. Collins have been mapped. 

Currently, there are about 35,000 users of the data, 3,000 editors, and about 35 million objects in the database.  Speaking of the database, it's a simple data model with only 3 data types:

Nodes: id, lat, long, user, timestamp, visibility, tags

Way: ID, nodes, user, visibility, timestamp, tags

Relations: id, members, user, timestamp, visibility

The database currently resides on a MySQL instance.  You can get your own copy of the database as a file (Planet.osm). It's released weekly, about 4GB compressed.  It is the definitive dataset, essenatially it's OpenStreetMap in a file (XML version of entire DB). 

Quickly, here's the tech stack for Open Streetmap:  MySQL, Ruby on RAILS, API, OpenLayers for rendering, editors, http://svn.openstreetmap.org

API: Built as simple as possible...RESTful, XML, HTTP AUTH

Rendering: Mapnik, Osmarender

So, that's a quick update from Where 2.0.  More to come.

This week, Dave Bouwman and I will be attending the Where 2.0 Conference in San Francisco.  Where 2.0 is all about bringing GIS and geographic data to the masses by putting it into usable, searchable, and web enabled applications.  It's helping move the GIS industry from the ivory towers to the browsers of everyday people.  We'll be blogging from the event, so stay tuned for daily updates.  If you're at Where 2.0 and see Dave or myself, come on up and say hello.  We love meeting new people and talking GIS...and anything else for that matter.  See you in San Francisco.

I think one of the best aspects of agile development is the ability for a team to frequently learn from their mistakes.  It's especially crucial that this happens in a blame free environment.  When something goes wrong during an iteration, it's important that no team member is singled out.  The entire team accepts responsibility for their failures and successes together.  And when a team makes mistakes, they need to learn from them.  The key components for in a team's ability to learn from their mistakes are the attitude and interactions of the ScrumMaster. 

There are a few things a ScrumMaster must do to help their teams learn from their mistakes.  First and foremost, the ScrumMaster cannot be a fixer.  When things are broken or not working the team, not the ScrumMaster, must figure out how to fix things.  If the ScrumMaster continually steps in to fix the problem, the team never learns how to fix a problem for themselves.  This leads back to the old command and control structure of more traditional development approaches.  Instead of being a fixer, the ScrumMaster needs to be an enabler.  The ScrumMaster needs to be aware of any problems the team may be having and provide them with whatever resources they need to solve the problem on their own.  It could be something as simple as a phone number for a key client contact.  Whatever it is that is keeping the team from solving their problem, the ScrumMaster is there to provide it...except for the solution itself.

The other thing I think a ScrumMaster must do is allow teams to make mistakes.  Because Scrum is, at its core, an empirical process, we expect certain things not to work...and we expect to inspect and adapt our practices to make them work better.  That means letting teams fail sometimes.  If a ScrumMaster always steps in and prevent a team from making mistakes, the team never get the chance to learn from them.  If a team doesn't get that chance, they become inefficient at self-management, another key tenet of Scrum.  And again, this leads back to the old command and control structures of traditional project management.

So, my two pieces of advice for ScrumMasters: Let your teams make mistakes...and don't be a fixer, be an enabler.