cspag's blog

Agilistas Hits 1000 Member Mark

June 2, 2008 by cspag

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.

Where's the glue?

May 30, 2008 by cspag

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.

Scaling agile success

May 29, 2008 by cspag

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.

Agile adoption: Why isn't this stuff working?

May 28, 2008 by cspag

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.

Short term teams

May 27, 2008 by cspag

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.

The case for collocation

May 19, 2008 by cspag

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.

ScrumMasters: Don't be a fixer

May 7, 2008 by cspag

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.

Who's driving the bus?

April 28, 2008 by cspag

Here at DTS, we're very focused on consulting-type software development. As such, we have very direct access to our end users and customers. Our work is "clearly" defined and prioritized by our customers and we receive direct customer feedback every two weeks. We do not have a dispersed customer base, it's usually a single organization. However, last week I had lunch with a friend who does more "shrink-wrap" development. His customers and end-users never define or prioritize their needs. In fact, unless it's by pure happenstance, the developers never meet or know their customers. The functionality and feature set for the software is defined by an internal customer proxy who has his "finger on the pulse of the customer".

Now a disclaimer: I've never worked on a shrink-wrap team, I've always been on consulting development teams. Given that little disclaimer, I don't understand how a customer proxy can really define what an entire unseen, unknown customer base really needs.

My Dad was a ScrumMaster

April 17, 2008 by cspag

In light of the recent news about American Airline's maintenance problems, I sat down and talked with my Dad about aircraft maintenance. You see, my Dad was a maintenance Crew Chief for Pan American Airlines for nearly 30 years and I wanted to understand how things got so bad for American. My Dad explained the inner workings of Pan Am's maintenance program to me. The program dated back to late 1960's and early 1970's and was remarkably agile-sounding. Here's the program in a nutshell.

Team Velocity: More than the sum of it's parts?

April 2, 2008 by cspag

With our move to our new company came a new way of working for our team. We used to be a tight knot team, all working the same long-term 3+ year enterprise project. Now we're working on equally engaging projects, but they are shorter term. Our "team" has been split into smaller teams of 3, 2 and even 1 person per project. We've also been working on distributed teams with our other offices around the country as well. As such, our velocities are for individuals, small teams and disjointed teams. It looks like this will be the modus operandi for the foreseeable future as well: Mix-n-match teams to put the right people on the right jobs for our clients. So, the question that has been occurring to me lately is, how do I get reliable velocities to adequately estimate bids for future work with our mix-n-match teams?