CHAPTER 3: THE STRUCTURE OF AN AGILE
ORGANISATION

‘Make everything as simple as possible, but not simpler.’ Albert Einstein (paraphrased), 1933

Aim of this chapter: To provide the organisational context in which Agile, and Agile Business Management, operates. We will look at the lean management structures that provide oversight, set goals and manage risk, whilst remaining flexible and adaptable. This chapter will also describe many of the specific management techniques needed to manage different types of Teams, Departments, and companies, in an Agile way.

The third domain of Agile Business Management is an organisational structure that promotes increased communication, trust and empowerment of your Teams. The ideal Agile Business Management structure has the minimum layers of management between the CEO, or equivalent, and junior Team Members, whilst still remaining efficient and functional. By creating self-organising and cross-functional Teams made up of individuals empowered with personal authority and accountability, a single, mid-level manager should be capable of supporting between 10-20 Teams. Each cross-functional Agile Team is typically between 5-9 full-time staff, where the whole Team works towards a single, specific outcome.

	Cross-Functional: Where individuals with different, and complementary, skills, work together as a Team.
	Self-Organising: The responsibility of the Team to create a functional, internal Team structure, by replacing, and reorganising, Team Members as needed.

As shown in Figure 6, the heart of your Agile organisation is the many small, cross-functional, empowered, and in some cases, self-organising Teams. Each Team should contain all the key skills required to deliver on their Customers’ Requirements. Benefits to this integration include faster delivery times, rapid response to new issues, and improved information sharing across the organisation. However, to realise these benefits requires that all Team Members are committed to the outcome, and adaptable in their role. 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 handover to, another Team. By passing work between silos, strict matrix organisational structures lack consistent ownership of work, cause poor communication between departments, and increase delays in the overall process.

	You can expect your organisation to perform better under Agile Business Management, but only if everyone is pointing in the same direction.
	Example Cross-Functional Team: A Team responsible for developing a proposal and quote for a new Government client, could include sales people, marketers, graphic designers, solicitors, technical writers, pre-sales technical experts, etc.

While the design of Agile Business Management is adaptable, to almost any organisation, to take advantage of the benefits, your organisational structure must be conducive to good communication and staff engagement.

Individual departments within an Agile organisation should contain all the required skills to deliver their Customers’ (the department’s Customers, not the organisation’s Customers) Requirements. When your Teams identify that additional skills are required to deliver a new Requirement, they should have the authority to recruit, or transfer, staff with those skills into their Team. Agile organisations can utilise informal ‘Centres of Excellence’, or ‘Competency Centres’, as a mechanism to ensure that specific skills are managed and developed consistently, across the organisation. However, an individual needs 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.

Create Centres of Excellence around skills that belong to a Team, rather than separate departments.

By consolidating the Customer Requirements into a specialised Requirements Backlog (see section: Requirements and the Requirements Backlog), new Teams can be dynamically established outside of traditional reporting hierarchies and departments. This is most useful to deliver project-based outcomes, or to develop prototype products for business research and development. After delivering their Requirements, you can either convert temporary Teams into a new department, or transfer them into an existing one.

Remember Agile principle #11: The best architectures, requirements and designs, emerge from self-organising Teams.

The skills that make up a Team should be complementary, and specified by the Requirements of the Customer. New and existing Team Members take on various roles within the Team, based on their expertise, and taking into account the following five factors:

1  Individual Team Members will have specialisations and preferences, and whilst they should be able to take on different roles, they may not be as productive.

2  Team Members should be able to take on multiple roles, though they will not be able to take on ALL roles. You will need a good coverage of skills to ensure role coverage.

3  There is a productivity penalty for context switching; you want Team Members to focus on a specific role, and switch only as required.

4  Staff who can take on multiple roles, tend to be more creative in their work.

5  The Customer’s Requirements drive the structure of the Team, and often require multiple Team Members in the same role to meet them.

Example Cross-Functional Team: A Team responsible for developing a proposal and quote for a new Government client may change during different Iterations of work.

By splitting Requirements into small and manageable parts, suitable for Continuous or Incremental Delivery, Teams can be restructured with different roles regularly, and as required. To ensure the correct distribution of roles and skills, your Teams need to plan each Iteration out in reasonable detail. Each Team should be responsible for planning the Iteration; including replacing Team Members, to ensure the correct combination of skills.

	Incremental Delivery: Planning and delivering related Requirements in short, fixed-time blocks.
	Continuous Delivery: Planning and delivering related, or unrelated, Requirements as they are identified and prioritised.

Reducing delays and 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 Requirements consistently, without waiting on external dependencies. By visualising the flow of work through each role, the Team can quickly identify bottlenecks, allowing them to self-correct, without requiring management decisions.

The next chapter covers the delivery and visualisation of Requirements in more detail.

Trust and authority are important factors in developing empowered Teams; this can be encouraged by ensuring that your Teams have direct ownership, and control, of their work, within the bounds set by the Customers’ Requirements. To support the Team’s ownership of their work, and prevent undue interference, Scrum introduced the concept of differentiating between Committed and Involved Parties.

The Team makes up the Committed Parties, those who are actively working towards delivering Requirements for the Customer, and are accountable for its outcome. Managers, Customers, Customer Representatives and other Stakeholders, are Involved Parties, 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. A successful outcome needs both Committed and Involved Parties; however, a successful Team must be sufficiently empowered, in return for taking accountability for delivery.

As with everything, cross-functional Teams are not without their risks. Understaffed Teams may not be able to deliver all the Requirements that the Customer needs. A Team may be lacking individuals with needed, specialised skills, or individuals may be unable to dedicate the time required to the Team, through either unplanned leave, or other corporate (non-Customer) requirements. By being aware of these, and related risks, you can put in place simple resource mitigation strategies. For example, allowing the Team to estimate, and plan, each Iteration themselves, delaying Requirements until a Team Member with a specific skill-set is available, clearly communicating with the Customer to set their expectations upfront, and putting in place good staff redundancy measures.

A possible mitigation strategy for some of these risks is to ensure that your organisation has a central skill register that all Team Members are responsible for keeping up to date. Noting, of course, that staffing is a highly complex issue, and has long-term impacts on Teams if poorly managed. The skill register should list the professional processes, techniques and technologies that Team Members are experienced in, their level of capability, and any related information (such as education or qualifications). This register should be centrally located and visible to all staff, to help Team Members self-organise, by identifying who, in your organisation, has the skills needed to deliver on their Customer’s Requirements.

Estimate: The process of calculating the effort required to deliver a Requirement.

When recruiting for an Agile organisation, you need to place greater emphasis on people and communication skills. You are looking for staff that fit the Team culture, can accept accountability, do not require micromanagement, are multi-skilled, and can take on additional responsibilities as required. Where possible, you should never recruit new staff only to fill an immediate need. New staff should be engaged strategically, and time taken to integrate them into your organisational culture.

Your Agile HR Department should be working very closely with the Teams, their Customer, to ensure Requirements are being met. This engagement model means that each Team shares the authority for hiring candidates, and, as such, is ultimately accountable for that decision, and for hiring suitable candidates, with suitable skills, for their Team.

So far, I have mostly talked about the delegation of authority to empowered Teams; what then, is the role of management in an Agile Organisation? Each department, whether it supports internal or external Customers, needs management at an appropriate level. To continue the example from earlier, a HR Department may have two Teams, and multiple internal Customers, but still requires a single manager who is responsible for staff performance management, initial Customer and stakeholder engagement, and financial management and delegation. Ultimately, it is you, the Agile Manager, who is responsible for empowering, inspiring and leading their Teams (see Chapter 1: You, the Agile Manager).

Case study: IT Branch, City of Edmonton -Building an Agile organisation! IT Branch, City of Edmonton: The IT Branch is responsible for managing, and maintaining, the IT investment across the City of Edmonton. Consisting of 340 people, five sections, and almost $60m in operating budget, the branch works with business units to help them translate business needs into technology solutions. Operating as a shared service, their primary Customers are the internal business units that make up the City functions, such as fire, waste management and public transit. In 2008, the IT Branch received feedback from City staff and business leaders that they were not meeting service delivery expectations. To address these issues, and the related underlying causes, an enhanced, and sustainable, service delivery model was created. This model of service delivery, leadership and engagement was built around the following principles; listen, support, encourage and, most of all, deliver. This new service delivery model was adopted by mid-2009, after significant engagement with all staff. To bring about the cultural changes needed for this new model, the IT Branch has spent the past four years undertaking business transformation, establishing structural change, educating staff, and implementing new processes. The problems: The two major problems that originally catalysed the transformation of the IT Branch were identified in the 2008 annual Customer survey and biennial employee survey. 1  Customers’ needs were not being met. 2  The staff environment was fostering low morale. These problems became even more apparent as people came to understand that the current approach to managing IT in local government was no longer working. That is, traditional approaches to building permanent systems no longer aligned with how things were functioning in reality. Ultimately, with the City demanding so much of the branch, there was no other option but to attempt an Agile and flexible solution. The causes: Over time, the City (which is now 107 years old) had become a very hierarchical, command and control organisation. This fostered an environment in which people did not feel encouraged to take responsibility for their actions, and was not suitable to meet the new challenges, and rapid evolution, in IT. In addition, staff had much greater understanding, and expectation of technology than in the previous five or 10 years. As a result, the IT branch was constantly struggling to keep up with changing demands. These problems, and their causes, are not unique to Edmonton. They are common across local government, and certainly exist in many other organisations. The solution: Over the last few years, there has been a huge reset in terms of people’s expectations of leaders. People started to ask; ‘How did leaders let it come to this?’. This led to a shift in thinking within the City, towards a new leadership model that encourages co-creation, engages staff, and leverages people’s intrinsic motivations. The solution was to move away from the concept of a delivery manager (such as a client solution manager, or an infrastructure services manager), as these types of managers were often much better as technical experts, than as effective people managers. Structurally, the IT Branch went from seven directors to five, and from 31 managers, 11 of which managed no people (Figure 7), down to 20 technical managers and six coaches (Figure 8). A key part of the new structure involved taking a group of IT professionals, who could also be people managers, and converting them into coaches, responsible for engaging with staff and driving the cultural change. Figure 7: Pre-transformation organisation chart Figure 8: Current organisation chart In parallel to the structural changes, the branch created a resource management office (RMO) to streamline the management of staff assignments. Operationally, everyone reports to the RMO, and is assigned to work based on their knowledge, skill, ability and availability. This is a very complex and difficult function, and the branch is still working to improve it. Finally, the creation of the RMO means that staff understand that the person they are working with today, might be reassigned to another project with a higher priority. From a cultural perspective, it was important for the branch to keep using the word ownership. Historically, there hadn’t been the concept of personal ownership; that outcomes weren’t just the manager’s responsibility, but everyone’s responsibility, in different ways. The final aspect to the new model was to change the way projects were implemented within the branch. Instead of an active Project Management Office (PMO) guiding the delivery of each project, the responsibility for project delivery, and the project resources, was put back into the delivery units. The PMO was retained, but their responsibility was refocused on providing oversight, and managing processes and standards. The implementation: As an approach to sustainable service delivery, the IT leadership team came together in March 2009 and proposed, what was then, the Agile Service Delivery (ASD) model. However, the response to the initial presentation of the ASD model to the IT Branch was almost universally underwhelming. People didn’t respond to it, and the consensus was that it would be like all the other ‘re-orgs’, lots of talk, but nothing would change. This led to the realisation that, to the staff, it looked like the leadership team had gone into a room, cooked up a solution, and presented it to the branch as a ‘fait accompli’. In April 2009, it was decided that a new approach was needed. This resulted in a series of 30 town hall meetings, each with 10, randomly selected staff attending. The goal of these town hall meetings was to give staff an opportunity to talk about the current state, and their vision of the future. In planning for these meetings, it was decided that what was discussed at each meeting would be posted for ALL to see. That was the first step to being transparent. At the beginning of each meeting, the two goals for the transformation were articulated to the staff, in order to provide context. These were: 1  To create fulfilment in their work. 2  To provide them with the freedom to do what they knew needed to be done. In order to remain Agile and flexible, the original plan for an ASD model was put aside at the beginning of the town hall process. By the conclusion of the town hall meetings, the branch had adopted a model similar to ASD, but developed through co-creation with an engaged workforce. The major difference between the original ASD and the current model, was to move responsibility for project delivery from the PMO to operations staff, in order to retain, and share, experience. At the conclusion of the town hall process, the entire branch met, to draw together all of the discussions, and chart a way forward. It was at this point that the leadership team sat down with HR, the unions, and other resources, to discuss the implications of the model. Using value management as a framework, the leadership team was then able to map from the values, and the ‘10 Ways of Being’1, to the business model. From that, developed the mission and vision statement that was circulated to the whole branch for discussion. In mid-2009, a project manager was engaged to formally manage the process of restructuring the branch, one level at a time. The project manager was responsible for the practical aspects of the transformation, such as the plans, rewriting the manager’s job descriptions, creating the coach positions, moving people around, etc. The branch restructure also emphasised the need for good governance from the IT leadership group. To ensure that all the directors were on the same page, and common issues were discussed, a regular leadership forum was established. It wasn’t until early 2011 that the project manager was assigned off the transformation. The change had reached a self-supporting stage, where it had become everybody’s responsibility, not just the project manager, or the leadership team. The challenges: Most of the challenges faced during the early stages of the transformation, related to people’s ability to cope with the change, and continue to operate in the new IT Branch. The continuous change experienced within the branch transformation, led to a sense of instability, or insecurity, for staff. This was further compounded by the anxiety caused by unsubstantiated rumours and general speculation. Communication, and the overall communication strategy, became an integral part of the branch’s ability to be Agile. Changing people’s view from ‘Oh, that didn’t work, so we’re trying something else now’ to ‘This is another aspect of our journey’. It would be incorrect to assume the branch has been 100% successful, but creating, and maintaining, a relationship of trust with staff, has built confidence in the transformation, and with the leadership team. In addition to managing challenges at a group level, there was also the challenge of managing individuals. Many people had individual issues and concerns that blocked their ability to be successful. This is where the coaches became involved. The coaches were responsible for working closely with people, and addressing their individual concerns. Of course, this had to be balanced with the risk of spending all your time with the high needs people, and losing sight of the mission. A good example of this is that people, in general, don’t do a good job of holding other people, or themselves, to account. In the past, the hierarchy was the mechanism that held people to account. However, when the transformation moved away from that model, it became each staff member’s personal responsibility to follow up, or recommit. At the far end of the spectrumwere those staff who did not engage. Those that said, ‘I don’t come to work for fulfilment, I come to work for the pay cheque’. This meant that the process of hiring people became very important. New recruitment priorities have been put in place to ensure that new staff don’t just fit with the culture, but are going to help the branch move forward with the culture. Finally, there have also been structural challenges within the transformation. The roles and responsibilities of the RMO have been widely accepted, and it is understood that without it, the branch doesn’t have the flexibility to move people to where they are needed. However, in many cases, a manager will still ask for a specific person, rather than whomever the RMO sends. For this to be properly resolved, an ongoing, and involved, cultural shift is required. The outcomes: As of early 2013, the IT Branch transformation has been in progress for over four years. Though worthwhile, the transformation has not been an easy process. It took several years for the directors and managers to get on board with the changes. Overall, the branch has reached a state where those who don’t understand, and don’t engage, are the odd ones out, responding in a different way to most of the others. This is true of both leaders and staff. The best evidence for the success of this transformation is shown in the upwards trend, in terms of satisfaction, engagement and understanding, in the 2012 customer and employee surveys. Over the last few years, in addition to the branch transformation, the entire City has adopted new, co-created, leadership principles. This new corporate approach aligns closely with, and validates, the approach taken by the IT Branch, to the point that the language is similar. While this transformation has been a success, there is still work to do in some areas. People ask ‘When is the transformation going to be over?’, and our answer is, ‘Once started, it never ends’. - Chris Moore, CIO, City of Edmonton

Internal departments

‘A new type of thinking is essential if mankind is to survive and move toward higher levels.’ Albert Einstein, 1946

As an Agile Manager, you are responsible for one, or more, business functions or departments. Each department typically divides the organisation into functional areas, each with different outcomes, Customers and ways of working.

Human Resources

Human Resources (HR) is responsible for staff recruitment, salary management, and implementing management policies within an organisation.

•  Typical products: HR policy documents, position descriptions, and job advertisements.

•  Typical processes: Managing applications, verifying claims, personality tests (e.g. Belbin or Myers Briggs), industrial relations negotiations, salaries, separation procedures (both voluntary and involuntary), and performance management.

•  Optional processes: Occupational health and safety, career counselling, and staff training.

•  Frameworks and guidelines: Equity and Diversity legislation.

•  Typical Customer: Internal departments.

•  Stakeholders: Finance and Accounting (budget), Media and Communications (external advertisements).

•  Work style: Ad hoc, suitable for Continuous Delivery.

The responsibilities of HR do not change dramatically under Agile Business Management, though there may be significant cultural changes. Changes are primarily to workflow, transparency and Customer interaction.

ICT Support and administration

ICT Support is responsible for the day-to-day administration of IT assets, including infrastructure (desktops, telephony, servers, network), and software (applications, the Internet/intranet, operation systems). Large organisations will generally have tiered support, and may even outsource the first tier (help desk).

•  Typical products: ICT infrastructure, standard operating environment.

•  Typical processes: Help desk support, system upgrades, preventative maintenance, system (e.g. desktop, telephony, etc.) provision, testing/installing new products.

•  Optional processes: CT project management.

•  Frameworks and guidelines: Product administration guidelines, ISO20000.

•  Typical Customer: Individual staff members (via help desk), internal departments.

•  Stakeholders: Privacy and security (policy and audit), Finance and Accounting (budget and procurement).

•  Work style: Mostly ad hoc, suitable for Continuous Delivery. Some project based (e.g. system upgrades), suitable for planned Incremental Delivery.

The role of IT Support and Administration does not change dramatically under Agile Business Management. Like HR, changes are primarily to workflow, transparency and Customer interaction. Outsourced help desk functions can continue to be outsourced, but you will get improved interaction by removing, or making, the first tier transparent, and ensuring that support Teams are physically located in the same building as their Customers.

Sales and Marketing

Sales and Marketing Teams interface between consumers (or Customers) and the Delivery Teams. They are responsible for the promotion, pricing, market research, lead generation, and sale of your products and services. Effective Sales and Marketing Teams will interact closely with your Customers, through shop fronts, online websites, social media, or professional networks. Sales and Marketing also work closely with the Delivery Teams, to ensure that the outcomes meet Customer needs or expectations.

•  Typical products: High-level product requirements, packaging.

•  Typical processes: Lead generation, market research, setting prices, promotion, professional networking, presentations (e.g. conferences and trade shows), sales (online, shop front, or B2B), distribution.

•  Optional processes: Advertising campaigns, social media, Customer service.

•  Frameworks and guidelines: Relevant legislation.

•  Typical Customer: The organisation (represented by the senior executive). Depending on your organisation, the Delivery Teams can be a Customer, but the converse is also possible, where the Marketing Manager is the Customer of the Delivery Teams.

•  Stakeholders: Media and Communications (branding and advertising), Finance and Accounting (budget and cashflow).

•  Work style: Ad hoc. Suitable for Continuous Delivery.

Sales and Marketing often work in an Agile way already, so under Agile Business Management their role may not change significantly. For B2B products, sales staff are still responsible for lead generation, but handover to the Delivery Teams is much earlier. Remember, Delivery Teams have the responsibility for working directly with the Customers. For B2C products, the marketing manager may become the Delivery Team’s Customer, with the additional responsibilities that entails. There is minimal change to consumer sales Teams, e.g. shop front staff.

Finance and Accounting

Finance and Accounting is responsible for the management of all the financial and monetary aspects of the business.

•  Typical products: Annual budget, tax returns, payroll.

•  Typical processes: Cashflow management, managing accounts, shares management, short- and long-term investments, managing depreciable assets, raising capital (shares and loans).

•  Optional processes: Procurement, Forex markets and currency conversion, international trade.

•  Frameworks and guidelines: Relevant tax and accounting legislation, CPA, or equivalent guidelines.

•  Typical Customer: The organisation (represented by the senior executive), the taxation office.

•  Stakeholders: Everyone.

•  Work style: Long-term planned work, suitable for planned Incremental Delivery.

The role of Finance and Accounting does not change dramatically under Agile Business Management. Changes are primarily to workflow and transparency.

Media and Communications

Media and Communications are responsible for interacting with the public, public relations, media press releases, brand awareness, and occasionally, social media.

•  Typical products: Press releases.

•  Typical processes: Press conferences, public relations.

•  Optional processes: Social media interaction, corporate website.

•  Frameworks and guidelines: N/A.

•  Typical Customer: Sales and Marketing, senior executive, Delivery Teams.

•  Stakeholders: External media.

•  Work style: Mostly ad hoc, suitable for Continuous Delivery. Some project based (e.g. advertising campaigns), suitable for planned Incremental Delivery.

Under Agile Business Management, all staff share the responsibility of interacting with the public, especially when dealing with consumers, and the public, in the social media space. The role of Media and Communications in relation to brand and media affairs does not change dramatically. The standard changes to workflow and transparency apply to these Teams as well.

Legal

Legal support teams generally provide regulatory, liability, and indemnity advice, as well as draft, or review, contracts between the organisation and its Customers. In the extreme case, they will respond to legal action taken against the company.

•  Typical products: Commercial contracts.

•  Typical processes: Provide legal advice, ensure regulatory compliance, intellectual property management, overall risk management.

•  Optional processes: Manage litigation, acquisitions and mergers.

•  Frameworks and guidelines: Relevant legislation, bar association guidelines.

•  Typical Customer: Sales and Marketing, senior executive, Delivery Teams.

•  Stakeholders: Everyone.

•  Work style: Advisory Requirements are generally ad hoc, suitable for Continuous Delivery. However, most Requirements for the legal team are larger, and are suitable for Incremental Delivery.

The role of the Legal Department does not change dramatically under Agile Business Management. Like HR, changes are primarily to workflow, transparency and Customer interaction.

Research and Development

Research and Development (R&D) Teams are internally focused, and are responsible for improving existing products and services, as well as creating new ones.

•  Typical products: Context specific. For example, a clothing producer may research faster production methods, new materials and new designs.

•  Typical processes: N/A.

•  Optional processes: N/A.

•  Frameworks and guidelines: N/A.

•  Typical Customer: Delivery Teams, senior executive.

•  Stakeholders: Consumers (research), Finance and Accounting (forecasting and planning).

•  Work style: Mid- to long-term planned work, suitable for planned Incremental Delivery.

While R&D’s core responsibilities remain the same, under Agile Business Management, R&D products are delivered rapidly, and often in close alignment with the Delivery Teams. By empowering Delivery Teams to work closely with the Customer and consumers, you may be able to incorporate R&D responsibilities directly into the Delivery Teams.

Production and Operations – Delivery Teams

Generally, Production and Operations are the largest department in an organisation. Responsible for building core products, and/or delivering core services, Production and Operations are the reason your organisation exists.

Delivery Teams: An internal department responsible for building core products, and/or delivering core services. Due to the highly variable range of responsibilities for Production and Operations Teams between organisations, Agile Business Management simplifies this by calling them all ‘Delivery Teams’.

•  Typical products: Context specific. For example, a clothing producer will produce clothing, and a financial services company will buy and sell shares for their clients.

•  Typical processes: Materials procurement, resource scheduling, production cost management, production forecasts, quality control.

•  Optional processes: Staff procurement, plant location and layout.

•  Frameworks and guidelines: ISO9000, CMMI.

•  Typical Customer: External clients, Sales and Marketing, product manager.

•  Stakeholders: Everyone.

•  Work style: Context specific. Can be ad hoc, suitable for Continuous Delivery, or long-term planned work; suitable for planned Incremental Delivery.

The majority of Agile Business Management changes occur within the Delivery (Production and Operations) Teams. These include greater Customer interaction, direct responsibility for delivery, and implementing Continuous or Incremental Delivery processes. In fact, most of the processes in this book apply to these Teams.

Other departments

This is by no means an exhaustive list of potential business functions or departments. Other departments can include; Project Management, Office Management, Facilities Management, Real Estate, Filing and Records Management, Secretariat, Business Intelligence, Libraries, etc. Applying the core Agile concepts and processes from this book, any department, or business function, can improve their agility, adaptability and engagement.

The Board and executive governance bodies

‘The office of director ... a man ought not to fill without qualification.’ Lord Selborne, 1873

The governance of an organisation is more than just the management of its constituent departments. In larger organisations, oversight and overall governance sits with the Board of Directors, and through them, the CEO. As the company charter defines the Board’s size, structure and administration, most organisations transitioning to Agile Business Management do not have the luxury of changing the Board.

However, for wide-scale adoption, the Board need to act as champions of Agile Business Management, and the same principles that govern the rest of the organisation, should govern them. Corporate objectives and policies set by the Board should be adaptable, iterative, testable, and able to take advantage of the dynamic marketplace. Measuring the performance of the organisation, and its CEO, should be based on Agile metrics (see section: Managing Teams) which, in turn, aligns executive remuneration with Agile KPIs.

The Board needs to be involved in the development of the Agile corporate strategies, and is responsible for monitoring the integrity, and effectiveness, of the Agile Business Management practices.

In addition to their legally binding responsibilities, Agile Boards need to apply greater due diligence to the governance of their organisation. This is not due to a lack of trust in their chosen executive, but because an Agile organisation can, and will, adapt and change rapidly. Because of this, the Board needs to work closely with the executive, to remain informed, so they can make appropriate governance decisions.

In order to deliver on their Agile obligations, the Board should expect greater transparency and communication from the organisation and the executive. This, in turn, improves their ability to act, in good faith, in the best interest of the organisation and its shareholders.

Management within an organisation is the responsibility of the CEO, although this is usually delegated to Department heads (see section: Internal departments), or specific executive governance committees. These executive committees provide oversight and guidance on complex issues within the organisation, and traditionally meet every two-three months for several hours, with ‘out-of-session’ meetings as required. Examples can include:

•  Investment committee: Appointed (and usually chaired) by the CEO, the investment committee is responsible for approving major capital investment decisions across the organisation. By bringing stakeholders together, the investment committee reduces the risk of poor investment decisions.

•  Information management committee: Appointed by the CEO or CIO, the information management committee is responsible for governing the information assets of the organisation. This highly complex issue often crosses Departmental bounds, so an expert committee can provide specialist advice and coordination.

•  Compensation committee: Appointed by the Board of Directors, the compensation committee researches, and sets, the remuneration of the company’s executive. This external committee reduces any perceived conflict of interest on this sensitive topic.

•  Project steering committee/working committee: Ad hoc groups, created to oversee a specific project, event, or organisational issue.

Agile Business Management encourages the use of executive committees, to manage these complex issues for large organisations. They can be very effective as a mechanism for coordination and communication. However, like most other Agile processes, they should be fast, regular, and iterative.

For example, a traditional committee may meet every two months for four hours, whereas an Agile committee would meet every two weeks for one hour. Under this model, they meet for the same total duration, but with greater regularity, to take advantage of emerging business opportunities. Other characteristics of Agile meetings, as defined in section ‘The Daily Stand-up and Agile meetings’, should apply to executive committees as well.

Case study: New Zealand Post Group – An Agile executive! New Zealand Post Group (NZPG) consists of a range of businesses, providing communication and business solutions to the New Zealand public and businesses, across all sectors and industries. Products and services range from the core mail business, through to banking and digital solutions. NZPG, like many businesses after the global financial crisis, undertook a business review, and identified that there were a number of missed opportunities to respond to customer and market trends. It was realised that these opportunities would continue to be missed while the organisation was ‘stuck’ in old modes of operation. In late 2011, the Group Leadership Team, consisting of the Group CEO, CFO, Group Heads and General Managers, began a transformation and continuous improvement programme, to improve the overall responsiveness of the organisation. This transformation led to the creation of the Sorting Room, a visualisation of the state of the organisation and its strategic initiatives, as well as related cultural and process changes. This new approach to corporate strategy emphasised simplicity, visibility and trust, and ultimately changed the way the NZPG Executive operates. The problems: The need to be more responsive to changes in customer behaviour, and changes in the marketplace, was the primary stimulus for organisational transformation. Long feedback cycles were limiting the ability for the organisation to execute, and communicate, corporate strategy, which, in turn, limited its responsiveness. Historically, the monthly executive board meetings were not effective at resolving organisational issues, or driving strategic change. These meetings usually lasted all day, with agendas filled with lengthy and unwieldy ‘FYI’ papers, that were often unrelated to the goals of the Group Leadership Team. The result was that participants would lose focus, and, after a certain point, ‘the will to live’. The rapidly changing business environment was the final catalyst for this transformation. This needed a new approach, where the focus was on solving problems from a group perspective, rather than the traditional siloed one. The solution: To address these problems, the Group General Manager of Innovation identified that the organisation needed a collaborative, problem-solving and decision-making environment, and so the ‘Sorting Room’ was born. Drawing on Agile, Lean Six Sigma and Systems Thinking methods, the Sorting Room is a dramatic change in the way the Group Leadership Team operates. It is a central space that provides oversight of the strategic initiatives of the organisation, and it is reinforced with a weekly forum for the Group Leadership Team, to debate the strategic challenges facing the business, as well as emergent incidents and risks. Each strategic initiative (such as revenue growth, business improvement and leadership) is allocated to an executive to champion. This person (and their group/division) is responsible for the delivery of the initiative, and the programmes of work underneath it. These programmes of work are rigorously monitored, and have strong gating processes, especially those programmes with large capital investment. The weekly Sorting Room meeting starts by focusing on the impediments to success from across the business, particularly anything that affects staff. This is followed by the main agenda; an in-depth analysis into two of the strategic initiative programmes, by the relevant, responsible executive. The Sorting Room meetings are not meant as a status report. It is an environment where the executive can share information and help each other. This means that if an in-depth analysis is put on the agenda, it is because the responsible executive has an issue to solve, and wants the help of their peers. As a final step, the impact of each completed strategic initiative is measured against predefined metrics. These are an important part of the feedback loop, and ensure that the initiatives lead to quantifiable outcomes for the organisation. Table 1: Differences between the old and new states   Old state New state Environment Boardroom War room Timeframes Monthly (5-6 hours) Weekly (2 hours) Structure Hierarchical Flat (External facilitator) Focus FYI, Proposals Problems, Questions Pre work Many papers 2  issues Style Written, Formal Visual, Engaging Ambience Corporate Informal Criteria Push Pull Visibility Low High Figure 9: The Sorting Room workflow The room itself contains a view of all the strategic initiatives, and associated work, across the organisation. There are five main areas to the room. 1  The Sorting Wall (Figure 10) is a Kanban Board that displays each strategic initiative across the wall. This is then split into the relevant stages; work that has started, work underway, impediments, and done. Attached to this is a listing of the key metrics (e.g. financial spend) for each of the strategic initiatives. Figure 10: The Sorting Wall 2  The Scale Wall (Figure 11) provides a heat map of key activities across the top 10 strategic initiatives. By focusing on the programmes of work against time, the Scale Wall shows potential bottlenecks, and the impact of the initiatives on staff. Figure 11: The Scale Wall 3  Next to the Scale Wall is a small information area, to remind the executive of the rules of the Sorting Room, what they are here to do, as well as general information, such as how much each meeting costs. 4  The final wall contains some clear working space for the topics under discussion. 5  Finally, there is a stylised elephant (Figure 12) on one wall, that represents ‘the elephant in the room’. If anyone feels a topic is being ignored, or going unaddressed, they can attach a card to this wall, to raise it at the next Sorting Room meeting. Figure 12: The elephant in the room Each task on the Kanban Board is represented by a sticky note. Each note is colour coded according to the strategic aspect (e.g. people, process, customer, and finance) that the activity will affect. Additionally, to foster a culture of accountability, a photo of the responsible executive is attached to each note. This means that the Group Leadership Team can simply look at the wall, and determine the mix of impact across time, as well as who is responsible. In order to promote a culture of transparency beyond the Group Leadership Team, the Sorting Room is available for anyone in the organisation to access and use. What has been found, is that teams will often use this room to hold their team meetings. The only difficulty this creates is that confidential, strategic initiatives have to use a code name, such as if the NZPG is doing a divestment or acquisition. Finally, a senior manager within the organisation was selected to take on the responsibilities of the Executive Scrum Master. This person is responsible for facilitating the Sorting Room meetings, using an adapted Agile format, and utilising the above Kanban techniques. Given the sensitive nature of the Sorting Room meetings, it was important that the facilitator was somebody the Group Leadership Team could trust. The implementation: The Sorting Room was implemented in response to the challenge to find a better way to enhance collaboration between the Group Leadership Team in order to solve business problems, rather than the traditional ‘boardroom’ format. The challenge was accepted, and implemented, on one condition, they all agree to trial it, come what may, for at least six months. It was important that the transformation was effective, without being expensive. By leveraging internal talent, such as using the Business Improvement team to manage the implementation, and the design team to create colourful and appealing walls and plans, NZPG was able to implement the initial version of the Sorting Room and related processes within three weeks, with a minimal budget. By engaging the Executive Scrum Master early on in the transformation process, the Group Leadership Team was guided through the new processes. This negated the need for any major training, beyond a brief introduction to the Sorting Room. During the initial phase, the Head of Corporate Affairs was included, to communicate the changes across the organisation. They were responsible for broadcasting a monthly communiqué to all staff on what the ‘Sorting Room’ was, and the range of issues being addressed by the Group Leadership Team. The implicit message was: ‘There is a new place and process to go through to get decisions from the Group Leadership Team, and it is very different from the previous format’. The transformation itself adopted an iterative approach. The new processes were trialled based on a ‘pure’ Agile format, and then reviewed every six months to meet the current needs, and ways of working, of the Group Leadership Team. Within the first six months, the Group Leadership Team was starting to realise the benefits of the Sorting Room. Through strong, robust conversations around strategy, there was greater visibility and collaboration between the executives, that, in turn, led to concrete actions being undertaken. By the end of 12 months, the Sorting Room had been enhanced to include focus on impediments, new visual cues on the Kanban Boards, as well as the new Scale Wall. The challenges: Initially, there was some resistance to the change, especially when the level of transparency became evident. The impact of having your photo attached to a post-it on a wall that anyone in the organisation could view, was powerful. This has led to the executives being significantly more open, and receptive, to being held accountable by their ‘team’. NZPG was also in the midst of changing from a federated business model, to a unified group. Therefore, the executive transformation also had to contend with the cultural lag associated with this organisational change. Outside the executive, the only people who directly experienced this transformation were those presenting papers. Because of the shift in focus to problem solving, not all presenters received an easy ride. Those that were contributing to solutions had a more positive experience. The outcomes: Overall, the outcomes have been very positive, with substantial improvements compared to the original format. There are fewer FYI papers, and a greater focus on problem solving. There has been a tremendous impact on the level of collaboration, as the executive benefits from weekly meetings, and see each other far more frequently. There is a real sense that the executive are working as a team. There has also been a noticeable difference in behaviours amongst the Group Leadership Team. The time estimations of actions have become more realistic, as has the substance of the actions. The executives are significantly more open, and receptive, to being held accountable by their ‘team’. The introduction of the Sorting Room has also had a pervasive effect on the wider organisational culture. There is a greater emphasis for the executives to work as a single team, rather than the traditional siloed approach. This has led to a greater understanding of each other’s problems, and a collective ownership of responsibility. Finally, the effect of going through the new process, and the associated level of visibility, has meant that this format has begun to be mimicked across the organisation. The Sorting Room will continue to be optimised to get the best from the Group Leadership Team. Change takes time, even at executive level, and after the initial resistance by some, all are on board, and taking part in making the Sorting Room work. - Paul Reid, Group GM Innovation, New Zealand Post Limited - Jake Porterhouse, Executive Scrum Master, New Zealand Post Limited

Pair Work

‘If you don’t know where you are going, you will probably end up somewhere else.’ Lawrence J Peter, 1977

The concept of Pair Work draws directly from the Pair Programming technique, as defined by the Extreme Programming Agile development framework. In this technique, each Team member works as part of a pair, at a single workstation. Each person in the pair is either the ‘Driver’ or ‘Observer’, and has specific responsibilities. The Driver is responsible for doing the work, be that writing, developing, building, etc. The Observer is responsible for advising, and reviewing, the work. Each person in the pair switches roles frequently, usually about every 30 minutes, and they form new pairs each day. Figure 13 shows how each person in the pair changes throughout the process.

By separating the two responsibilities, the Driver can focus on developing the current Task as quickly as possible, whereas the Observer considers the bigger picture, and can suggest ideas for improvement, and identify likely, future problems. The act of observing improves discipline in the Team, both by reducing wasted time (e.g. surfing the web or checking e-mail) and improving attention to detail (e.g. writing supporting documentation, or recording outcomes). However, the major advantage of Pair Work is the overall reduction of defects created that need to be resolved later.

In general, Pair Work provides a major increase in quality, at the cost of a minor decrease in speed.

Whilst there are no formal studies in Pair Work outside the software engineering disciplines, several studies of Pair Programming have found that the quality of work significantly improves, compared to programmers working alone^2,3,4,5. As well as improved design and maintainability, these studies show a reduction in defect rates between 15 and 50%, with a higher reduction in defect rates for high complexity Tasks, and using experienced pairs. While pairing, individual Tasks are generally completed sooner, however, overall development speed (including defect resolution), compared to programmers working alone, reduces by between 15-25%.

Pair Work example: In this example, based on real-world Teams, two teams (of two people each) are working on the same tasks; Team 1 is using Pair Work and Team 2 is not. Team 1 – Pair Work: Because Team 1 is using Pair Work they will work on Task A together and then Task B. Task A Initial Work 6 hours   Testing ½ hour   Rework ½ hour   Defect Rate 2% Task B Initial Work 4  hours   Testing ½ hour   Rework 0  hour   Defect Rate 4% Overall Total (Initial + Test + Rework) (6+4) + (½+½) + (½+0)     = 11.5 hours   Average Defect 3% Team 2 - Individual Work: Because Team 2 is not using Pair Work they are working on Task A and Task B simultaneously. Task A & B Initial Work 7  hours 6 hours   Testing 1 hour ½ hour   Rework 1 hour 1 hour   Defect Rate 15% 10% Overall Total Max (Initial + Test + Rework) (7) + (1) + (1) = 9 hours   Average Defect 12.5% You will notice that Team 1 took less time to deliver each Task, and had fewer defects. However, since they delivered Task A then Task B, they were slower overall than Team 2, who could deliver Task A and B at the same time (though they were still less accurate).

The value of Pair Work to your organisation will change between Requirements and Teams. As an Agile Manager, you need to compare the potential increase in quality and reduced dedicated testing time, against the increased overall time to deliver. This is not a rhetorical question, but a true judgement of value that you need to make, and verify, regularly.

Table 2: When to choose Pair Work

One of the key, qualitative advantages of Pair Work, is the implicit skills and knowledge transfer between partners. This includes both specific skills relating directly to the Task, and general knowledge transfer relating to work techniques and expertise. This is particularly valuable in the case of helping new employees to learn the standards and practices of the Team, and the specific Requirements of the current Customer. By switching partners each day, specific knowledge and skills quickly spread throughout the Team, promoting a cross-functional and cross-skilled Team.

Ultimately, Pair Work is a cooperative, social skill that requires good communication and trust between partners. This can be uncomfortable for Team Members unfamiliar with this process, and can take some time to learn. Regardless of organisational status or experience, both partners need to contribute equally, and listen to the other’s ideas. Even as a mentoring mechanism, a new Team Member is still an equal partner in the pair.

As a final note, there is some controversy over the value of Pair Programming, and thus Pair Work. I leave it to you to decide if this approach will bring value to your organisation. At a minimum, however, I recommend that you apply Pair Work concepts to high-risk Tasks, and the training of new Team Members.

Team Facilitator

‘A system must be managed. It will not manage itself.’ W Edwards Deming, 1993

The Team Facilitator is one of the most important roles within the Team. They are responsible for Team cohesion, building consensus, and ensuring that the Team understands, and follows, the Agile Business Management processes and values. Where appropriate, the Team Facilitator also tailors the Agile Business Management processes to meet the needs of the Team. The Team Facilitator should be experienced in Agile Business Management, and capable of teaching those skills to other Team Members, in order to improve the overall capability and skills of the Team. Facilitation is a difficult skill, and a good Team Facilitator needs to have specific characteristics to be successful.

•  Good people skills: The Team Facilitator needs to be collaborative, with a good sense of humour, and provide a safe and constructive environment for the Team. This encourages Team cohesion, which, in turn, encourages higher morale and productivity.

•  Good communication skills: Being able to stimulate discussion within the Team, and actively listen to each other’s suggestions and feedback, is important for the Team Facilitator. This will reduce conflict, and provide an environment for creativity and innovation to flourish.

•  Good conflict resolution skills: Team Facilitators need to be capable of resolving conflicting opinions between Team Members, while remaining neutral (but not passive) on the issues discussed, and assertive, without being overbearing. This will improve the overall effectiveness, and build an environment of trust, within the Team.

•  Knowledgeable but not necessarily an expert: To be effective, the Team Facilitator needs to understand the work of all the Team Members. This ensures that the Team Facilitator can engage effectively with individual Team Members regarding their work, as well as understand the implications, and limitations, of new Requirements, or process changes, on the Team.

•  Fearless in removing impediments: The Team Facilitator needs to be able to proactively stand-up for the Team, without fear or favour, when engaging with management, or other Teams. By quickly resolving impediments, the Team can be more productive, and deliver the Customers’ Requirements faster, with minimal overhead.

•  Humble: The Team Facilitator is a supporting role, only responsible to help the Team to be as effective as possible. While this role is important, the success and value comes from the entire Team (which they are a part of). This ensures that the Team benefits from the expertise of all Team Members, and that the Team Facilitator can be productive with their non-facilitation responsibilities.

•  Fostering curiosity and excitement: Teams can get very busy dealing with day-to-day issues, and lose sight of the bigger picture. The Team Facilitator needs to provide context, to foster a sense of excitement within the team. The Team can be creative, make better long-term decisions, and enjoy their work. This, in turn, can improve the overall quality of their work.

•  Common sense: The Team Facilitator needs to be able to apply common sense to the Team processes, rather than follow instructions blindly, and without thinking. This will ensure that the processes used by the Team meet the Team’s specific needs.

•  Hands on: Finally, the Team Facilitator is responsible for basic Team housekeeping, such as prepping materials, organising meetings, and ensuring that the Team has the tools to deliver the Customers’ Requirements. This will ensure Team Members work effectively, and reduce their overhead when delivering Customer Requirements.

Finally, the Team Facilitator is not a command and control role, and should not be assigning Tasks, or making decisions for the team.

The Team Facilitator does not need to be the Team Leader, and in many cases, it can help if they aren’t. Because the organisation imbues Team Leaders with institutional authority, Team Members will obey their instructions, regardless of any personal opinions. Agile Business Management is most effective when the Team buys-in to the process, and a Team Facilitator without institutional authority must build respect and trust in the Team, in order to get that buy-in.

Anyone familiar with Scrum, will recognise this role as similar to the Scrum Master.

Team Facilitator: The person responsible for managing the Agile process within a Team. The Team Facilitator can be a Team Leader or Team Member.

Managing Teams

‘Treat your men as you would your own beloved sons. And they will follow you into the deepest valley.’ Sun Tzu, ∼6th Century BCE

At this point, you have empowered your Teams to be accountable, and responsible, for their outcomes. This empowerment transfers many of the direct responsibilities for Customer engagement, Team management and planning, from the manager to the Team. Traditionally, the Team has always been responsible for delivery; empowerment just means that they have the direct authority to follow through. However, no matter how Agile or empowered your Teams are, you are still their manager. Whether direct or indirect, you still have responsibilities for their performance and their well-being.

If it isn’t already obvious, Agile Business Management strongly emphasises the use of metrics, to understand, characterise, validate, and optimise the success, or otherwise, of the process. As part of the validation approach, you can use traditional Key Performance Indicators (KPIs) at each stage of the management process. This can help reduce the management overhead, and limit active management for productive Teams. You should assess Agile KPIs in the same context as the Agile work, this means that the KPIs should be Continuous or Incremental, automatable, and with a focus on Customer engagement.

	Key Performance Indicator: A performance measurement to evaluate the success of a particular activity.
	Standard KPI rules still apply. For example, they should be aligned to corporate strategic objectives, assigned to an individual or Team, actionable, easy to understand, a mixture of leading and lagging, and few in number.

KPIs used in your Team’s, and staff performance management, need to include both quantitative and qualitative measures. Quantitative measures verify that the Team is delivering to specific Requirements, generally as defined by the Customers’ Requirements Backlog. These are simple to measure, often drawn from a workload management system, and based on simple, numeric factors (such as the number of queries resolved). Qualitative measures verify that the Team is communicating well, and is fully engaged in planning, and working well together. These are difficult to measure directly, and are usually gathered through observation, and formal or informal feedback from colleagues.

Quantitative KPIs: •  Are quality control tests occurring during every Iteration? •  Is the Team engaging with the Customer, or Customer Representative, regularly? •  Is the Customer, or Customer Representative, engaging with the Team regularly? •  Are Requirements being estimated, and consistently delivered? •  Are defects being resolved within two Iterations? •  Is there a reduction in identified defects by consumers (note: consumer, not Customer)? •  For Incremental Delivery, are 90% of planned and estimated Tasks being completed each Iteration (Velocity/goals achieved)? •  Have overhead costs (e.g. additional meetings, delivery/release costs, delays) been reduced? •  Is the Team/person meeting agreed due dates? Qualitative KPIs: •  Are Retrospectives being effectively utilised? •  Is the Customer happy with the work being produced? •  Is the Iteration planning accurate? •  Peer review, or 360° review (controversial, but often effective)?

Velocity: The rate of delivery of Requirements per Iteration, or other fixed period.

Two examples of metrics that you should monitor, yet make poor KPIs, are the accuracy of estimates, and the percentage of Quality Control Tests that pass. KPIs based on passing early Quality Control Tests promote poor quality control, as failing tests are both expected, and provide, positive feedback to the Team. Similarly, estimation accuracy is impacted by a large number of factors, many of which the Team have no control over.

Collecting, and measuring, metrics without organisational awareness and acceptance for the rationale behind them, can lead to some Team Members manipulating their outcomes, purely to meet metrics or KPI targets. In these situations, collecting metrics can actually cause significant harm, and can lead to a complete failure of business process. Staff need to be aware that metrics and KPIs are used to improve outcomes and discover business process issues, not to assign blame.

Agile specific KPIs are valid regardless of whether they are standalone, or part of a balanced scorecard6 approach.

Under an Agile Business Management model, your staff need to undertake continuous professional development, to remain effective and competitive. Professional development can take many forms, from formal external training, attending conferences, pairing (or mentoring) with senior staff, or working across different Teams. The cross-functional Teams themselves promote ongoing skills-transfer between Team Members. As part of being empowered, individuals need to be responsible for identifying, and obtaining, their own professional development needs.

Managing Distributed Teams

‘A leader leads by example not by force.’ Sun Tzu, ∼6th Century BCE

In modern business, geographically distributed Teams are becoming significantly more common. Reasons for distributing your Team might include the availability of resources in different locations, closeness to certain business or technology clusters, proximity to Customers, or cost advantages. With a bit of common sense, and some minor adjustments to the process, it is simple to run Agile Business Management with geographically distributed Teams.

The same core rules apply to Team creation as with co-located Teams. To ensure a successful Team, only recruit self-motivated and highly skilled staff. Though it may take longer to create the Team, weak Team Members may be unable to cope with a lack of direct management, and will hamper delivery. If you must use less skilled Team Members, make sure they work from the office, where you, or other managers, can closely manage them, and only use the best Team Members for remote work.

By distributing your Team Members, you run the risk of poor Team cohesion, which, if you remember from the start of this chapter, will reduce efficiency, and can reduce many of the benefits of Agile Business Management. To mitigate this risk, make additional effort to ensure that all Team Members feel responsible, and accountable, for the achievement of the overall goal, whereby nobody can succeed without everybody else being successful. This will help foster a sense of teamwork and staff loyalty. If possible, supplement this by regularly swapping Team Members between geographic locations, allowing people to meet face to face, promote skills transfer, and improve their professional relationships.

While multiple Teams can be easily distributed, where possible, all members in a single Team should be co-located. It is easier to manage and coordinate distributed Teams, rather than distributed Team Members. Don’t take this as an excuse to be lazy, and design a Team based on the skills at hand; form Teams around the required skills, not around the available skills.

Lastly, communication is the key to any successful delivery, especially in distributed Teams. You must set up, and enforce, a communications process early in the work cycle that includes:

•  Invest in regular face-to-face meetings, especially when forming a new Team. This ensures that the Team Members get to meet their colleagues, share skills, and build strong, working relationships.

•  Encourage the use of multiple technologies (such as e-mail, online chat, tele/video conferencing, and social media) to encourage regular, and effective, communication. By providing different communication platforms, individual Team Members can choose the most appropriate channel for a given conversation.

•  Where appropriate, record, and retain, all formal communication, for future reference. Written communication (such as e-mail) is easier to search than voice or video. This provides a location where Team Members can easily refer to decisions and discussions on Requirements or technical issues. However, be aware that the communication value of e-mail is significantly lower than that of other communication channels.

•  Invest in professional video conferencing hardware for each major centre, and ensure that all individual Team Members have basic video conferencing functionality at their workstations. Overall, communication improves when participants are able to see non-verbal cues.

Remember Agile principle #6: The most efficient D and effective method of conveying information to, and within, a development team, is face-to-face conversation.

Risk management

‘Fall seven times. Stand up eight.’ Old Japanese Proverb

As work in an Agile organisation is continuously adapting to meet changing business needs, aggressive risk and issue management is an important governance outcome. Project managers will be familiar with many of these concepts, as Agile Business Management applies the same risk and issue management rigour from project management, to all areas of corporate management.

	Risk: A risk is something (generally negative) that could happen, and is assessed in terms of likelihood and potential impact.
	Issue: An issue is an event, change or risk that has occurred, or is occurring.

A risk can apply to any part of your organisation, and can either be a business, technical, or resource risk. Business risks apply to areas of your business, such as corporate processes, financial management (e.g. cashflow), or Customer engagement (e.g. satisfaction). Technical risks apply to your Production and Operations Teams, and relate to the delivery of Customer Requirements. Resource risks apply to staff management, and can be in areas, such as unexpected absences (e.g. late to work, sick leave, death, etc.), delays in recruitment, skill gaps, or fraud.

The likelihood, and impact, of some risks may change by using Agile Business Management over traditional management frameworks. For example: Higher risks •  Impact due to no Customer buy-in •  Impact due to poor support by secondary functions (such as HR) •  Likelihood of scope change Lower risks •  Impact due to rework •  Likelihood of poor estimation •  Impact due to scope change

Teams are responsible for identifying and managing risks, however, as an Agile Manager, you need to regularly monitor, and assess, these risks. Each risk should describe what could happen, how it may happen, when it may happen, the likelihood of it happening, the impact if it happens, and how it can be avoided or mitigated (treatment). It is important to remember that each risk may have more than one cause and treatment.

Where possible, base likelihood and impact on quantitative measures, such as financial, and schedule impact or historical percentile likelihood. Poor logic, insufficient evidence, and even plain old wishful thinking, can significantly bias qualitative measures, such as the traditional high/low rating.

Four basic techniques apply in the management and treatment of risks.

1  Avoid: A Team can avoid a risk by not performing the work that leads to it. Examples may include; not holding a meeting because a Team Member is sick and you don’t want to spread the illness, to not driving to work because you may have an accident on the way. The disadvantage to avoiding a risk is that you also miss the benefits.

2  Reduce: A Team can reduce the impact, or likelihood, of a risk, by changing the work that causes the risk, or putting in place alternative activities. Examples may include; additional investment in communications tools for distributed Team Members before commencing work for a Customer, or co-locating all Team Members to a single location close to the Customer. The disadvantage of reducing a risk is the additional cost required to implement the reduction strategy.

3  Share: A Team can share a risk by outsourcing, or insuring, the work required for a Customer. Examples may include; acquiring public liability insurance to protect against accidents in the workplace, to acquiring professional indemnity insurance to protect against civil lawsuits. The disadvantage of sharing a risk is the additional cost involved, and the legal disagreements that can occur when the shared risk does not exactly correlate to the contractual arrangements.

4  Retain: A Team can retain (or accept) a risk if they are willing to accept the impact of the risk should it occur. Examples may include; purchasing incorrect office supplies, as the cost to replace is very low; to a terrorist attack, as the likelihood is so low, and the cost to mitigate is very high. The obvious disadvantage of retaining a risk is that there is no strategy in place if the risk occurs, and it has a greater impact than expected.

Example risks: Risk #1 •  Risk: Poor Customer engagement •  Caused by: Conflict between a Team Member and Customer •  Likelihood: Low •  Impact: High •  Treatment: Provide formal induction for all staff in Agile processes. Provide ongoing support and training in communication skills •  Likelihood after treatment: Very low •  Impact after treatment: Medium Risk #2 •  Risk: Negative product reviews •  Caused by: Dissatisfied consumers who purchased our product •  Likelihood: High •  Impact: Very low •  Treatment: Additional quality control in product development and training for help desk staff •  Likelihood after treatment: Moderate •  Impact after treatment: Very low Risk #3 •  Risk: Data loss •  Caused by: ICT systems crash •  Likelihood: 0.5% per year •  Impact: $500,000 •  Treatment: Creating mirrored systems and off-site back-up •  Likelihood after treatment: Very low •  Impact after treatment: Moderate Risk #4 •  Risk: Production system outage •  Caused by: ICT systems crash •  Likelihood: 1.8% per year •  Impact: $50,000 •  Treatment: Redundant production systems with regular disaster recovery and business continuity tests •  Likelihood after treatment: Very low •  Impact after treatment: Low Risk #5 •  Risk: Property damage •  Caused by: Fire, flood, etc. •  Likelihood: Very low •  Impact: $15,000,000 •  Treatment: Business continuity insurance •  Likelihood after treatment: Very low •  Impact after treatment: Moderate

Once identified, risks are recorded in the Team’s Risk Register, which in true Agile fashion, is visible to all stakeholders. Record each risk in the Risk Register separately, even related risks, to support the needs of different Teams. Teams can manage very low, low, and medium risks, internally, but need to report high, and very high risks, even if they can manage them internally.

Risk Register: A log of all risks for a specific Team and Customer.

You do not need to treat, or monitor, all risks, as treating risks costs time and money. You need to decide what level of risk you are willing to accept (your risk appetite), and how much you are willing to invest in avoiding risks you can’t accept.

As a final word, there are many good books on the subject of risk, and risk management, that will provide detail⁷, and, in some cases, guidelines⁸ on implementing good risk management.

1 Transforming the City of Edmonton IT Branch, Male (2009).

2 Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise, Arisholm, et al (Feb 2007).

3 The Effect of Pairs in Program Design Tasks, Lui, Chan and Nosek (Feb 2008).

4 The Costs and Benefits of Pair Programming, Cockburn and Williams (2000).

5 Pair Programming Illuminated, Williams and Kessler (2003).

6 The Balanced Scorecard: Translating Strategy Into Action, Kaplan and Norton (1996).

7 Waltzing With Bears: Managing Risk on Software Projects, DeMarco and Lister (2003).

8 The Black Swan: The Impact of the Highly Improbable, Taleb (2007).