Self-Organizing Agile Team

The Goal of Agile is to Deliver the High Quality Software, Self-Organizing should be Vehicle, not a Destination.

There is no doubt Agile is becoming mainstream, however, 'within' or 'of' Agile, it still takes time for getting matured from structure, methodology or mechanism perspective. How to build a high performance agile team is the other hot debate in Agile community: Should Agile team self-organizing or self-organized? Does Agile team need a manager? What are the characteristics of an self-organizing Agile team?

Self-organizing should be a vehicle, not a destination. The goal is to deliver the high quality software on value, time and schedule. Also, it's not a binary on/off setting; the calibration is analog so dialing-in the right amount of self-organization is the tough part. Each member of the team simply needs to be given a role and they need to fully understand what is expected of them. It is extremely important that the product owner keeps a steady stream of succinct requirements and allows technical  information flowing into the team (which can be communicated to the group by regular stand up meetings, grooming and constant re-prioritization of the product backlog). Teams in their "Storming" phase should also be monitored.

Self-organizing team effectiveness test: To ensure that your team is self-organizing, you need to leave it in a middle of a project. Real self-organizing team will be more likely successful. The team should be mature and cohesive both personally and professionally
- management should have the courage to trust the team
- trust is made easier by a track record, built up either during the project or as a result of re-using teams that have proven themselves in previous projects. 

Benchmark measurement: If the goal is to assess the efficacy of an Agile initiative, then you should establish assessments around benchmarks that track innovation, software quality, productivity, consumer response, and etc. If the goal is to give continuous feedback to team members so they can improve, then link that feedback directly to those same things or whatever it is, the team values about the software being produced.

Assess the team adaptability. The team capable of self-organization is probably also better at adapting to change. Observe whether the team is solving problems and forming decisions together. Are they respectfully resolving interpersonal conflicts? Do they keep each other informed of their work, so that the team can deliver working software according to their plan? Are they becoming a more cohesive team rather than simply a group of individuals who were assigned to do a job? And you need to have a project tracking tool providing real-time status reports and supporting team collaboration (very important for virtual and remote teams)

Building great software should be the goal. Focus on delivering the quality software, it's better to put attention on the parts of Agile that directly influence software and give less of attention to things that will ultimately take care of themselves in a high-velocity culture, as.achieving team maturity takes time and effort, and you may not be well-served by making self-organization a top-tier goal, and that should be evident in the feedback to developers, the measurements, the reports to senior management, and in the project results.  From team perspective, either self-organizing or not, it is about how to stimulate energies to cultivating innovation, creativity, and the skills required to develop awesome software.

By very nature of Agile, it’s about experimenting, exploring and adapting, from team structure to best practice, and agile team plays pivotal role in developing the next generation of digital organization.

Posted in: Agile,Project Management