CHAPTER 1: AN EXECUTIVE BRIEF ON AGILE²

What is Agile?

'Agile' is a collective term for methods (and practices) that have emerged over the past two decades to increase the relevance, flexibility and business value of software solutions. These approaches are specifically intended to address the problems that have historically plagued software development activities in the IT industry, including budget overruns, missed deadlines, low quality outputs, and dissatisfied users.

Although there is a broad range of Agile methods in the IT industry – from software development and project delivery approaches to strategies for software maintenance – all of these methods share the same basic objectives:

• replace large up-front investment in software solutions with incremental investment based on business value returns
• focus project team members on delivering capabilities that generate the highest business value for the organization
• encourage ongoing communication between the business areas and project team members to increase the relevance, usability and quality of delivered software
• entrust and empower staff to deliver value
• position software solutions to be responsive to ongoing industry, organizational and technology changes.

Some of the most common Agile methods include:

• iterative strategies for managing software development projects, such as Scrum, Dynamic Systems Development Method (DSDM), Feature-Driven Development™ (FDD™), the Rational Unified Process® (RUP®), and the Agile Unified Process (AUP)
• strategies for optimizing software development work, such as eXtreme Programming (XP™), and Lean Development
• strategies for managing software development projects, as well as maintenance and support activities, such as Kanban and Scrumban
• extensions of Agile methods to support large enterprise-wide teams and shared corporate objectives, such as the Scaled Agile Framework® (SAFe®), Scrum of Scrums, Large-Scale Scrum Framework (LeSS) and Nexus.³

These Agile methods have been (and continue to be) successfully used by thousands of organizations worldwide⁴, most notably in the United States, Europe and Australia. Some of the more prominent organizations using Agile methods include Nokia Siemens Networks™⁵, Yahoo!™⁶, Google™⁷, Microsoft™⁸, BT™⁹, Bankwest™¹⁰, SunCorp™¹¹, and Wells Fargo™¹².

In order to fully appreciate the effectiveness of Agile methods, it is worthwhile taking a couple of minutes to understand the business environment that caused these approaches to be established in the first place.

A two-minute history of Agile

In the 1990s, the IT industry was plagued by the remarkably high failure rate of software development projects; projects that became notorious for their missed deadlines, substantially overrun budgets, faulty deliverables and dissatisfied customers. A handful of thought leaders in the industry believed that these IT project failures could be attributed to three key factors: over-planning, insufficient communication and ‘all-at-once’ delivery.

Over-planning

IT software projects traditionally began with the production of extensive ‘up-front’ documentation, including project plans, functional requirements, system design specifications, and technical architectural designs. These documents, which often took months to produce (and even longer to get approved), were intended to ensure that the developed software would align with user requirements. In reality, however, these documents only served to provide corporate managers with a false sense of security in the expenditure of their IT budgets; and to ensure that delivered software would be substantially misaligned with the ongoing – and changing – needs of the business.

The biggest problems with organizations relying upon up-front documentation were:

• the lack of responsiveness to ongoing changes in user requirements, market demand, internal resource availability and the capabilities of the underlying technologies
• the tendency for stakeholders (e.g. business areas, customers) to:
• o not clearly articulate their requirements (which were then left to the discretion of the technical team to interpret)
• o want everything under the sun (resulting in highly critical business requirements being lost in a sea of extraneous requirements)
• the inevitable misalignment between text descriptions of the users’ needs and the resulting software.

The bottom line is that software products delivered to meet these up-front design documents were destined to fail – and businesses were losing millions in the process.

Insufficient communication

The second overwhelming driver in the ongoing failure of software development projects in the 1990s was the traditional – and often deliberate – separation of the business areas that required the software and the technical staff responsible for delivering the solution (i.e. development in a vacuum).

Once the big up-front design documents for an IT project were finalized, they were generally handed over to the technical team for development. The technical team was then sent back to their desks (often located in a separate section, floor or even building from the business areas) with a pile of paper and an immutable deadline. The next time that the technical team interacted with the business area was when they installed the resulting software on the users’ machines for acceptance testing (or, even worse, production use).

This isolation created inevitable issues with the resulting software, including:

• user requirements left to the interpretation of the technical team members, without the benefit of understanding the business context
• the inevitable disconnect between the two-dimensional concept proposed in the documentation and the manifestation of that concept into tangible screens that the user could interact with
• not allowing for changes to business requirements that may have occurred between the time that the user was last consulted and the months (and sometimes years) that followed before the resulting software was installed on their system.

All of these factors resulted in the delivery of software that was frequently misaligned to the needs of the business users, including inadequate workflows, system errors, critical design flaws and features that were rarely (or never) used by the business – with no remaining budget or resources available to address these issues.

‘All-at-once’ delivery

Software development projects in the 1990s depended heavily on ‘waterfall’ project management methodologies, where analysis, design, development, testing and delivery stages were undertaken serially, requiring the full completion of one activity before the next one could begin. The use of waterfall methodologies on these projects meant that software design could not begin until all of the requirements analysis was complete; software testing could not begin until software development was complete; and software was not delivered to the users until all of the preceding stages had been completed.

This use of waterfall approaches in the IT industry was intended to reduce business risk in project delivery, requiring each step to be completed to management’s satisfaction before further expenditure was incurred. In reality, waterfall approaches significantly increased the risk of IT project failure by:

• mandating big up-front documentation (with all of its related issues)
• discouraging responsiveness to changing requirements as the project evolved
• creating ‘silos’ of ownership that reduced communication across project team members.

Perhaps the most risky impact of these waterfall approaches, was delaying the delivery of tangible business outcomes until the very end of the project – when problems in the software are the most evident and changes to the software are the most costly.

Instead of enabling the organization to manage expenditures and risks throughout the software development project, executives were faced with an all-or-nothing proposition: keep pouring resources into a failing IT project, so that at least some value can be recovered from the previous investment, or end the project midstream and receive no tangible benefit to the organization. The ‘all-at-once’ delivery approach often left these executives with no other options.

There were, of course, other factors that influenced the high failure rate of software development projects in the 1990s, including limitations in technology and the lack of availability of skilled technical resources. However, the three issues outlined above – over-planning, insufficient communication and ‘all-at-once’ delivery – were factors that were within the control of the organization to change.

In order to combat the widespread failure of IT projects, a group of innovative thought leaders¹³ began to develop strategies and practices that were specifically designed to address these three issues. It is their insight, along with the contribution of many others that followed, which has resulted in the proven, business-value-driven Agile methods that are used throughout the world today.

The 10 core business benefits of Agile

The business value that Agile methods provide to organizations can be distilled into the following 10 core Agile business benefits:

1. Ongoing risk management: by regularly confirming and adjusting requirements based on ongoing interaction with stakeholders; and by delivering fully functional and tested software features, so that technical risks are identified and mitigated throughout the process.
2. Ongoing control of budget expenditure: by providing decision makers with the opportunity to review and assess the business value of deliverables in each iteration, with the option to adjust, postpone or stop ongoing funding based on the return on investment (ROI) of delivered work.
3. Rapid delivery of tangible outcomes: by focusing team efforts on regularly producing fully functional and tested software features.
4. A focus on the highest-priority features: by continually working with key stakeholders to confirm and adjust the work undertaken by the project team to align with the most current priorities of the organization.
5. Strong alignment with business requirements: by directly involving key stakeholders in the initial and ongoing review of developed software, and by incorporating their feedback throughout the process.
6. Responsiveness to business change: by adjusting work throughout the process to incorporate organizational, industry and technology changes.
7. Transparency in status tracking: by regularly providing tangible outputs for stakeholder review, combined with open communication channels and centrally available status-tracking tools.
8. Substantially higher quality outputs: by incorporating rigid testing regimes throughout the software delivery process; and by working regularly with stakeholders to confirm the usability and business value of delivered features.
9. Greater employee retention: by creating work environments that are based on high communication, empowering the team and trusting their expertise, encouraging innovation, and regularly acknowledging the team’s contribution to the organization.¹⁴
10. Minimized whole-of-life software costs: by incorporating usability, quality and extensibility into software solutions throughout the delivery process, which reduces support and maintenance overheads; and by allowing additional functionality to be integrated into the solutions more cost effectively.

These combined benefits position organizations to receive a range of real productivity gains¹⁵ from their software development activities. They enable these organizations to bring IT development work back under business control.

The following section provides an overview of some of the most common Agile methods, and identifies how each is designed to deliver these business benefits to your organization.

Common Agile methods

Figure 1, overleaf, summarizes the extent to which ten of the most common Agile methods deliver the 10 core Agile business benefits identified in the previous section:

Figure 1: Breakdown of the 10 core Agile business benefits by Agile method

Each of these methods is described in further detail in the following sections.

Scrum

Scrum is an iterative project management method most commonly used for Agile software development projects, but suitable for any project-based work. Scrum provides a framework for business areas to identify and prioritize work required, and for project teams to commit to the subset of priority items that they believe can be delivered in each two- to four-week iteration (or ‘sprint’).

Scrum requires the nomination of resources to provide key roles in the project, including:

• the Product Owner who represents the needs of the business, and is responsible for documenting and prioritizing solution requirements as input into ongoing planning
• the Scrum Team, a cross-disciplinary team charged with undertaking the agreed work in each sprint
• the ScrumMaster who facilitates the team’s work, removing project impediments and ensuring that appropriate Scrum practices are being followed by the team.

Core to the success of Scrum are two activities that are undertaken for each iterative sprint:

• the Sprint Planning Meeting, held at the beginning of each sprint, where the Product Owner, ScrumMaster and Scrum Team review the highest-priority items identified by the Product Owner and agree on the subset of priority items that will be included in the forthcoming sprint
• the Sprint Review, at the end of each sprint, which includes a demonstration of work completed in that sprint and a retrospective review of the work undertaken to enable continuous improvement for subsequent iterations.

Scrum also encourages teams to engage in daily stand-up meetings, short update sessions held each morning that enable the team to quickly review their completed and planned work and address any hurdles.

The progress of the Scrum Team’s work is communicated to stakeholders through monitoring and measurement tools, such as:

• the executive dashboard, a report that summarizes the work within (and across) Agile teams for easy progress monitoring across the organization
• the product backlog, a reporting tool that enables both stakeholders and project teams to monitor the progress of work against the agreed business requirements¹⁶
• the sprint backlog, a reporting tool that enables teams to monitor and manage their actual day-to-day work.

Scrum is arguably the most commonly used Agile approach worldwide, and a range of professional courses are available to certify people for roles such as the ScrumMaster and Product Owner. These courses foster the consistent and effective application of these roles in every organization. They are also intended to address common areas of misapplication in Scrum implementations, such the mistaken view of the ScrumMaster as a project manager (instead of a facilitator).

This collaborative approach to project management and status tracking – combined with regular reviews of tangible outcomes and business-driven prioritization of ongoing work – positions Scrum to deliver all of the 10 core business benefits of Agile.

Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM) framework is another iterative approach to managing Agile software development projects. It has its roots in Rapid Application Development (RAD), resulting in a strong emphasis on building prototypes and confirming the feasibility of the solution with the business prior to undertaking full development activities. This is evidenced by DSDM requiring Stakeholder Workshops, a Feasibility Report, a Feasibility Prototype and a Business Study to be undertaken prior to full implementation.

The practices that underpin DSDM are at the very heart of Agile methods, including active user involvement throughout the process, iterative and incremental development, frequent delivery of tangible outputs and empowering the team. Ongoing testing and quality control of software throughout the process are also emphasized. These practices combine to enable DSDM, like Scrum, to deliver all of the 10 core business benefits of Agile.

Unlike Scrum, however, the DSDM framework requires a range of artifacts (e.g. development plans, functional models) to be developed at each phase of the project to provide ongoing confirmation that planned work is aligned with the needs of the business.

Although the approaches differ, both Scrum and DSDM have the same core objective – the delivery of high business-value outcomes in controlled, iterative timeframes. Scrum provides a high-level framework for achieving this objective, and relies on communication between the participants to ensure that work undertaken meets ongoing business needs. DSDM provides a more structured framework to achieve this objective, requiring proposed work to be documented and confirmed prior to continuing to the next stage.

Feature-Driven Development™

Feature-Driven Development (FDD™) is an Agile method that combines elements of iterative project management with practices that are specific to software development. The basic driver of FDD™ is providing incremental value to the business by delivering complete, working product capabilities (i.e. software ‘features’ and ‘feature sets’) in every iteration.

FDD™ requires close collaboration with the business areas to establish an up-front ‘domain model’ of the business problem that the proposed system is intended to address. Once this domain model is identified, it is broken down (decomposed) into smaller units (i.e. ‘features’) that are able to be developed and delivered iteratively. Team members are then assigned to build nominated features which, once successfully tested, are incorporated into the larger system.

In many respects, FDD™ works from the same underlying principles as other Agile methods (e.g. Scrum), in that the project team works closely with the business areas to deliver regular, incremental value to the organization. However, FDD™ is far more prescriptive about defining the boundaries of the solution up front, assigning specific roles and responsibilities to the team members, and controlling the scope of each team member’s work during the actual software development process.

Based on the above, there is an argument to say that, although FDD™ delivers all 10 core business benefits of Agile, its ability to deliver ‘responsiveness to business change’ is limited. This is because the structure of FDD™ makes it less responsive to ongoing organizational, industry or technology changes that do not fit in with the originally identified domain model.

Lean development

Lean development (Lean) is an Agile method that combines elements of iterative project management with best practices in software design and development. Lean stems from the Lean manufacturing processes that originated as early as 1922¹⁷, but most closely aligns with the principles of Kaizen¹⁸ and Total Quality Management (TQM)¹⁹.

At the heart of Lean is value stream mapping, focusing on:

• identifying and confirming the business value of customer requirements
• delivering the highest business-value software features
• making software development processes as efficient as possible.

As a corollary to this, Lean promotes the identification and elimination of areas of waste within the software development process (e.g. project teams unable to progress their work because they are waiting on input from the business).

Another core principle of Lean is fast delivery (deriving from queueing theory and just-in-time practices), which encourages teams to:

• use pull techniques to respond to customer needs as they emerge
• align the volume and complexity of their work with their optimal capacity to deliver.

In support of this, Lean encourages the team to hold off on making decisions as long as reasonably possible in the software development process, to provide maximum flexibility in addressing ongoing business requirements.

Lean also incorporates stringent quality management techniques by enforcing system integrity at both the business requirements and technical levels, by promoting system optimization and software testing throughout the process, and by encouraging the team to regularly review and critique their work for continuous improvement.

In addition to optimizing the software development process, Lean focuses on the critical importance of having a cross-functional project team which is sufficiently skilled, resourced and empowered to continually deliver the highest value outcomes to the organization.

It is the combination of these factors that enables Lean to deliver all of the 10 core business benefits of Agile.

eXtreme Programming (XP™)

eXtreme Programming (XP™) is an activity-specific Agile method for iterative software development work. XP™ encourages software developers to produce and deliver the simplest possible technical solution required to meet the customer’s objectives; anticipates that requirements will change once the customer has had an opportunity to work with the delivered software; and encourages the ongoing improvement and optimization of the software based on customer feedback.

Unlike the ‘big up-front documentation’ approaches that burdened the IT industry in the 1990s, XP™ documents business requirements at a high level – and then works hands-on with the customer to deliver their desired outcomes using the simplest designs, delivered in the earliest possible timeframes.

XP™ incorporates the use of an Agile practice called Test-Driven Development (TDD), which encourages software developers to create the tests that will be used to validate the code that they are building prior to undertaking development work. TDD is an innovative quality management approach, requiring team members to define and document their measures of success prior to undertaking the work required.

Another Agile practice used in XP™ is a concept known as refactoring, which allows the team to regularly review the existing system and modify it, where required, so that future software changes can be implemented more easily. Amazingly, this includes full authority for the team to throw away existing software in favor of a replacement solution that will provide the organization with greater flexibility to address future requirements. XP™ advocates that the short-term loss of work undertaken is worth the long-term opportunity for software solutions to grow with the organization more cost-effectively.

XP™ also utilizes a number of other Agile practices that enable its practitioners to regularly deliver high-quality output and reduce ongoing maintenance costs, including pair programming (having two members of the delivery team work together on assigned tasks to increase accountability and knowledge sharing), automated testing and continuous integration.²⁰

The iterative and customer-driven nature of XP™ enables it to deliver all of the 10 core business benefits of Agile; however, as XP™ is not a formal project management methodology²¹, its ability to influence ongoing budget management with decision makers is only able to be achieved indirectly through customer feedback (or in combination with other Agile methods, such as Scrum).

It is the simplicity of design, the expectation of change, and the freedom provided to the team to rethink and optimize software solutions that make XP™ one of the most well-regarded and widely used Agile methods.

Rational Unified Process®

The Rational Unified Process® (RUP®) is a framework of Agile best-practice approaches that are designed around iterative software development work, with a strong focus on identifying and addressing risks as early in the project as possible. Although the framework is flexible to adapt to the needs of each project, the primary objective of risk mitigation is a critical factor in every RUP® implementation.

RUP® work is commonly divided into four phases:

1. Inception: This is when the project scope is identified and confirmed through a business case, a description of the work, an initial (or basic) use case model, budget forecasting, an estimated delivery schedule, and a risk assessment. All aspects of the planned project work are confirmed by key stakeholders prior to progressing to the next phase.
2. Elaboration: This is when the team develops the bulk of the use cases (which document the users’ interaction with the system) and the system architecture for the solution. The primary focus of this phase is the identification and mitigation of technical risks in the solution. This is done by adding in use cases that specifically target identified risks, prototyping risk areas to show that they can be addressed, and by utilizing an executable architecture for the most critical use cases. Work within this phase can be done iteratively, with the most risky areas being addressed in the initial iterations. Original project estimations are confirmed during this phase, which includes the creation of a detailed development plan for stakeholder confirmation. The elaboration phase is considered complete when stakeholders are confident that all identified risks have been sufficiently addressed, that the system design is sound, and that the updated project schedule (including budget utilization and resourcing) is sufficiently accurate to proceed.
3. Construction: This is when the actual development work is undertaken by the team in support of the approved use cases. The RUP® is not prescriptive about the development platform that teams use, but strongly advocates the use of an object-oriented environment to facilitate the development and integration of discrete use cases, which then provides a greater opportunity for ongoing quality control and code reuse. Work in the construction phase is generally done across multiple iterations, culminating with an initial operational capability (IOC) review, where stakeholders assess developed capabilities and confirm project readiness for deployment.
4. Transition: This is when the approved capabilities are deployed to users with the necessary documentation and training to support the successful use of the solution in a production environment. Depending on the size of the system, work in the transition phase can also be done iteratively, with subsets of capabilities released when the organization is in a position to utilize them. Transition phase work continues until the users are able to utilize – and are satisfied with – all the released capabilities (i.e. the 'product release milestone').

A key differentiation between the RUP® and other Agile methods (e.g. Scrum) is that, with the RUP®, the iterative work of the elaboration, construction and transition phases is done within the boundaries of the initial scoping work that was done in the inception phase. Accordingly, the RUP® is considered to be an iterative software development method, instead of an iterative project delivery method. The result is that the RUP® can be used to mitigate the risks associated with implementing agreed functionality, but is less effective at addressing the risks of internal or external changes to business requirements as project work progresses.

For organizations transitioning from waterfall to Agile approaches in software development, the RUP® can provide a 'safer' starting point: one that introduces the project team to the principles and practices of iterative work without dramatically changing the upfront specification approach that they are familiar with. Similarly, for projects that are subject to existing scope constraints (e.g. fixed scope contracts), the RUP® offers a way to introduce some of the key benefits of Agile (primarily risk mitigation) within the immovable constraints of a fixed deliverable. It is, however, important to recognize the limitations of the RUP® in delivering all of the 10 core business benefits of Agile. Like FDD™, the RUP® framework has limited ‘responsiveness to business change’ because all of the project work is done within the boundaries of the initial scoping work that was done in the inception phase.

Agile Unified Process

For organizations that want the discipline of the RUP® and the benefits of XP™ practices, the Agile Unified Process (AUP) provides a 'best of all worlds' Agile approach.

The AUP works within the inception, elaboration, construction and transition phases of the RUP®, but simplifies the structure of the RUP® to seven key disciplines: model, implementation, test, deployment, configuration management, project management and environment. Importantly, the AUP incorporates numerous Agile practices (particularly XP™ practices) as part of the iterative work within the RUP® phases to ensure that development is continually focused on delivering the customer’s highest-priority features as an extensible, elegant, user-driven solution. To further supplement the risk management features of RUP®, the AUP advocates migrating iterative releases of tested functionality into a pre-production environment prior to the full transition of the solution into the live environment.

As described by its creator, Scott Ambler, the AUP is 'serial in the large' and 'iterative in the small'²².

The AUP provides lightweight documentation, with teams having the option to refer to more detailed guidelines as needed. The AUP is also adaptable, so that teams can apply those practices that are best suited to the needs of each project.

To facilitate the adaptation of the developed solution to meet ongoing business requirements, the AUP further encourages teams to use simple tools, scalable architectures and database refactoring.

In many respects, the AUP is the ideal approach for more traditional organizations that are transitioning to Agile methods, as it combines both the core principles of Agile and the power of XP™ practices with the risk management structure of the RUP® and the standard artifacts that organizations expect from a traditional software development process. It does, however, have similar limitations as the RUP® in delivering all of the 10 core business benefits of Agile, specifically in ‘responsiveness to business change’ due to the constraints established in the inception phase.

Kanban

Kanban is an Agile workload management and change management method that can be used in conjunction with or independently from other Agile methods. It is often used to manage IT support and maintenance activities, where priority work can change on a weekly, daily or even hourly basis.

At the heart of Kanban, is empowering the project team to regularly deliver business value by employing lean practices to make their work as efficient and manageable as possible. One of the primary methods for achieving this is by limiting the team's work in progress (WIP) at any point in time, enabling them to maintain their focus on completing the highest priority work.This approach enables the team to focus on completing a fixed number of tasks that are optimized for their capacity to deliver to quality standards: no more and no less.If the business requires a higher priority task to be addressed, stakeholders and team members must determine what current work should be postponed in order to free up sufficient resources to address the requirement. Equally, if the team has an opening in the WIP queue, they can pull in the next highest priority work identified by the stakeholders.

Kanban uses the practice of visualizing the workflow through the use of centralized Kanban boards to make the following information evident to all stakeholders at any time:

• the status of all of the team’s planned, current and completed work
• the team’s availability to take on additional work
• any hurdles that are preventing work from progressing.

Not only does this practice create an environment of open communication, transparency and collaboration; it promotes a culture of continuous improvement by encouraging teams to address bottlenecks, overcome hurdles, and maximize their productivity throughout the process.²³

Where Scrum prescribes managing work by time-boxed iterations, and FDD™ prescribes committing to work by deliverable features, Kanban is far less prescriptive on how a body of work is defined, or when it can be delivered. Instead, Kanban allows the team to establish review cycles and release timeframes based on the specific requirements of the organization. To accommodate this, Agile practitioners have begun using hybrid methods, such as Scrumban (a combination of Scrum and Kanban) to incorporate effective Agile practices, such as retrospectives, into the optimized workflows of Kanban. (Details on Scrumban are provided in the next section.)

It is important to note that Kanban is a method for managing what work is being done by the team, and for allowing the organization to continually adjust the tasks on the Kanban board to address the highest priority business requirements. Unlike other Agile methods, however, Kanban does not prescribe how the team works with stakeholders to identify and confirm software features, nor does it prescribe how these features are tested and integrated into existing software components. Accordingly, Kanban delivers most of the 10 core business benefits of Agile, with ‘strong alignment with business requirements’ and ‘substantially higher quality outputs’ only delivered to a limited extent.

Scrumban

In describing the range of Agile methods above, it was identified that most Agile approaches are designed to deliver efficiencies within a specific area of focus, such as iterative project management or iterative software development. In response to this, many organizations have chosen to implement hybrid or custom Agile approaches, which leverage the benefits across several different Agile methods.

One of the most commonly combined Agile methods is Scrum (as an overarching project management approach), which can be used in conjunction with more targeted software development methods (e.g. XP™ or Lean). In particular, there is significant use of the combined Scrum and Kanban methods (known as Scrumban) to integrate the flow management, visualization and lean principles of Kanban with the structure and practices of Scrum work.

The interesting thing about Scrumban is that it can be perceived (and implemented) in two distinctly different ways.

The first approach for implementing Scrumban is where teams apply Kanban capacity workflow management and lean practices within the Scrum project management framework. In this approach:

• the prioritized product backlog feeds the 'to do' column in the team's Kanban board with the aim of maintaining an optimal number of product backlog items in the queue at all times to ensure the ongoing availability of high-priority work
• the team manages their capacity (and focus) by controlling the number of product backlog items that are actively being worked on (their 'Work in Progress') and by 'pulling in' new work when they have availability²⁴
• all of the columns on the Kanban board have defined minimum and maximum limits, where exceeding these limits (in either direction) triggers actions to be taken to ensure continuous workflow
• standard Scrum practices (e.g. daily stand-ups, retrospectives) and Scrum roles (e.g. Product Owner, Scrummaster) are used, however:
• teams are less focused on the upfront estimates and commitments that are typically used in sprint planning, and more focused on ensuring that product backlog items are small and achievable to maintain consistency in their throughput cadence
• sprint retrospectives focus more on establishing lean process efficiencies to decrease the cycle time for each product backlog item (i.e., the time required to get each item through the flow and ready for release)than on the detailed analysis of velocity or confirming the accuracy of previous estimates.

In addition to flow management efficiencies, Scrumban focuses the team on visualizing the complete user story as they do their work, not just the subset of features in the current sprint backlog.

The second way of implementing Scrumban is more holistic, where focusing on the highest priority work carries up through the enterprise as a continuous process, not restricted by sprint structures or milestones. In this 'prioritization on demand' approach, the business feeds requirements into the backlog (and, subsequently, the 'to do' column of the Kanban board)as they become known - and then re-prioritizes them as often as needed to support emergent information. This means that Product Owners do not need to wait for a formal sprint planning session to have their new (or newly prioritized) requirements added to the team's 'to do' column - requirements can be updated and reprioritized as part of a continuous flow. This is what the author of the first materials on Scrumban²⁵, Corey Ladas, intended when he described it as a way of using Kanban to deliver lean software development across the enterprise.

Both approaches to Scrumban deliver the 10 core business benefits of Agile, although there is an argument to say that the second, more holistic, approach delivers greater responsiveness to business change overall.

Scaled Agile Framework® (SAFe®)²⁶

The Agile methods described in this section have focused primarily on team level project delivery, i.e., practices that are suitable for an individual small- to medium-sized development team. In larger IT departments with hundreds of developers, the organization may want to consider scaling these methods to enable the coordination of larger groups of resources towards shared objectives. This expansion is generally achieved by either:

• Scaling up the work that is done by an individual Agile team (particularly Scrum teams) to support the equivalent work across multiple teams - with aggregated artifacts (e.g. a shared product backlog across teams) and scaled communication channels. Examples of this type of approach include Scrum of Scrums, the Large Scale Scrum (LeSS) framework and Nexus²⁷
• Coordinating and driving Agile work at portfolio, program and project levels to synchronize the work across multiple Agile teams to align with shared corporate objectives. One of the most widely known and used approaches to achieve this is the Scaled Agile Framework® (SAFe®).

SAFe® provides a structure for integrating Agile work across the enterprise by identifying specific processes and roles for:

• managing the delivery of required outcomes through Value Streams (portfolio level), Program Increments and Releases (program level) and Iterations (team level)
• managing business requirements as Epics and Program Epics (across releases), Features (within releases) and User Stories (within iterations)
• managing the system architecture to ensure consistency and efficiency in system design at all levels, including an 'intentional architecture runway' to support planned work.

The SAFe® integrated framework provides:

a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis²⁸

allowing Agile work to be managed and monitored at every level of the enterprise.

To maintain the productivity and integrity of Agile methods, SAFe® also ensures that the core Agile practices of iterative work, test driven development, continuous integration and refactoring are undertaken at the team level, as well as providing overarching architectural governance and synchronization at the higher levels.

The official SAFe® website at www.scaledagileframework.com provides a complete picture of the framework, including detail on the processes, roles and outputs at each level.

As SAFe® supports Agile methods at the enterprise level, it is positioned to deliver all of the 10 core business benefits of Agile and, in many respects, can achieve this more broadly than Agile work that is used exclusively at the team level.

It is important to note that the descriptions in this section represent only ten of the Agile methods available to your organization. There are several other Agile methods in use (and emerging) throughout the IT industry, including Disciplined Agile Delivery (DAD) and Crystal. The More Information on Agile section at the end of this book provides you with links to industry resources on additional Agile methods for your consideration.

It may also be worthwhile reviewing an excellent comparison matrix provided by DevX at:www.devx.com/architect/Article/32836/0/page/4, which provides further detail about several of the Agile methods described above.

Who uses Agile?

As identified at the start of this chapter, Agile methods are used by thousands of organizations worldwide, including Nokia Siemens Networks™, Yahoo!™, Google™, Microsoft™ and BT™, to produce high business-value outcomes in the delivery of their software solutions. They have been equally successful in private and public sector organizations of all sizes, particularly throughout the United States, Europe and Australia.

As an example, one of the most common Agile methods, Scrum, is used by prominent organizations worldwide, including Adobe™, Barclays Global Investors™, BBC™’s New Media Division, BellSouth™, Bose™, CapitalOne™, Federal Reserve Bank™, GE™, Google™, Microsoft™, Motorola™, Nokia Siemens Networks™, SAP™, State Farm™ and Yahoo!™²⁹

A recent survey undertaken by VersionOne™ indicates that organizations that use Agile in their software delivery are achieving increased productivity (84% of respondents), faster time to market (77% of respondents) and improved ability to manage changes in priorities (87% of respondents).³⁰

This track record can give readers confidence in knowing that Agile methods are sustainable, proven approaches that are successfully used throughout the global marketplace. For executives, however, the most critical question is often: What can Agile do for my organization?

 

² For those who follow this author’s writing, some of the introductory material from Agile Productivity Unleashed and Everything You Want to Know About Agile has been adapted for use in this book, serving the same purpose as the original.

³ Further detail on these methods is provided in the Common Agile methods section of this chapter.

⁴ As evidenced by the number of signatories to the Agile Manifesto (www.agilemanifesto.org) as at December 2015.

⁵ NokiaSiemens and Agile Development, Haapio P, JAOO (2008): http://jaoo.dk/file?path=/jaoo-aarhus-2008/slides//PetriHaapio_CanAGLobalCompany.pdf.

⁶ Lessons from a Yahoo! Scrum Rollout, Mackie K (2008): http://campustechnology.com/articles/2008/02/lessons-from-a-yahoo-scrum-rollout.aspx.

⁷ Scrum Tuning: Lessons Learned at Google, Sutherland J (2006):https://www.youtube.com/watch?v=9y10Jvruc_Q.

⁸ Microsoft Lauds Scrum Method for Software Projects, Taft D K (2005): www.eweek.com/c/a/IT-Management/Microsoft-Lauds-Scrum-Method-for-Software-Projects/.

⁹ Agile Coaching in British Telecom, Meadows L and Hanly S (2006): www.agilejournal.com/articles/columns/column-articles/144-agile-coaching-in-british-telecom.

¹⁰ Bankwest goes Agile: project time slashed, Braue D (2010): zdnet.com/bankwest-goes-Agile-project-time-slashed-1339306091/.

¹¹ Suncorp goes Agile for 19k desktop integration project (2008): itnews.com.au/News/130927,suncorp-goes-Agile-for-19k-desktop-integrationproject.aspx.

¹² Is Agile Development Only for Nerds?, Matta E (2008): http://radiowalker.wordpress.com/2008/10/07/is-Agile-development-only-for-nerds/.

¹³ Including Kent Beck, Martin Fowler, Alistair Cockburn, Jeff Sutherland and Ken Schwaber.

¹⁴ From the team member’s perspective, this collaborative and supportive work environment is arguably the most important business benefit of using Agile methods.

¹⁵ See www.realproductivitygains.com for further detail on identifying and quantifying real productivity gains.

¹⁶ Some Scrum teams also use a Release Backlog to identify and manage subsets of capabilities that are planned for delivery in scheduled releases.

¹⁷ My Life and Work, Ford H with Crowther S, Garden City Publishing Company, Inc. (1922), ISBN 9781406500189.

¹⁸ KAIZEN - The Japanese Strategy for Continuous Improvement, Kotelnikov V www.1000ventures.com/business_guide/mgmt_kaizen_main.html.

¹⁹ TQM. Total Quality Management. An Integrated Approach to Quality and Continuous Improvement, Kotelnikov V www.1000ventures.com/business_guide/im_tqm_main.html.

²⁰ XP™ is better suited to technology platforms that support practices such as refactoring and continuous integration. Older and more restrictive systems may not be viable platforms for these practices.

²¹ Noting that there is an emerging interest in using the powerful techniques of XP for eXtreme Project Management

²² The Agile Unified Process (AUP): www.ambysoft.com/unifiedprocess/agileUP.html

²³ Some organizations choose to manage all of the work across a department on one Kanban board, with colored sticky notes used to distinguish separate initiatives. This enables commitments and resource availability across the department to be viewed more holistically.

²⁴ In Scrumban, when team members have completed a WIP task, they will first focus on what is needed to help other team members complete their WIP tasks before pulling in new work (known as 'swarming' to address the highest priority WIP tasks for the team overall). This can include taking on different roles (e.g. testing) to provide whatever assistance is needed to complete the task.

²⁵ Scrumban - Essays on Kanban Systems for Lean Software Development, Corey Ladas, 2009 Modus Cooperandi Press

²⁶ Designed by Dean Leffingwell and Scaled Agile, Inc.

²⁷ The More Information on Agile section provides links to detailed information on these methods.

²⁸ Introducing the scaled agile

²⁹ The use of Scrum by these organizations is documented in a number of sources, including corporate websites, industry publications (e.g. Microsoft Lauds Scrum Method for Software Projects, Taft DK (2005): www.eweek.com/c/a/IT-Management/Microsoft-Lauds-Scrum-Method-for-Software-Projects/), the work undertaken by industry experts such as Jeff Sutherland (www.scrumalliance.org/community/profile/jsutherland) and case studies at industry events, e.g. The Growth of an Agile Coach Community at a Fortune 200 Company, Silva K & Doss C, AGILE 2007 (13-17 Aug 2007), Washington DC: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4293562%2F4293563%2F04293600.pdf%3Farnumber%3D4293600&authDecision=-203.

³⁰ 9th Annual State of Agile Development Survey: http://info.versionone.com/state-of-agile-development-survey-ninth.html.