One Team, but just a team

One of the agile development practices is One Team, meaning that team as a whole takes the responsibility. When agile team is formed by a bottom-up initiative, it will soon face the problems of limited sphere. Most of the problems in projects are not related to design, technology or engineering practices. These are the only ones that the team is capable to fix quickly through iterations and reflective retrospectives. After fixing its own sphere, the team hits the wall when working in the shadow of a large organization. This can be a stressfull situation as everything is starting to be crystal clear.

Afterall One Team is just a team.

Last monday at Agile Seminar Helsinki Heimo Laukkanen presented that the whole organization needs to be agile in order to fully harness the power. He talked about IT governance, but even faster you will notice need for change in leadership styles, design review practices, personnel development, project planning (not plan), marketing involvement, and a lot more. Even while the agile development only in technical level may be rewarding, seeing clearly the dysfunction of standard organizational processes (so called best practices) and structures will hammer down the gained team spirit and motivation, eventually forcing it back to old ways of working.

Changing these processes and structures in a large organization may be impossible with bottom up approach. Large organization has a whole process department to take care of the process. It would take a complete paradigm shift to access this process. What makes this hard is that this department is not rewarded based on project success or revenue, but the success of current paradigm - from the administrative perspective. Admitting that a paradigm shift is actually needed might feel like a failure of the department.

This is one of the reasons why agile interventions often fail, the rest of the organization fails to learn fast enough.