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.
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.
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.
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. Read more »
