|
‘There is nothing wrong in change, if it is in the right direction. To improve is to change, so to be perfect is to change often.’ Winston Churchill, 1925 |
Agile is about change; changing how you think, changing how you work, and changing the way you interact. By accepting, embracing, and shaping change, you can take advantage of new opportunities to outperform, and out-compete, in the market. While this sounds simple, change, by its very nature, is not easy.
The concepts in this book change what it means to do business. ‘Agile Business Management’ is a series of concepts and processes for the day-to-day management of your organisation, regardless of industry, size or location. The end goal is to improve business adaptability, staff engagement, quality, and risk management, for the benefit of your Customers.
Agile Business Management is not a quick win; it is not a ‘three-step plan’ to a ‘better business’. Agile Business Management is hard work, and requires a cultural shift from the traditional business practices of hierarchical corporate structures, customer engagement, staff management, and work processes.
This book divides Agile Business Management into four domains, each requiring corresponding changes to the way your business operates. The first domain is You, the Agile Manager. Though it may seem daunting, changing the mindset and processes of management is probably the easiest change to make. It only requires an open mind and a willingness to adapt to a changing business environment.
The second domain is Integrated Customer Engagement – the changing relationship and interactions between you and your Customer. Under Agile Business Management, Customers take on direct responsibility for the delivery of their Requirements. Teams and Customers work closely together, collaborating towards the desired outcomes. To be Agile, means to be flexible and adaptable to changing circumstances, and nothing changes more than your Customer’s needs.
The third domain is the Structure of an Agile Organisation -how you manage your staff, the heart of your business, and how they relate to the rest of the organisation. This is a change from a traditional hierarchy, towards self-empowered individuals and Teams. One of the strengths of Agile Business Management is the focus on personal empowerment, developing engaged staff as a mechanism to drive improved customer outcomes. Whilst empowerment is difficult to define and measure, the outcomes are clear. Employees have the responsibility, accountability and authority to deliver to the Customer’s Requirements.
Having examined the role of the Customer and Team, it’s time for the fourth and final domain – Work, the Agile Way. Agile Business Management uses Just-In-Time planning, and an Incremental, or Continuous, Delivery process, that allows for rapid change when scope and circumstances change. Customers work alongside the Team to shape and direct the outcomes, while the Team regularly deliver partial, though functional, products to the Customer. The product itself will continue to evolve, as each Iteration builds upon the last.
As no two organisations are the same, the design of Agile Business Management is both generic and customisable. Designed to be applicable to most organisations, it is agnostic to the size, industry, nature, location, product base, and culture of your organisation. Where possible, this book also uses common terms and definitions. This means that you will gain the greatest benefit from a considered and tailored implementation, rather than applying every concept in this book verbatim.
There are two approaches you can take when implementing Agile Business Management – the first is a selective, methodical and Incremental approach, and the second is a faster, all-at-once, big-bang approach. While each organisation has different needs, experience shows that a slower, more considered approach to process improvement, usually leads to better results. Start by changing those processes that provide the greatest organisational improvement, observe the outcome, and use that feedback to shape the next change. This is, in itself, an agile approach to Agile. Done correctly, changes in process lead to observable business improvement, which in turn leads to change in the mindset of the organisation. As always, appropriate staff and executive training should complement any organisational change.
Agile Business Management has been many years in the making, and draws on the underlying principles and concepts of the Agile movement. Originally developed by the software engineering industry, you can apply most of the concepts of Agile to technical and non-technical organisations of any size. The management concepts and processes have been implemented across numerous organisations and departments, from managing people and resources, operations management, financial management, Sales and Marketing processes, IT support, and of course software engineering.
Join us for the journey.
What is Agile?
|
Plans are worthless, but planning is everything.’ Dwight Eisenhower, 1957 |
Firstly, it is important to understand that Agile is a value system – not a process.
Based on the Lean Manufacturing1 practices, and adapted and extended for the software industry, Agile is a generic term that describes over 50, sometimes conflicting, methods and frameworks for working in an adaptable, Customer focused, and Incremental way. These frameworks cover the full spectrum of business and product delivery; including strategy, planning, design, development, Q/A and management. Though Agile has only recently gained popular awareness, many organisations have been using these frameworks for over 20 years, and, in the case of lean manufacturing, over 50 years. Well-known Agile frameworks and techniques include Scrum2, Extreme Programming (XP)3, Test-Driven Development (TDD)4, and Kanban5.
|
Customer: An individual (or organisation) who engages one or more Teams to deliver a series of Requirements, and who has the responsibility, and authority, to direct the delivery of the products or services. |
|
Team: A small group of between five and nine staff, containing across-section of skills, permanently, or temporarily, grouped together to deliver one or more Customer’s Requirements. |
The first major milestone in the Agile story was in February 2001, when representatives from many of the fledgling Agile processes, such as Scrum, DSDM, and XP came together to write the ‘Agile Software Development Manifesto’6. Consisting of four core values and 12 principles, the Agile Manifesto forms the basis of all Agile frameworks, including Agile Business Management, and defines what it means to be ‘Agile’.
In Agile Business Management, the four core values define how you do business as an Agile organisation:
1 We value individuals and interactions over processes and tools (see Chapter 3: The Structure of an Agile Organisation).
That is, while processes and tools can help sustain a consistent level of output, motivated individuals and Teams collaborating and working together, are more creative, and can produce higher quality work.
2 We value working software over comprehensive documentation (see Chapter 4: Work, the Agile Way).
In an Agile Business Management context, replace ‘working software’ with ‘delivered Customer Requirements’. This means that, while processes that support delivery are important, the Team’s focus should be on delivering to the Customer’s needs.
3 We value customer collaboration over contract negotiation (see Chapter 2: Integrated Customer Engagement).
Written contracts are still important. However, you should be treating your Customer as a partner, not as an opponent. The goal of an Agile contract is to facilitate rather than protect, though it can do that as well.
4 We value responding to change over following a plan (see Chapter 4: Work, the Agile Way).
Under Agile Business Management, plans are useful as a guide, but adapting to the Customer’s changing Requirements brings greater business value, for both you and your Customer.
The values on the right (processes, documentation, contracts and plans) are still important to a successful business; however, to be adaptable and Agile, you need a greater appreciation of the values on the left (individuals, working software, customer collaboration, responding to change).
Requirement: Also called a User Story, or Minimal Marketable Feature, a Requirement is a specific, documented and deliverable Customer need. |
Supporting the four core values, are the 12 principles of the Agile manifesto that define the Agile mindset. These are the key business attributes that are most important to Agile practitioners. Keep in mind that, although originally written in the context of software engineering, the same mindset applies to business management. The adoption of this mindset within the management structure of an organisation is critical to the success of any Agile Business Management transformation process.
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software [Requirements].
2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3 Deliver working software [completed Requirements] frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.
4 Business people and developers [Team Members] must work together daily.
5 Build projects [Teams] around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development Team is face- to-face conversation.
7 Working software [completed Requirements] is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers [Team Members], and users should be able to maintain a constant pace indefinitely.
9 Continuous attention to technical [and non-technical] excellence and good design enhances agility.
10 Simplicity, the art of maximising the amount of work not done, is essential.
11 The best architectures, requirements, and designs emerge from self-organising Teams.
12 At regular intervals, the Team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Understanding these 12 principles is critical to understanding Agile, and Agile Business Management.
The values and principles of the Agile manifesto, as well as some of the successful Agile frameworks from the ICT industry, form the basis of Agile Business Management. The specific frameworks that Agile Business Management utilises include Scrum (for its Incremental product development processes), Kanban (for its continuous workflow management process), Test-Driven Development (as a mechanism to embed quality control in the work cycle), Feature Driven Development (as a mechanism to break large Customer Requirements into deliverable Tasks) and Extreme Programming (to provide sustainable delivery within Teams).
Scrum
Scrum is described as a ‘framework within which you can employ various processes and techniques’, rather than a process, or a technique, for building products7.
Primarily used as a project management and product development framework8, Scrum describes a framework (as shown in Figure 1) for the Incremental Delivery of complex products. The Scrum framework is primarily team based, and defines associated roles, events, artefacts and rules. The origins of Scrum trace back to the mid-80s, but it was not a unified framework until 19959, when Jeff Sutherland and Ken Schwaber brought together the related experiences and research on Incremental product development and project management.
Kanban
The original concepts of Kanban 
were developed in the 1940s and 50s by Taiichi Ohno10 as part of the Toyota Production System, as a mechanism to control Just-In-Time (JIT) production and manufacturing processes. Kanban, which approximately translates as ‘signboard’, is described as a ‘visual process management system that tells what to produce, when to produce it, and how much to produce’. The modern Kanban method, as formulated by David J Anderson in 200711, is an adaption of the original JIT approach, with an emphasis on staff welfare and continuous process improvement practices.
|
Just-In-Time: A production strategy that strives to improve a business return on investment by reducing waiting inventory and associated carrying costs. |
At its simplest, each prioritised Task (or Card) on a Kanban Board passes through a visualisation of the Team’s process, or workflow, as they happen. Each primary activity in the Team’s workflow is visualised as columns on the Kanban Board, usually starting at Task definition, and finishing with delivery to the Customer. Of course, being Agile, these Cards and activities are visible to all participants, including the Customer. Figure 2 shows the actual Kanban Board used to track the writing of this book.
|
Task: A discrete activity that forms a subset of a Requirement. Put another way, the delivery of each Requirement requires the delivery of one, or more, Tasks. |
To identify, and control, bottlenecks and process limitations, each workflow state (or column) has a limit, called a WIP, or Work In Progress Limit, to the number of currently Active Tasks. This allows managers and Team Members to regularly monitor, and measure, the flow of work.
Lean Manufacturing
Lean Manufacturing, often called lean production, or just ‘Lean’, is a streamlined manufacturing and production technique, as well as a philosophy that aims to reduce production costs, by eliminating all ‘wasteful’ processes. Put another way, Lean focuses on ‘getting the right things to the right place, at the right time, in the right quantity, to achieve perfect workflow’.
Lean defines three types of waste: Mura, Muri, and Muda.
1 Mura (Unevenness): Mura exists where there is a variation in production workflow, leading to unbalanced situations, most commonly where workflow steps are inconsistent, unbalanced, or without standard procedures.
2 Muri (Overburden): Muri exists where management expects unreasonable effort from personnel, material or equipment, most commonly resulting from unrealistic expectations and poor planning.
3 Muda (Waste): Muda is any step in the production workflow that does not add direct value to the Customer. The original seven wastes, as defined by the Toyota Production System (TPS), were Transport, Inventory, Motion (moving more than is required), Waiting, Overproduction, Over Processing (from poor design), and Defects (the effort involved in inspecting for, and fixing, defects). Additional and new wastes are not meeting customer demand, and are a waste of unused human talent. There is further differentiation between Type 1 (necessary waste, e.g. government regulations) and Type 2 (unnecessary waste).
Based on the original Toyota Production System (see section: Kanbans), Lean Manufacturing was formally defined in 1988 by John Krafcik, and later expanded upon by James Womack, Daniel Jones and Daniel Roos12.
Lean Manufacturing provides a set of techniques13 to identify, and eliminate, waste which, in turn, improves quality, and reduces overall production time and cost. In addition, Lean Manufacturing also improves the ‘flow’ of production through the system. These techniques include:
• Value stream mapping: Analysing and planning the flow of materials and information that is required in the production process.
• Five S: This is an approach to quality and continuous improvement. The five Ss are: Sort (to clean and organise the work area), Set in Order (arrange the work area to ensure easy identification and accessibility), Shine (mess prevention and regular maintenance of the work area), Standardise (create a consistent approach for carrying out production processes), Sustain (maintain the previous four Ss through discipline and commitment).
• Kanban: See section: Kanbans.
• Fail-proofing: Prevent human errors before they occur.
• Production levelling: Ensure that each step in the production process delivers at a constant rate, so that subsequent steps can also deliver at a constant rate. No step in the production process should produce goods at a faster rate than subsequent steps, or consume goods at a slower rate than preceding steps.
Finally, Lean Manufacturing emphasises Kaizen14 (改善) or Continuous Improvement; the ongoing, incremental and regular technique of improving all processes, products and functions relating to production, resources, organisational management, and the supply chain.
|
Kaizen: A philosophy, culture and technique of driving continuous improvement in work processes and business functions. |
|
Many of the terms in Lean Manufacturing have been translated from the original Japanese. As such, they often lose the context, or secondary meanings, of the term. Where possible, this context is described throughout the book. |
Feature Driven Development
Feature Driven Development (FDD) is a series of Agile processes to support the planning, design and building of large-scale projects15. Developed by Jeff De Luca in 199716, FDD defines five basic activities that break down complex systems and requirements into staged components suitable for Incremental development. These activities are:
1 Develop overall model: Define the context, and create a high-level scoping document.
2 Build feature list: Decompose the model into subject areas, and within each subject area, a set of features to be delivered (as with other Agile frameworks, the effort to deliver each feature should not exceed the length of a single Iteration).
3 Plan by feature: Prioritise, and assign, each feature to a development team.
4 Design by feature: Select, and design, the set of features to deliver in the current Iteration.
5 Build by feature: Build, test and review each feature.
Each activity is comprehensively discussed and peer-reviewed to ensure clarity and agreement between all stakeholders.
Test-Driven Development
Developed in 2003 by Kent Beck17, Test-Driven Development (TDD) is primarily a software engineering process that forces programmers to write small, incremental verification tests prior to writing each function of the software. Each set of verification tests defines the outcome of a single feature or improvement. This ‘test first’ approach encourages simple design, concise development, and confidence in the product.
There are six steps to the TDD process:
1 Write new tests.
2 Run all tests, verifying that the new tests fail.
3 Write the software function.
4 Run all tests, verifying that the new tests pass. If the tests fail, or you discover any new issues, return to step three.
5 Refactor the code by improving the quality of work, without changing the functionality.
6 Repeat.
TDD does not directly translate outside of a technical environment, where tests can be automated and strictly defined. However, you can apply the core concepts, and define the acceptance, quality control and quality assurance criteria prior to any work commencing, to the same benefit.
Quality Control: The act of identifying defects by testing, validating and verifying a completed product, or service, against the Customers’ Requirements. |
|
|
Quality Assurance: The process of improving development and test processes, to increase overall quality and reduce defects. |
|
Defect: A shortcoming, imperfection, or lack in an otherwise completed Requirement. |
Extreme Programming
Extreme Programming (XP) is an Agile software development framework created by Kent Beck and published in 199918. Like all Agile frameworks, it advocates Incremental Delivery and responding to changing Customer Requirements. XP’s focus is on the method and role of the Delivery Team, and defines four, basic activities within the software development process.
1 Coding: The act of building a working product to the specific Customer Requirements (code is also used as a communication and problem-solving tool; by attempting to code a solution, developers can discuss complex problems and demonstrate alternative solutions).
2 Testing: With strict emphasis on testing, especially automating testing, developers can ensure high-quality code, and the completeness of their work.
3 Listening: Getting the developers to communicate with the Customer ensures that both parties understand the Requirements, and effort, involved in delivery.
4 Designing: By emphasising planning and design, complex systems can be simplified, and unwanted dependencies reduced.
Common misconceptions
|
‘On two occasions I have been asked, “Pray, Mr Babbage, if you put into the machine wrong figures, will the right answers come out?” [...] I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.’ Charles Babbage, 1864 |
Being a generic term, Agile means different things to different people. Therefore, before we go much further, I should clarify some of the more common misconceptions surrounding Agile.
Agile is ad hoc, with no process control: First of all, Agile isn’t a lack of process. Agile provides a range of formal processes, and methods, to inform work processes, customer engagement and management models. Conversely, Agile isn’t about blindly following the prescribed ‘agile’ methods and processes. Agile is about using your common sense to apply processes, as determined by the current situation, and shaped by the Agile philosophy.
Agile is faster and/or cheaper: Agile isn’t significantly faster, or cheaper, than alternative frameworks. Put another way, in most cases you can’t get significantly more effort out of your Teams by moving to an Agile approach. While there is an overall efficiency gain when utilising Agile methods, well-managed Agile and non-Agile Teams will deliver products and services in approximately the same time and effort.
Agile teams do not plan their work or write documentation: Agile is not an excuse to avoid appropriate planning or writing documentation. It is an on-demand, or Just-In-Time, approach that encourages continuous planning and documentation, but only when needed for specific Customer Requirements. This allows Customers and Teams to determine if the planning, or document, adds value to the process or product. It creates an opportunity to emphasise valuable documents, and eliminate anything that isn’t useful.
An Agile project never ends: While this may be true in some situations, the benefit of Agile is that work will continue while the Customer continues to gain business value, and that value is worth more than the cost of developing it. Most projects, in any industry, have a point of diminishing returns. This is the ideal time for an Agile project to end.
Agile only works for small organisations: Agile works for projects, teams and organisations of any size, not just small projects. That is not to say that it will work for all organisations, but size is rarely a factor. Large and complex projects and organisations are often excellent candidates for Agile transformation, where it is difficult, or impossible, to know all your Customer’s Requirements in advance.
Without upfront planning, Agile is wasteful: This assumes that your Customer knows the detail of all of their Requirements in advance. If this is true, then by all means, undertake comprehensive upfront planning. However, in reality this is rare, and usually leads to the greater ‘waste’ of having undertaken design and development work that was ultimately unnecessary. Agile Business Management encourages minimal upfront planning, ensuring everyone is working towards the same goal, and reduces the risk of miscommunication.
Finally, Agile is not the solution to all your problems. It is a change in approach and culture that comes with its own set of benefits and issues.
Governance and Agile Business Management
|
‘A leader is best when people barely know he exists, [...] when his work is done, his aim fulfilled, they will say: we did it ourselves.’ Laozi, ∼6th Century BCE |
Governance supports the organisation, by ensuring consistent management, cohesive policies, overall guidance, and decision-rights for a given area of responsibility. Though the structure, roles and policies may differ from traditional organisations, Agile Business Management uses these same governance mechanisms and controls.
Good management is about getting hundreds, if not thousands, or hundreds of thousands, of your employees all working in harmony towards a common goal. In most organisations, employees work on behalf of the shareholders, via the Board of Directors. All but the smallest of companies need strong governance processes to ensure consistent outcomes in-line with the expectations of the Board. Corporate governance defines these relationships, and provides the processes to ensure managers make appropriate business and financial decisions, managing staff and their Deliverables, and adequately controlling quality processes.
|
Deliverable: The product, or service, created by the Team (or Teams), to fulfil a specific Requirement. Each Deliverable generally only fulfils a single Requirement, so a large project may consist of many Deliverables. |
There is no single model of good business management or corporate governance19. However, across the many approaches, including Agile Business Management, there are common themes, independent of industry, country or structure.
Corporate governance specifies the instruments to define, achieve, and measure your corporate objectives, in the interests of the company and its shareholders. Good corporate governance also puts in place appropriate monitoring controls, to ensure that the Board and executive bodies are actively pursuing these objectives.
Most organisations define governance through organisational structure, roles and responsibilities, and formal policies. Governance can also mean ‘external governance’; strict controls and policies imposed on an organisation by external parties. These can include:
• Legislation; such as workplace relations, or occupational health and safety.
• Specific industry standards and frameworks; such as CMMI®, ISO9001, ISO20000, ISO38500 or the OECD Principles of Corporate Governance.
• Government and industry regulation; such as financial or tax regulation.
• Shareholder requirements and expectations.
Agile Business Management is nothing, if not adaptable. If compliance with a specific regulation conflicts with your Agile Business Management goals, adapt your goals and governance processes.
Agile Business Management also provides built-in verification points, to ensure governance compliance. These include:
• Escalation of decision approval to appropriate levels
• Transparency and oversight of decisions
• Reporting to external agencies
• Providing, and archiving of, documentation
• Formal audits of business practices.
All governance processes need to balance the needs of diverse stakeholders, including; shareholders, regulators, corporate functions, and internal Departments. For the interests of these stakeholders to be satisfied, there needs to be an alignment of corporate interests and objectives. Misalignment comes in many forms, including differing backgrounds and priorities, complex or overloaded governance controls, different management values and principles, or just the complexities of running a large multisite, or multinational, organisation.
Department: A specific group within your organisation, responsible for a specific business function, subject area, service or product. Human Resources, Finance and Accounting, and Sales and Marketing, are all examples of departments. Departments may also be known as Groups, Divisions, Organisation Units, or Business Areas. |
All Agile Business Management processes aim to establish shared objectives and improve communication, but the most important feature is that they have built-in automatic alignment and re-alignment features. These include feedback-driven process adaption, empowered workers, self-organisation, collaboration and regular delivery.
At the end of your Agile Business Management transformation, you will have a set of processes that encourage broad collaboration across your business, including integration with corporate strategy and other core corporate governance mechanisms.
Successful Agile Business Management
|
‘Beautiful objects are wrought by study through effort, but ugly things are reaped automatically without toil.’ Democritus, ∼4th Century BCE |
Becoming an Agile organisation is an incremental process. There is no single point you say to yourself, ‘Yesterday we weren’t Agile, but today we are. Success!’ However, you can say, ‘Today we are more Agile than yesterday!’ Your journey to become an Agile organisation can be formal, through a transformation programme, or informal, through ad hoc changes addressing problem areas. Regardless of the mechanism, your Agile journey begins with a set of clear organisational goals. Ask yourself; what is your organisation trying to achieve by becoming Agile?
As every organisation will have different goals, so the process to become Agile will differ as well. In general, goals relate to improving adaptability in a changing marketplace, driving higher quality work, improved Customer and staff satisfaction, sustainable management processes, or reducing overheads.
To validate that you have achieved your organisational goals, you need to create a set of specific, success criteria that define measurable targets for your staff and stakeholders. Success criteria should be concise, realistic and directly measurable. It is also important to include both quantitative success measures, based on facts and figures, and qualitative success measures, based on feedback and opinion.
You can quantitatively measure the success of your Agile journey from your organisational maturity, in four key areas: Staff, Customer Engagement, Technology and Processes. For example:
1 Staff maturity measures
Staff are trained, and experienced, in Agile Business Management and associated frameworks (training measure).
Staff have an understanding of the underlying reasons for moving to Agile Business Management (communication measure).
Staff are directly empowered to engage with, and deliver to, the Customers (action measure).
Staff are skilled in the supporting tool-sets (training measure).
Staff are conversant in the work, quality control and release procedures (action measure).
2 Customer engagement maturity measures
Customers are trained in their new responsibilities (training measure).
Customers, or their representatives, are involved in the Team’s daily activities (action measure).
Customers actively define, and order, Requirements, at least once per Iteration (action measure).
Customers have the authority to make decisions regarding the delivery of their Requirements (action measure).
3 Technology maturity measures
There is a stable and well-documented supporting technology stack (see section: Kanbans) (action measure).
The supporting technology has clearly defined ownership and service levels within the organisation (communication measure).
4 Process maturity measures
Clearly defined business processes exist for all domains (action measure).
Cross-domain interdependencies defined for all Departments (communication measure).
Agreed service levels exist between all departments (communication measure).
Each process has clear business ownership and delegations of authority identified (action measure).
Saying that staff attended training, is not sufficient to pass a training success measure. You must be able to demonstrate that staff can apply these new skills. |
From a qualitative standpoint, there are only two main success measures:
1 Are our staff happy (action measure)?
2 Are our Customers happy (action measure)?
|
To help differentiate them, you should phrase quantitative success measures as statements, and qualitative success measures as questions. |
Not all organisations will succeed in becoming Agile. Organisation’s with low morale, no staff or executive buy-in, high staff turnover, or a lack of trust between themselves and the Customer, need to address these issues at the beginning of any Agile transformation programme, and will introduce additional risk into the transformation.
Relationship to other management styles
|
Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.’ Douglas Adams, 1990 |
Many of the concepts within Agile Business Management can happily co-exist with, and enhance, existing management and governance frameworks. This section looks at some common management frameworks and their interface points. The goal of this is to show that Agile Business Management does not exclude your existing management processes, frameworks or styles. You need to find the interactions between them, and create a management and governance framework that works for you and your organisation. The design of Agile Business Management is deliberately generic, so you can tailor the frameworks and concepts as appropriate to your organisation.
OECD Principles of Corporate Governance
The OECD Principles of Corporate Governance20 is a set of common, corporate governance standards and guidelines for companies, investors, stock exchanges and related parties, in both OECD and non-OECD countries. There are six core principles. These relate to:
1 Ensuring the basis for an effective corporate governance framework.
2 The rights of shareholders and key ownership functions.
3 The equitable treatment of shareholders.
4 The role of stakeholders in corporate governance.
5 Disclosure and transparency.
6 The responsibilities of the board.
These principles complement the principles of the Agile manifesto, which guide Agile Business Management. Common to both, is an emphasis on transparency (see Chapter 3: The Structure of an Agile Organisation) and accountability (see Chapter 1: You, the Agile Manager), at all levels across your organisation. The roles and responsibilities of the Board (see section: The Board and executive governance bodies) also extend to include greater participation and open communication.
Process control loops
Process control loops, such as Deming’s Plan-Do-Study-Act (PDSA)21, the related Plan-Do-Check-Act (PDCA), Six- Sigma’s Define-Measure-Analyse-Improve-Control (DMAIC)22, Test Driven Development’s Red-Green-Refactor (RGR), and the military Observe-Orient-Decide-Act (OODA)23 methods are cyclical processes to improve major decision making, through the rigorous testing of outcomes. Taking PDSA as an example, there are four key steps in the control loop; Plan, Do, Study and Act.
• P: Plan and set the objective upfront
• D: Do, or implement, the plan
• S: Study the results, and compare against the expected results
• A: Act on the results to improve the process
Agile Business Management iterates through a PDSA cycle for each Customer Requirement, and applies rigour to the upfront planning and quality processes. However, unlike many traditional PDSA processes which cycle through large blocks of work, this cycle repeats regularly and iteratively.
Another example is Test-Driven Development’s (see section: Quality Control) Red, Green, Refactor control loop, where Quality Control Tests are defined upfront, prior to your teams commencing any work. Once a Requirement is Done, the original tests run against the outcomes, to verify the overall completeness and accuracy. In this context;
• Red: Create the Quality Control Tests (which, if run, would obviously fail at this stage)
• Green: Do the minimum work to pass the Quality Control Tests (until the tests turn green)
• Refactor: Improve the quality of the work, to ease future enhancements and maintenance
You can also define the Red-Green-Refactor cycle as a PDCA control loop:
• P: Create the Quality Control Tests
• D: Do the work
• C: Validate the outcomes against the original tests
• A: Rework, or refactor, based on the results
|
Quality Control Test: A formal procedure that identifies potential defects, by examining the specific output of a Deliverable. |
Existing process control loops can also complement the continuous improvement processes (Kaizen) defined within the Agile Retrospectives chapter (see Chapter 6: Reflection, Retrospectives and Kaizen).
|
Retrospective: A regular Team meeting to review, and reflect on, the management processes that support the day-to-day operation. |
Deming’s 14 points
Along with PDSA, Deming is also famous for his 14 points to managers for transforming business effectiveness24. These points aim to change the focus of management from growth through financial returns, to the more Agile approach of growth through investment, innovation and strong staff engagement.
1 Create constancy of purpose toward improvement of product and service, with the aim to become competitive, stay in business and to provide jobs.
2 Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3 Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4 End the practice of awarding business on the basis of a price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
5 Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6 Institute training on the job.
7 Institute leadership. The aim of supervision should be to help people and machines and gadgets do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
8 Drive out fear, so that everyone may work effectively for the company.
9 Break down barriers between departments. People in research, design, sales, and production must work as a team, in order to foresee problems of production and in use that may be encountered with the product or service.
10 Eliminate slogans, exhortations, and targets for the workforce, asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the workforce.
11 a. Eliminate work standards (quotas) on the factory floor. Substitute leadership. b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
12 a. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality. b. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective.
13 Institute a vigorous program of education and self- improvement.
14 Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.
The processes defined in Agile Business Management encapsulate most of these principles. For example, Chapter 1: You, the Agile Manager defines new responsibilities for Agile management. The Agile Retrospective process of review and reflect (see Chapter 6: Reflection, Retrospectives) creates a culture of continuous quality and process improvement. And the creation of effective, cross-functional and empowered Teams, that have the authority and accountability to deliver, is at the very heart of Agile Business Management (see Chapter 3: The Structure of an Agile Organisation).
Theory of Profound Knowledge
|
‘A system cannot understand itself. [The aim] is to provide an outside view, a lens, that I call a system of profound knowledge. It provides a map of theory by which to understand the organisations that we work in.’ W Edwards Deming |
The Theory of Profound Knowledge25 is the principle that an organisation is a complex system, made up of interdependent components, such as processes and people. The successful management of the interactions between its components, directly drives the success of the system. Deming recommends that managers understand four things in order to manage the system effectively:
1 An understanding of the overall processes under their control.
2 Knowledge of variation, and how to measure it.
3 An understanding of the theory of knowledge itself.
4 Knowledge of psychology and human nature.
Understanding, and managing, the organisation as a whole, is a core requirement for any Agile manager. Without understanding the processes, and their expected variations, under your control, just-in-time planning is likely to have unexpected issues, with additional flow-on impacts. Similarly, without understanding psychology and human nature, it is difficult to manage cross-functional and self-organising Teams.
CMMI
Developed, and owned, by the Carnegie Mellon University26, the Capability Maturity Model Integration27 (CMMI), is not, in itself, a management framework. Rather, it is a set of goals and practices leading to corporate process improvement. However, CMMI does define a model for management best practices that an organisation must demonstrate, in order to show compliance. In all, CMMI assess organisations against 16 core process areas, as well as several context-specific process areas. Once appraised, organisations are given a maturity rating between one and five (Initial, Managed, Defined, Quantitatively Managed, Optimising), based on how well an organisation’s processes compare to CMMI best practice.
The 16 ‘core’ process areas are:
Project management
1 Project monitoring and control: A level 2 project management process to monitor, and manage, a project’s performance against the plan.
2 Project planning: A level 2 project management process to establish, and maintain, plans that define project activities.
3 Requirements management: A level 2 project management process to control, and manage, project requirements through the lifecycle from planning to delivery.
4 Integrated project management: A level 3 project management process to manage a project and its stakeholders.
5 Risk management: A level 3 project management process used to identify, and mitigate, potential issues before they occur.
6 Quantitative project management: A level 4 project management process to verify that the project is meeting its performance and quality objectives, using quantitative measurements.
Agile Business Management emphasises strong project management governance, while remaining adaptable, and catering to changing Customer Requirements. Customer Requirements are tracked, managed, and delivered according to the Customer’s priorities, which may change over the duration of the project (see section: Requirements and the Requirements Backlog). Standard Agile processes track, and regularly assess, risk (see section: Risk management). Finally, all work in Agile (whether project-based or not) is monitored, using comprehensive quantitative measurements. Continuous feedback is a core requirement to many Agile processes (see section: Measuring progress).
Support
7 Configuration management: A level 2 support process that manages the definition, and integrity, of deliverables across the lifecycle of development.
8 Measurement and analysis: A level 2 support process that manages the capability to collect, measure and analyse data on organisational processes.
9 Process and product quality assurance: A level 2 support process to evaluate processes, and deliverables, objectively.
10 Decision analysis and resolution: A level 3 support process to analyse possible management decisions, against formally established criteria.
11 Causal analysis and resolution: A level 5 support process that uses root cause analysis to identify the causes of selected outcomes, and uses that information to improve process performance.
Many of the recommended CMMI support processes form part of Agile Business Management. These include the use of the Requirements Backlog (see section: Requirements and the Requirements Backlog) as a configuration management technique, the quantitative measurement of progress, and the effectiveness of specific processes (see section: Measuring progress), as well as formal quality control mechanisms (see section: Quality control).
Process management
12 Organisational process definition: A level 3 process management process to define the organisational processes themselves, and the guidelines in their use.
13 Organisational process focus: A level 3 process management process to improve organisational processes, based on the incremental measurement of the success of existing processes.
14 Organisational training: A level 3 process management process to improve the skills, knowledge and capabilities of organisational staff.
15 Organisational process performance: A level 4 process management process to measure the performance of organisational processes quantitatively, to encourage continuous improvement.
16 Organisational performance management: A level 5 process management process to define business objectives, and proactively manage the organisation’s performance, in order to meet them.
Process management and continuous process improvement, are important aspects of Agile Business Management. Using formal measurement (see section: Measuring progress), continuous feedback, and staff training (see section: Managing Teams), processes can be formally, and quantitatively, measured. The retrospective process (see Chapter 6: Reflection, Retrospectives and Kaizen) provides an integrated mechanism for process improvement to be discussed, planned and implemented.
In the latest version of CMMI (v1.3), effort has been made to map existing Agile techniques against CMMI process areas, to improve the accuracy of CMMI assessments in Agile organisations. In addition, there have been a number of case studies, and research papers, on the integration of Agile and CMMI, showing the benefits of a hybrid approach28,29,30.
|
‘[Organisations] fail to distinguish that CMMI is ^f fundamentally a model. Instead of working with CMMI as a model, they work with CMMI as a standard. A standard is an auditable, testable, compliable work with a narrow field of distinct, acceptable, and demonstrable outputs, with little variation from one implementation to the next... To reiterate from the model itself, “CMMI contains neither processes nor procedures;” the lists of typical work products, for example, are examples of process outputs.’31 |
This is not to suggest that Agile Business Management and CMMI work together seamlessly, or ‘out of the box’. Organisations applying strict Agile Business Management would find it difficult to comply with some of the CMMI process areas at higher maturity levels. However, having said all that, you can tailor Agile Business Management to meet your organisation’s CMMI requirements, while still following the values of Agile.
1 The Machine That Changed the World, Womack, Jones and Roos (1991).
2 Scrum Alliance, Scrum, n.d.
3 Extreme Programming Explained: Embrace Change, Beck (1999).
4 Test-Driven Development by Example, Beck (2002).
5 Kanban: Successful Evolutionary Change for Your Technology Business, Anderson (2010).
6 Agile Manifesto, Beedle, et al, n.d.
7 Scrum Guide, Schwaber and Sutherland (2011).
8 Agile Software Development with Sccrum, Schwaber and Beedle, (2002).
9 Business Object Design and Implementation, Sutherland and Schwaber (1995).
10 Toyota Production System: Beyond Large-Scale Production, Ohno (1988).
11 Kanban: Successful Evolutionary Change for Your Technology Business, Anderson (2010).
12 The Machine That Changed the World, Womack, Jones and Roos (1991).
13 Lean Production Simplified, Dennis (2007).
14 Kaizen (Ky’zen), The Key to Japan’s Competitive Success, Imai (1986).
15 A Practical Guide to Feature-Driven Development, Palmer and Felsing (2002).
16 Java Modeling In Color With UML: Enterprise Components and Process, De Luca, Coad and Lefebvre (1999).
17 Test-Driven Development by Example, Beck (2003).
18 Extreme Programming Explained: Embrace Change, Beck (1999).
19 OECD Principles of Corporate Governance, Organisation for Economic Co-operation and Development (2004).
20 OECD Principles of Corporate Governance, Organisation for Economic Co-operation and Development (2004).
21 The New Economics for Industry, Government, Education, Deming(1993).
22 JURAN Institute’s Six Sigma Breakthrough and Beyond -Quality Performance Breakthrough Methods, De Feo and Barnard (2005).
23 The Essence of Winning and Losing, Boyd, n.d.
24 Out of the Crisis, Deming, pp.23-24: Fourteen Points© Massachusetts Institute of Technology, by permission of MIT Press (1982).
25 The New Economics for Industry, Government, Education, Deming (1993).
26 Capability Maturity Model Integration, Carnegie Mellon University; Software Engineering Institute, n.d.
27 CMMI® is registered in the US Patent and Trademark Office by Carnegie Mellon University.
28 CMMI® or Agile: Why Not Embrace Both!, Glazer, Dalton, et al (2008).
29 Extreme Programming from a CMM Perspective, Paulk (2001).
30 Love and Marriage: CMMI and Agile Need Each Other, Glazer (2010).
31 CMMI® or Agile: Why Not Embrace Both!, Glazer, Dalton, et al (2008).