Chris Spagnuolo's GeoScrum

Open House at DTS and DTS Agile

Chris Spagnuolo — Thu, 19 Jun 2008 18:00:53 GMT

Join us as we open our new Ft. Collins office. Meet our staff, check out our new office and enjoy drinks and appetizers.

Date: July 1, 2008

Time: 6:00 - 8:00 PM

Location: 409 Mason Court, Suite 127, Ft. Collins, CO 80524

Click here for a map and directions. If you would like to attend, please RSVP to Chris Spagnuolo via email.

The State of Agile Development

Chris Spagnuolo — Wed, 18 Jun 2008 15:39:49 GMT

With the increased interest in agile development these days, it's good to keep tabs on what the industry is doing in terms of the adoption and use of agile practices. For the past 2 years, Version One has conducted a "State of Agile Development Survey". Now, they are conducting their 3rd Annual Survey to gauge the adoption level and value of agile practices. It should take less than 10 minutes to complete. And, as a bonus this year, they will be drawing 3 prizes from the respondent pool: a $750 and two $250 gift certificates to Amazon.com. The survey is completely anonymous and the results will be made publicly available. If you're interested in taking the survey or want more details, visit Version One's Survey page here.

GIS/Agile Developer Training

Chris Spagnuolo — Mon, 16 Jun 2008 14:14:17 GMT

DTS Agile is happy to announce that Dave Bouwman will be teaching a developer intensive agile training course August 13-15, 2008. Dave will lead this intensive 3-day course and will show you how we develop our software. Releasing software every iteration sounds daunting, but it doesn't have to be. This course is designed to help teams implement a solid process for designing, testing, documenting and releasing software in an automated manner. Dave will review the use of open-source tools in the context of a real project. He will also discuss some of the additional challenges geospatial developers face. Although this class will focus on .NET technologies, the techniques and core concepts apply to any development language and platform. A complete description of the course topics can be found below. Click here for more details about the course and to register.

Course Topics

Source Control with Subversion

Source control systems are critical to any software development effort. We'll review how to setup a free Subversion repository at Assembla.com, and how to work with it via TortoiseSVN and the AnkhSNV plugin for Visual Studio.

Automated Code Documentation

Ever come back to some code you wrote and wonder what you were thinking? Did you wish you had some documentation? In today's development environments, adding good comments is very simple, and in some cases automated. Putting in structured comments also simplifies the creation of API documentation. We'll review how to leverage Xml comments, GhostDoc, and DocProject to produce professional quality HTML documentation from your source code.

Unit Testing

Going with the idea you need to walk before you can run, we'll start with an introduction to the why, what and how of unit testing. We'll look at how you can leverage unit tests today as part of a test-after development strategy. We will then look at MBUnit, a popular unit testing framework for .NET, as well as the TestDriven.net Visual Studio add-in that streamlines testing. We will also discuss the use of mock objects, and look at how we can use RhinoMocks to simplify things.

Design Patterns

Now that we have a handle on what unit testing is all about, we need to figure out how to write code that's testable. Luckily we can lean on some really smart people like Martin Fowler who have come up with re-usable code patterns that help us build testable software.

Refactoring Tools

Being agile means being open to that wild change of direction your client just asked for. When that happens you'll really appreciate good refactoring tools, but we'll show you how they can help keep your code lean and mean on a daily basis, and allow you to easily implement design patterns. We'll be looking at the tools built into Visual Studio, as well as ReSharper

Automated Builds

It's one thing to know it builds on your box, but that's not what counts! We'll review how to write a build script using MSBuild, the MSBuild Community Tasks, and how to setup a daily build process.

Continuous Integration

Since having the software build automatically every day is good, building on every check-in must be great! This is the core idea behind continuous integration - every time there is a check-in, the code is built, tests are run, and the team is notified if anything breaks. We'll look at setting up a CruiseControl.net server, and how that works for a real project.

GeoGathering 2008 Presentation Online

Chris Spagnuolo — Thu, 12 Jun 2008 19:30:40 GMT

Last week I was up at GeoGathering 2008 in Estes ParK, CO. I didn't have much to blog about from the event, but if anyone is interested, the presentations from the conference are now available online at the GeoGathering website. There's also a small photo slideshow available from the conference as well.

Agile Webinars from ThoughtWorks

Chris Spagnuolo — Thu, 12 Jun 2008 14:24:09 GMT

Attend ThoughtWorks' Agile-centric webinars to learn and discuss with some of the world's foremost Agile metrics experts on how you can measure and communicate the value of your Agile software initiatives:

Agile Reporting and Metrics: Project Intelligence for Successful Software Delivery.
Tue, June 24, '08, 11:00 AM EST - Register Now!
Getting the most out of Agile: "Agile made us Better, but we signed up for Great!"
Thu, June 26, '08, 11:00 AM EST - Register Now!

What you'll learn
(from Agile gurus Ross Pettit, Sanjiv Augustine, Raymond Cuellar)

Agile teams, like all application development teams need to quantify the business value they deliver. Attend these webinars with Agile experts and get answers to questions like:

What are the metrics we should be tracking?
What's useful and what's not?
How do I provide visibility into project progress to Management and other stakeholders?
Practical tools and concepts that can make immediate impact on your team and make IT a GREAT delivery partner

See more: Details of the webinars

Upcoming Webinars: Agile Testing and Agile Reporting and Metrics

Chris Spagnuolo — Fri, 06 Jun 2008 17:40:08 GMT

Brought to you by Better Software Magazine & StickyMinds.com:

Using Lean Thinking to Improve Agile Testing: The New Role of QA

Date: Tuesday, June 10, 2008, 2:00 p.m. ET

Featured Speakers: Alan Shalloway, CEO. Net Objectives

Podcast: Global Avian Influenza Mapping and Agile

Chris Spagnuolo — Thu, 05 Jun 2008 13:35:54 GMT

While at Where 2.0, Dave Bouwman and I did a podcast with Jesse and Sue over at Very Spatial. We spoke about a recent project we completed for the Wildlife Conservation Society for their Global Avian Influenza Network for Surveillance (GAINS) project. The mapping application was a Virtual Earth implementation which showed locations and information of bird flu cases around the world, as well as related flyways for those species. We also talked a little bit about how we used agile practices to deliver the application very quickly and with complete customer satisfaction. If you want to check out the podcast, head over to Very Spatial. If you'd like to take a look at the application, check it out the WCS GAINS website. And, if you're interested in more of the technical details, check out Dave's recent post about building the application.

Google Maps ExtJS Wind Energy Demo/National Geographic Tornado VE Map

Chris Spagnuolo — Thu, 05 Jun 2008 03:09:00 GMT

New on our DTS Code Dojo: Created as a demonstration integrating Google Maps and the ExtJS Javascript framework, the Wind Energy Explorer is a site for viewing our nation's wind energy capacity. The initial functionality is focused on loading state polygons into the map via GeoJSON. When the user clicks on a state, the rendering the capacity over last 9 years is shown as a Google Chart. The viewer also makes use of the powerful data grid in ExtJS, which automatically supports custom sorting. We will be adding more functionality to this viewer over the coming months.

Our recent work with National Geographic, the MetaLens Virtual Earth Viewer also got some good use and some press in the Coloradoan newspaper. David Wright, National Geographic's Director of Professional Products, used the site we created to post a photo journal of the recent effects of a tornado that hit nearby Windsor, Colorado. It was a great use of the site in raising local awareness of the devastation the tornado left in its wake. If you'd like to donate to the Windsor Relief Fund, visit the City of Windsor website to find out how you can help those in need.

Learning from Quincy Jones

Chris Spagnuolo — Wed, 04 Jun 2008 19:16:53 GMT

I was recently re-reading an article in the March issue of Smithsonian Magazine about the life and career of Quincy Jones. If you don't know who Quincy Jones is, he is possibly the greatest American music impresario ever. He's a living legend, with multiple Grammy Awards to his credit. His career and the musicians he has worked with are simply amazing. What really caught my eye in the article was a small paragraph that gave some insight into how he has been able to create such huge successes with the artists he has worked with. Here's the line that really made me think:

"He has an unusual combination of intensity and charm with which he has brought out the best from a wide range of idiosyncratic performers. As a producer, Jones is known to research every nuance, hire the best players, and set them free."

It really hit me that that's what all great producers should do. Hire the best, and set them free. As software development managers or scrum masters, we are the producers and we should always keep this little pearl of wisdom in mind. I think it's what really sets great teams apart from mediocre teams. First and foremost, hire the best. Stop trying to find cheap resources that can "bang stuff out". The best cost a bit more but in the end, they're well worth the price you paid.

Second: Once you've hired the best, set them free to do what they do best. That's why you hired them. As soon as you start constraining them to some corporate policy or restraining their creativity by imposing some project management mandate on them, you've lost your investment in the best. When we try to micro-manage or direct work too much, we can stifle the creativity and ingenuity of our best performers. Sometimes, this means having the sense of mind to let them go way out to and beyond the edge. That's where genius resides. This requires trust, patience, and no big egos.

So, what I learned from Quincy: hire the best, and set them free to explore their space. Let them perform naturally with no bounds. By doing this, we can really break barriers and produce what Seth Godin calls a Purple Cow. Set your team free today and start creating truly remarkable things.

Working from home? Check out Baby Smash!

Chris Spagnuolo — Mon, 02 Jun 2008 20:21:52 GMT

Do you work from home a lot? Have kids that like to sit on your lap and bang on the keyboard? Yup, we've all been there...it's fun. Well, now your little developer can really do something cool when he bangs on your keyboard. While working from home today, I discovered the latest cool thing created by Scott Hanselman called Baby Smash! According to Scott:

"As babies smash on the keyboard, colored shapes, letters and numbers appear on the screen. Baby Smash will lock out the Windows Key, as well as Ctrl-Esc and Alt-Tab so your baby can't get out of the application. I wrote BabySmash! for my 2 year old and 5 month old so they could bang on the keyboards of my Windows machines without hurting anything."

Agilistas Hits 1,000 Member Mark!

Chris Spagnuolo — Mon, 02 Jun 2008 18:35:55 GMT

Today, Allen Laframboise from ESRI signed up and became the 1,000th member of the Agilistas group on LinkedIn (sorry Allen...no prize for being #1000). It's been amazing seeing how may people have joined up. Agilistas is a collaborative community dedicated to evangelizing and advancing Agile practices in software and product development. If you're not an Agilistas member and would like to join here are some links for you.

To join Agilistas on LinkedIn: http://www.linkedin.com/e/gis/43421/24A5E7397137

To join the Agilistas website, which includes a community blog, a news & events section, file sharing and discussion boards, follow the instructions below:

For those of you who do not have an Agile Commons account, you can join Agilistas by going to http://agilecommons.org/join/agilistas

For those of you who do have an Agile Commons account, you can request membership by going to http://agilecommons.org/groups/1549f5474f/members/request. This link is displayed on the Agilistas homepage in the “Become an Agilistas Member” panel (which is only visible to members of Agile Commons).

Cheers!

Don't get skewered when you speak at a conference

Chris Spagnuolo — Mon, 02 Jun 2008 16:43:56 GMT

At the recent Where 2.0 Conference, several speakers were completely skewered during their presentations by attendees using Twitter and an IRC back channel. This phenomena is not limited to the Where 2.0 Conference...it's happening everyday at conferences around the world. And, it's in the public domain...everyone can see how bad you are! So, how do you avoid the pain of being completely bashed by your audience while you're speaking? Hint #1: Don't suck. Hint #2: Check out a great post by Rohit Bhargava over at Influential Marketing called "How to Speak at a Conference Without Getting Skewered on Twitter". And, I'd be neglecting my duties if I didn't plead with you for the 100th time to pick up a copy of Garr Reynolds' "Presentation Zen"...read it, learn it, live it.

Where's the glue?

Chris Spagnuolo — Fri, 30 May 2008 17:44:09 GMT

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.

Scaling agile success

Chris Spagnuolo — Thu, 29 May 2008 18:21:32 GMT

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.

Top 10 Pitfalls in Agile Software Development

Chris Spagnuolo — Wed, 28 May 2008 16:18:22 GMT

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.

Agile adoption: Why isn't this stuff working?

Chris Spagnuolo — Wed, 28 May 2008 15:15:49 GMT

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.

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.
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.
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.
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.
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.
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.

Short duration teams

Chris Spagnuolo — Tue, 27 May 2008 15:31:39 GMT

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.

Finally in our new space

Chris Spagnuolo — Thu, 22 May 2008 21:26:14 GMT

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.