When it comes to agile methods, almost everyone agrees that agility can apply to the software development team and to the organization within which a software development team finds itself. Some people will also argue that agile methods are applicable to organizations that don't develop software, but that's a discussion for another forum. This raises some questions: To what extent can the one be separated from the other? Can an agile team succeed if the organization around them doesn't wish to adapt to an agile approach? To what extent does the organization's resistance to agile methods affect the success of a team? Should agile methods focus on the the team or the organization to the exclusion of the other?
These questions are not new, but they are of particular relevance now, when the Agile Alliance is looking at ways to refocus itself and has suggested it is considering focusing on the agile team:
The Agile Alliance should explicitly focus on helping members of Agile teams succeed, leaving concern with the larger organization to others.
The threads Brian Marick set up on agile forums for the 'pro' argument, the 'con' argument and the associated poll have attracted some attention, as has the definition of team success. Laurent Bossavit speaks up for an agile-team focus:
I'd be happy with an AA focused on the "front-line" folks. And, whenever the AA is concerned with how things are working out between the "front line" folks and the rest of the business, I would want the AA's mission should be "to help the software development people engage and align with the business".
For Scott Lilly, this seems to be a black-and-white issue:
"localized optimization = no optimization"
Others believe this is best tackled holistically, such as Paul Oldfield:
Change works best IMHO and IME when there's top-down and bottom-up change, at the same time and both working toward a shared vision.
I believe the effectiveness will be considerably more than twice the effectiveness of doing just top-down or just bottom-up alone.
This discussion has also spread into blogs. George Dinwiddie seemed to have mixed emotions when he argued that the two concerns may not be separable, but that APLN's focus on the organization may allow the Agile Alliance to focus on the team. Another sideways look at Agile suggested:
But there's no Agile without active and enthusiastic business participation. Which leads to a problem ... many organisations find themselves at a pretty pass, a singularly vicious circle. They don't believe in their IT departments because they "don't deliver". The departments don't deliver because the requirements are unstable and hard to articulate. To solve this they need to think and act Agile. This requires them to trust their IT folks. But they don't. Because they "don't deliver."
Although some have already raised their voices elsewhere the discussion has been muted. The InfoQ Agile community is a large and vibrant community which can contribute to this discussion. We'll be asking a few members of the agile community as a whole large to join the conversation, but most importantly, we've asked you:
- Can the concerns of the agile development team and the agile organization be separated?
- To what extent are they separable, and to what extent does the success of one depend on the other?
- Should the Agile Alliance focus on the Agile team and leave the agile organization to others such as the APLN?
Community comments
The Team Is Important.
by David Hoehn,
Cautious Separation
by Geoffrey Wiseman,
Re: Cautious Separation
by Deborah (Hartmann) Preuss,
Re: Cautious Separation
by David Hoehn,
"success" and "failure", "teams" and "Teams"
by Keith Braithwaite,
My motivations for raising the fuss
by Brian Marick,
Re: My motivations for raising the fuss
by Amr Elssamadisy,
Re: My motivations for raising the fuss
by Dave Rooney,
Re: My motivations for raising the fuss
by Geoffrey Wiseman,
What kind of organization?
by Steven Devijver,
Agile Team, Agile Organization.
by Evan Leonard,
The Team Is Important.
by David Hoehn,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not having read this thread until recently I am trying to catch up.
Being involved with the APLN and also standing for eelection to the AA board this year I have an obvious interest in focusing the Agile Alliance, together with others on something which is important to the community. I do not feel that the AA will ever be in a position where they do not need to pay attention to the efforts made by other organisations such as the Scrum Alliance, DSDM Consortium, APLN and so on.
Focusing the discussion around teams seems to be a limiting factor on a more holisitic few on the issues which all entail "Agile".
Paul Oldfield's point of view is just as valid as Laurent Bossavit. I think it is imperative for a well rounded AA to provide the necessary programs and means so that "front-line" people can be well supported, have access to the necessary tools and bits of information, while those working as mentors and coaches are being provided with becessary resources to make life for agile teams and agile "front-line" implementors easier.
We are all part of a community, even if I focus much of my time on the AA, I will always be a part of the APLN, which has a specialist focus. However, the members of the APLN can learn from the AA members and vice versa. I do not see any need for a hard seperation between the two of them. Collaboration is what we are all about and that should happen between APLN and AA just as much as it should happen inside an agile organisation.
Organisations need to listen to the concerns of everyone in their environment, not only the developers. I do think, as I stated in some of my Proposals, that it is not only about the software development bit. The AA is very good at that area and will always have a strong focus around it, but bringing the business and the people enabling others to do Agile on board is a big part of the AA's focus into the future of Agile. At least to me.
If you have further questions, please do comment here or on the AA forum, I will make an effort to answer.
Cautious Separation
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Personally, my feeling is that there is room for limited separation; I believe that team success requires good alignment with the organization and that the two are related in ways that cannot be severed. On the other hand, if the Agile Alliance works closely with other organizations on the holistic view, it might be possible for them to emphasize the issues that are team-specific.
That said, my preference is to treat them as a whole and not focus on the team or the enterprise individually.
"success" and "failure", "teams" and "Teams"
by Keith Braithwaite,
Your message is awaiting moderation. Thank you for participating in the discussion.
So, I'd say that to first order individuals succeed (if they do) mainly because of their own characteristics, and they fail mainly because they are working in a context where success is not possible.
I'd also want to distinguish a "Team" from a "team"--the former is a bunch of people nominated by the organization, with a common manager, charging against a common cost centre, all working on the same "Project" with a "Goal" and so forth. And the latter is who you see working together towards some change when you look for who's doing that, given a change you have in mind.
In happy organizations, when you look for who is working towards the change that will enable the Goal you'll see a team that's the Team on the Project with that Goal. And then there's the other 99.9% of cases. This isn't really anyone's fault, as such.
A Team can easily choose that its going to use TDD to build its software, say, or plan its work in sprints or whatever, and no-one else in the organization will really care terribly much. As long as that Team doesn't barge about the place condemning all other Teams who don't choose these things as incompetent luddites.
If a team chooses to work in a fully ramified agile way, on the other hand the story is likely to be rather different. A lot of people all over the organization will find themsleves challanged in all sorts of ways, and they'll kick back. Can such a team survive, in such an environment? Let alone succeed?
Which of these is "front line"? I don't know for sure. I understand the question on the Agile forum only weakly, but it seems as if the choice is presented that the AA can focus on Teams (and supporting them in adopting pratices) or on teams and successful change. I'm inclined to think of the "team" as font-line, as the exposed risk takers with the potentially big reward. Their success strategy might not involve rolling out all the practices and blah, blah, blah. Not this time. Whereas the Team, ticking off its adoption checklist seems like a rear-echelon sort of affair. I suspect that this is the opposite of the understanding that the Agile Forum poll is aiming at.
And in reality, most cases probably require both stances.
Re: Cautious Separation
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
What if we came up with some heuristics that teams could use to tell whether they should get help with broader organizational issues? Beyond things a limited AA would address?
And provide services at APLN to help address or follow up on such issues (like a FAQ, a hotline, a blog, a chatroom, whatever).
Re: Cautious Separation
by David Hoehn,
Your message is awaiting moderation. Thank you for participating in the discussion.
Personally I would be delighted to see such patterns or heuristics emerged. I doubt that they will be very efficient though. Maybe a knoweldge and skill based training program could ensure that people have the necessary background to spot such issues. They can then choose to "report" them to the AA or organisations such as the APLN. There are, after all, enough open discussions and places where you can discuss.
My motivations for raising the fuss
by Brian Marick,
Your message is awaiting moderation. Thank you for participating in the discussion.
See a posting on my blog for more on the topic.
I agree with the point about global vs. local optimization. However, I question whether we - the Agile Alliance - have any appreciable influence on global optimization. If not, that means "global vs. local" is a false choice. It's really "local vs. none". Given that choice, I prefer "local".
But why accept that choice? Why not get some influence on global optimization? My answer: because we've shown no skill at it and are unlikely to succeed.
So what's the harm of trying? It diffuses the focus of the organization. A diffused focus, an organization that wants to make everything better, is not one that motivates good volunteer effort. We are currently in the annoying position of having a successful conference that brings in more money than we have good projects (championed by committed volunteers) to spend it on.
But there are plenty of problems at the team/local level that need solving. The people on our teams are not skilled or disciplined enough; there is not enough striving for excellence; there is not enough dedication to making work a joyful craft. So let's rededicate the Agile Alliance to taking all those disparate, dislocated people on teams and (1) giving them the opportunity and tools to excel, and (2) be less passive about nudging or pushing members to excel.
Re: My motivations for raising the fuss
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'll venture to suggest that this is true for the Agile Community as a whole and not just the AA.
Let me play the devil's advocate:
If this is true for the community, then Brian's point should be expanded - let us all stop trying to scale up past the team! Let's realize that this is the case and just do the local optimizations - that's what we've done successfully.
Re: My motivations for raising the fuss
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that improving/expanding the local optimizations is a good thing. However, I do believe that there are ways to make organizations more agile without diffusion.
For example, the organizational structures I see are very often vestiges of a waterfall approach to building systems. This entails the standard "bad things" like silo organizations, and also includes just the physical environment in which the people work.
For this to happen, you need a three-pronged approach. You must engage the people at the development level, you must engage the people on the business side, and you must engage and receive total commitment from the highest management level possible from the organization sponsoring the project. That's the key - being backed by someone with enough clout to be able to make the changes necessary for success. Since it's happening at such a high level, it's much more visible and will have a ripple effect. Assuming that success ensues, other executives will want to know how to apply the approach.
Of course, that assumes that all people are rational, and that there won't be a backlash by those who feel threatened by such changes. ;)
Dave Rooney
Mayford Technologies
What kind of organization?
by Steven Devijver,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think an important part of the equation is what kind of organization are you working for?
System integrator on fixed price base, outsourcing, internal IT projects, product development?
There are only so many types of organization that use IT but each one is specific.
I work for a system integrator and I have to say it's the most flexible organization type I've ever worked in. I see the same forces at play at other system integrators.
Internal IT projects will probably face very different organizational structures that in certain respects are likely typical for this setting.
Re: My motivations for raising the fuss
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hmm. That's certainly something to think about. I guess I'm not against emphasizing the areas where we feel that we can make a difference. At the same time, I think the organizational alignment is important enough that I'm not convinced we can give it up entirely.
When I say, 'we', I mean the agile community as a whole. How the Agile Alliance fits into that is the question that started this discussion. I'm interested to see where this goes.
Agile Team, Agile Organization.
by Evan Leonard,
Your message is awaiting moderation. Thank you for participating in the discussion.
Brian, I appreciate your thoughts about focusing the Agile Alliance very much. After all, its an agile principle to do one thing well, rather than two things poorly. However, I disagree that the agile community has shown no skill at solving the "global" problem. Are you familiar with Holacracy?
Holacracy is a practice for organization at the leading edge[1]. It has been developed by an agile software development company named Ternary Software[2]. Holacracy integrates several practices to product a whole-system shift in the organization, in the same way that Agile methods have for software development teams.
The principles behind our practice in agile software development have great possibility for application in the organization as a whole, but it will take new steps of discovery and invention to apply the principles in a new organizational practice.
While at the same time it may be appropriate for the agile community to focus in on and extend its "local" influence. Trying to solve both the "local" and "global" problems within the same organization may be more than one community can bear without breakup and fragmentation.
Holacracy provides a new center to organize around to solve the "global" problem while remaining entirely compatible and supportive of the Agile community. Have a look.
Evan Leonard
[1] - www.holacracy.org
[2] - www.ternarysoftware.com