Can Agile Separate Team Concerns from Organizational Ones?

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.

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.

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.

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

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.

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.

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.

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

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.

My answer: because we've shown no skill at it and are unlikely to succeed.

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