Extract from my upcoming book "Directing the Agile Organisation"
The 3rd domain of Agile Business Management develops an organisational structure that promotes the increased communication, trust and empowerment of your teams. The ideal Agile Business Management structure has minimal layers of management between the CEO, or equivalent, and junior team members. By empowering individuals and teams with personal authority & responsibility to deliver the Customers requirements, combined with self-organising teams, a single mid-level manager should be capable of supporting between 5 and 10 teams. A cross-functional team is typically between 5-9 full-time staff and works towards a single specific outcome.
It is possible to have an un-agile organisation structure. By passing work between silo's, matrix organisational structures lack consistent ownership of work, cause poor communication between business areas and increases delays in the work process. Individual business areas within an Agile organisation should contain all the required skills to deliver their Customers (the Business areas Customers, not the Companies Customers) requirements. As additional skills are needed to deliver new requirements, staff with those skills should be recruited or transferred into that business area. Agile organisations can utilise "Centres of Excellence" or "Competency Centres" as a mechanism to ensure that specific skills are consistent across the organisation, but an individual need to be able to utilise their judgement and common sense where appropriate. Common Centres of Excellence include; project management, business intelligence, quality assurance, communications, and risk management. Note: these are skills that be belong to a team NOT separate business areas.
You can expect your organisation to perform better, but only if everyone pointing in the same direction.
The heart of an Agile organisation are multiple small, cross-functional, empowered and in some cases, self-organising teams. Each business area is made up of multiple, cross-functional teams containing all the key skills required to deliver the required outcomes. For example, a team responsible for developing a tender could include sales people, marketers, graphic designers, solicitors, technical writers, pre-sales technical experts, etc. This is different to the traditional hierarchical or matrix management structures where one team would start the process, and at pre-determined stages request input from or hand-over to another team. Benefits to this integration include faster delivery times, rapid response to new issues and improved information sharing across the organisation. However, to effectively realise these benefits requires all team members to be adaptable and committed.
The roles that make up a team should be complimentary and based on the specific requirements of the outcomes. Team members take on various roles within the team based on their expertise and should be brought into a team taking into account the following 5 factors:
- Individual team member will have certain specialisations and while they should be able to take on different roles, they will not be as productive.
- Ideally team members should be able to take on multiple roles, they will not be able to take on ALL roles. You will need a good cross-selection of skills to ensure role coverage.
- There is a productivity penalty for context switching; You want team members to focus on specific roles and switch only as required.
- Staff who can take on multiple roles, tend to be more productive and creative in their work.
- The structure of the team is driven by the requirements and often requires multiple team members in the same role to meet them.
By splitting work into small & manageable iterations of between 1 and 4 weeks, teams can be restructured with different roles regularly and as required. The ensure the correct makeup of roles and skills, each iteration needs to be planned out in reasonable detail. To develop a sense of empowerment & trust as well as to improve the quality of estimation, the team should be responsible for planning out the iteration, including swapping team members to ensure that the mix of skills is correct. By keeping each iteration relatively small, the effort of planning and the risk of wasted effort is significantly reduced.
Reducing delays and work bottlenecks is one of the key benefits to cross-functional and self-organising teams. By individuals changing their primary role on-demand, the team can deliver high-priority work consistently without waiting on external dependencies. By visualising the flow of work through each role, role based bottlenecks are identified quickly allowing for the team to self-correct without requiring management decisions.
Note: The mechanism by which work is delivered and visualised is covered in the next chapter.
Trust and authority is key to developing empowered teams; part of this is ensuring that teams have direct ownership and control of the work, within the bounds set by the Customers requirements. To support the teams ownership of their work and prevent undue interference, Scrum introduced the concept of differentiating between committed and involved parties, light-heartedly called pigs and chickens.
A Pig and a Chicken are walking down the road. The Chicken says, "Hey Pig, I was thinking we should open a restaurant!". Pig replies, "Hm, maybe, what would we call it?". The Chicken responds, "How about 'ham-n-eggs'?". The Pig thinks for a moment and says, "No thanks. I'd be committed, but you'd only be involved!"
The team makes up the committed parties (or pigs), those who are actively working towards delivering the outcomes for the Customer and are accountable for it's outcome. Managers, Customers, Customer Representatives and other Stakeholders are involved parties (or chickens), those who have an interest in the outcome and are consulted and kept informed of status, but are not responsible for day-to-day delivery. If I may stretch the metaphor, It is the pigs whose "bacon is on the line" if the task doesn't get completed on time or to the Customers satisfaction. A successful project needs both pigs and chickens, however a successful team must have sufficiently empowered "pigs" in return for taking accountability for delivery.
As with everything, cross-functional teams are not without their risks. Teams that are understaffed may not be able to deliver all the requirements that the Customer needs, a team may be lacking specific skills to fill a required role, or Individuals may be unable to dedicate the time required to the team, either through unplanned leave or other corporate (non Customer) requirements. By being aware of the risks they can be mitigated by allowing the team to estimate and plan each iteration, delaying requirements until a team member with a specific skill-set is available, clearly communicating with the Customer to set their expectations up-front and putting in place good staff redundancy measures.
So far we have mostly talked about the delegation of authority to empowered teams; what then, is the role of management in an Agile Organisation. Each business area, whether it supports internal or external Customers needs to be managed at an appropriate level. To continue the example from earlier, a HR department may have 2 teams and multiple internal Customers, but still requires a single manager who is responsible for staff performance management, initial Customer & stakeholder engagement, and financial management & delegation. Ultimately, however, the Agile Manager is responsible for empowering, inspiring and leading their teams (see You, The Agile Manager)
Image is CC BY NC - PaDumBumPsh (Flickr)