Setting Up Global Agile Teams- Empowerment

Problems With Pillar #2: Empowerment
The partnership between team and stakeholders is fundamental. If one side can never say ‘no’ to the other, then it is not a partnership–it is a master-slave relationship where neither party can ultimately get their needs met. The partnership is what opens up the complete domain knowledge of a whole team and places it entirely in service to the organization. 
Two things are needed for a core team to step up to their role in this partnership:
  • Autonomy over their work, with a practical way to make decisions as a group
  • Mentoring to improve their skills in the technical work itself continuously
Empowerment of agile teams is not optional; it is crucial for the high degree of focus and dedication necessary to produce bug-free code sustainably. Mere process rules that a company may institute cannot make people engage to the degree required for producing such high-quality software. Their commitment, creativity, passion, and energy are needed – not just their obedience to rules! No externally imposed discipline is any match for self-discipline. This is the key to agile (and to Lean Thinking), which is entirely missed by so many would-be adopters. [6]
Erosion of “Soft” Skills as First Danger Signal
The first danger sign was the disappearance of retrospectives. Group learning and team unity of purpose must be renewed periodically. This is a very high-leverage activity that solves a great many thorny problems while they are still tiny. The line manager(s) of those on the team should have noted that Joanne was carrying the load for retrospective facilitation, and should have recognized the importance of that skill by helping others get trained to do it well also.
Facilitation is only part of the picture; useful data is needed too. Teams should experiment in every iteration with ways to improve their work, recording data on each experiment. Comet team’s first argument was over how much effort to spend cleaning up the quick fixes in the code when customers were clamouring for new features.
Missing Cooperation Between Departments
Failure to act on issues raised in retrospectives is another problem. The team had repeatedly raised concerns requiring the cooperation of another department, but it was not forthcoming. By letting this issue sit, managers sent a message to the team that it wasn’t necessary. This contributed to the team’s feeling that retrospectives were pointless. A deeper root of this problem is an insufficient, more significant commitment to agile, spanning departments. This is a system problem that the core team cannot solve. Managers need to take the lead here.
In an agile adoption programme, friction between the agile teams and the surrounding organization will occur. The organization evolved to support waterfall teams with handoffs between siloed job functions. It will have to change if the agile teams are to survive. Management’s main job in an agile adoption programme is to watch for the friction points and then adapt the organization to the agile teams

Comments

Popular posts from this blog

Why You Need to Be Specific about Agile Practice Adoption

The Crucial Role DevOps Plays in Change and Configuration Management

Configuration Management and DevOps with Jez Humble and Bob Aiello