When introducing agile methods we need to consider factors such as lifecycle coverage, roles, and activities. Methodology Scope Diagrams provide a way of illustrate these characteristics and quickly highlight gaps in coverage for further consideration.
For example, many agile methods don’t really start until a candidate list of features has been identified. So while they may offer great ways to develop software, they may not provide much in the way of project feasibility guidance. Before discarding existing practices, we need to determine if they are really required and if so, if they need to be replaced or retained.
Methodology Scope
In the book “Agile Software Development” Alistair Cockburn illustrates the three dimensions of a methodology scope as follows.
Figure 1 - Methodology Scope
Along the horizontal (X) axis we have the project lifecycle starting with the early stages of Envisioning and Feasibility of a project, then progressing through Requirements, Design and Code stages until ending with Deployment, Training and Maintenance. The vertical (Y) axis shows the project roles covered by the methodology and the depth (Z) axis illustrates the activities addressed by the method. The area shaded green depicts the coverage of methodology scope by the approach in question.
In the Figure 1 example we can see that the methodology in question covers the lifecycle from just before Requirements until just before Deployment, addressing all the roles except Training, Secretary and Contractor and coving the Product Development and Time Recording activities.
Using these dimensions to examine agile methods is a useful way to highlight differences between various approaches.
Extreme Programming (XP) is a development focused approach which offers increased productivity, improved quality and responsiveness to changing requirements via a set of simple, yet high disciplined practices and values. XP targets the key development and testing elements of a software project and offers some supplemental task planning and development estimating guidelines. As such it has a relatively small methodology scope because it does not tackle all the phases, activities or roles of a software project instead focusing on the (most critical) development aspects or a project. Figure 2 shows the methodology scope for XP.
Figure 2 - XP Scope
The X axis of Figure 2 illustrates that XP is focused on the Requirements, Design & Code and Testing portions of the lifecycle, it does not address earlier activities such as Envisioning or Feasibility or later elements like Training or Maintenance.
The Y axis illustrates the XP Role focus on Developer, Testing and Business representatives. There is little coverage for DBA’s, PM’s or Support. It is possible to argue that some traditional roles such as Quality Assurance and Training are covered within XP because the Test First principles recommended assure a higher quality of software than typically developed using traditional methods. Likewise, XP’s emphasis on user collaboration and increased user input negate the need for a Training role as enough ambassador users will be very familiar with the application to train users new to the system. However, particularly in enterprise environments, these arguments are not valid. Quality Assurance plays a much larger role than verifying software correctness, as it also validates communications, training materials, hand over and sustainment provisioning. Similarly, Training responsibilities may involve significant collateral creation and many rounds of user training for widely used systems.
The Z axis shows how XP concentrates on the activity of Application Development and does not tackle Project Coordination. This narrow area of focus should not be regarded as a weakness of XP, but instead as an effective means to target the primary pain-point for many organizations, XP represents a small, “insertable” solution for development teams. The lifecycle from Requirements to Testing, involving the business, developers and testing seems to be the most critical portion of a project. Creating better ways to work in this core project segment has lead to the popularity and benefits of successful XP projects.
Methodology Scope as a barrier to Adoption
However, for some environments this narrow focus is not enough, people want a methodology that also tackles Project Coordination activities and Project Management roles. Alternatively the existing activities and roles currently in place within the organization do not fit well with XP and so compatible approaches are required. A common addition or partner for XP is Scrum. Scrum does not attempt to tackle “upstream” activities such as project feasibility but it does cover most of the day to day PM responsibilities and general project coordination. Figure 3 shows how XP and Scrum augment each other well to address more of the overall methodology scope.
Figure 3 - XP + Scrum Scope
By combining Scrum with XP the key activity of Project Coordination is addressed. Due to XP’s focus on development team at the core level of requirements, code and testing, and Scrum’s focus on the higher, coordination level, Scrum is often called a “wrapper” for XP. Scrum does not provide detailed guidance at the development level making it easy to insert XP and yet it provides compatible management guidance to wrap around development activities.
So, Scrum seems an ideal partner for XP in some respects but their combination still fails to address major portions of the methodology scope model. There is no support for the early Envisioning, Feasibility and Setup phases of a project, or Deployment, Training and Maintenance phases. Roles such as QA, DBA and Training get scant coverage and while internal PM responsibilities are covered, interfaces to portfolio management and PMO’s are not addressed. “So what?” some say, “These things are peripheral, unique to each environment, and of lower overall value”, all true, but their omission is slowing the adoption of agile methods in enterprise organizations.
Pragmatists not only need to be sold on the benefits of agile, but also convinced of the practicality of adopting such an approach. “Where does it address X?” and “How will it integrate with existing process Y?” are common questions that are difficult to answer with some narrowly focused agile methods. Agile buy-in can be slow in large enterprises because the mind set of key decision makers are put off by the gaps. They are the pragmatists who are less inclined to try new approaches based on potential benefits; they want to see a clear roadmap of how all the pieces will integrate before committing to an approach.
Successful process introduction is more about communications, education and selling the benefits of a new approach to an organization than the processes in question. Process definition is the easy part; it is process acceptance, adoption and sustainment that are the difficult elements to achieve.
When selling the benefits of agile methods to an enterprise, the requirements of the pragmatist must be addressed. While project Feasibility and Setup may seem less important than coding, if their omission from a method prevents or slows adoption then they suddenly take on a new significance. The sad fact is that many organizations are reluctant to try agile approaches because they cannot see a clear end-to-end replacement for their existing process or fail at interfacing existing procedures to agile methods.
Sometimes organizations need to see some additional governance set up to support the perceived gaps in the methodology. This idea is shown in Figure 4
Figure 4 – Additional Governance
Regardless of how much method guidance your organization needs (or ideally, how little it can be operate with) Methodology Scope Diagrams are useful tools to aid the discussions.
The following thumbnails show the scope coverage for a variety of popular methods. More coverage is not necessarily a good thing, it means there is more to potentially introduce, more to train people how to use. For example, Scrum has seen a good uptake partly because it is easy to explain and get started with. On the other hand some of the broader methods may help if it has coverage of an area a company is struggling with. As always, it depends on a variety of factors.
Comments