5.4.1 The Greater the Anticipated Risks, the Greater the Need for Upfront Planning

Generally speaking, the higher the risks anticipated for a venture, the more upfront analysis and planning will be needed. For example, a high-cost, fixed-contract initiative with an external solution provider exposes the business to the risk of high, unexpected costs: missed requirements can result in cost overruns, missed launch dates, and risks to the customer experience. To mitigate these risks, you need to extend activities in the Initiation and Planning zone to allow for a comprehensive risk analysis in the plan.

5.4.2 What’s Past Is Prologue⁷

7. “Whereof what’s past is prologue.” See William Shakespeare, The Tempest, act 2, scene 1, line 217, PlayShakespeare.com, https://www.playshakespeare.com/the-tempest/scenes/act-ii-scene-1

Tap into the collective wisdom of the organization regarding similar initiatives when determining how long to spend on preparation and planning activities. Reach out to key individuals who were involved in these activities in the past. Ask them which activities can be safely postponed until development and which, in their view, should be performed up front because the cost of delaying them would be prohibitive to a successful outcome.

5.5.1 Differentiating Quadrant (Top Right)

The model includes four quadrants based on levels of market differentiation and mission criticality. Use the top-right quadrant in Figure 5.2 for mission-critical products or capabilities that are market differentiators. Items landing in this category should be developed in-house by long-lived teams because they have to be continually improved for the product to remain competitive.

5.5.2 Parity Quadrant (Bottom Right)

The bottom-right quadrant in Figure 5.2 is for mission-critical capabilities that are not core differentiators. Parity with the market standard is sufficient for these items, since excellence is unlikely to affect customer choice.

Develop items in this quadrant in-house, or outsource them. Weigh the immediate savings of outsourcing against future costs. Keep in mind that choices made early on can have a significant impact on the cost of future changes.

One example of a parity capability is eBay’s payment processing. Payment processing is a parity capability for eBay because it’s mission-critical but not a differentiator. Early on, when the business case for eBay was, as yet, unproven, it outsourced payment processing to PayPal in order to deliver the capability quickly with minimal upfront investment. By 2002, eBay’s volume grew to the point where it no longer made financial sense to outsource the service, and the company brought it in-house by purchasing PayPal.

Many businesses face a similar decision regarding cloud services, such as AWS (Amazon Web Services). At the outset of product development, the use of these services speeds time to market, provides scalability, and doesn’t require a substantial upfront investment. However, once the business grows, the cost of these services often tips the scale in favor of in-house development.

If an outsourced solution is to be used, explore ways to reduce future costs in case the solution needs to be replaced when volumes rise. Costs can be significantly reduced by building adaptability into the design from the start, such as through strategies like service-oriented architecture (SOA) and the use of outgoing APIs for messages to third-party services.

5.5.3 Partner Quadrant (Top Left)

Use the top-left quadrant in Figure 5.2 for capabilities and products that are differentiators but outside the company’s core mission and competency. For example, consider a training company whose value lies in its intellectual content—the courseware, workbooks, and so on, that it provides to its customers. Suppose that it decides to launch an eLearning platform. The platform is not the company’s core competency, but it is a crucial differentiator. The preferred option is to develop the services collaboratively through a long-term partnership with a third party. That option provides a stable basis for ongoing innovation in a critical area without diverting the company from its core mission.

5.5.4 Who Cares? Quadrant (Bottom Left)

Use the bottom-left quadrant for capabilities that have low mission-criticality and market differentiation. Spend as little resources as possible on these capabilities. Consider excluding them from product development due to their low value to the business.

5.6.1 Transitioning from Manual to Automated Testing

Test automation is key to enabling a company to deliver changes to the market with speed and confidence. If your organization is transitioning toward automated testing, use the test pyramid in Figure 5.4 as a guideline to determine where to focus the automation effort for maximum benefit.

The figure illustrates the relative prevalence of tests by test type. The type with the most tests is at the bottom of the pyramid. The type with the fewest is at the top. (Other versions of the pyramid, such as Martin Fowler’s, may vary from that shown in Figure 5.4.)⁹

9. Martin Fowler, TestPyramid, MartinFowler.com, November 15, 2017 (originally published May 1, 2012), https://martinfowler.com/bliki/TestPyramid.html

At the top of the pyramid are manual tests. These should be the least numerous because they are the most time consuming and expensive to run.

Next are automated user acceptance tests. There should be fewer automated tests of this type than the types below it on the pyramid. There are several reasons for this:¹⁰

10. Fowler, TestPyramid.

• User acceptance testing (UAT) tends to be brittle. Changes to the user interface can easily break existing tests.

• Automated UAT scenarios are expensive to write.

• User acceptance tests have a propensity for nondeterministic behavior (i.e., they provide inconsistent results for the same test, making them difficult to diagnose).

Automated lower-level integration tests verify the connection between one software component and another, such as the connection between a programming unit and an API to which it sends messages. These automated tests should be more numerous than user acceptance tests because they are less brittle. Most automated tests should be unit tests, because

• There are more low-level units to test than higher-level components.

• Unit tests are frequently reused in regression testing and are a critical capability for enabling reliable, continuous delivery.

• Automated unit tests are less subject to change than other test types.

Use the testing pyramid to guide the transition to test automation for software that’s already been written:

• Focus test automation, at first, on end-to-end UAT (at the top of the pyramid), since you won’t need many of these relative to other types of tests.

• Next, focus on automating lower-level integration tests.

• Finally, create automated unit tests (bottom of the pyramid) for existing software units.

When prioritizing the automation of new software units, advance through the pyramid in the opposite direction, from the bottom up. Developers should begin creating automated unit tests and low-level integrations tests as part of their coding process. All new software units should include these tests and pass them before being accepted. Expect testing-automation activities to take up about 50 percent of a developer’s coding time. As an analyst, you collaborate with others to specify UAT.

5.6.2 Timing the Automation of the Build and Distribution Processes

When transitioning to automated build and distribution processes, focus investment on new products, because decisions made early in the product’s lifecycle have a disproportionate impact on future automation costs. For example,

• A system designed at the outset to use Web Services (e.g., AWS) for its build and distribution processes can be built and scaled later at much less cost than one that relies heavily on manual intervention.

• New releases of a product designed at the outset as a website are easier to distribute reliably than a product designed as a mobile app or as a laptop application. The former requires updates only at the server end, whereas the latter involves users’ participation—introducing unreliability because some users may not participate.

5.7.1 Guidelines for Forming Agile Teams

5.7.2 Organize around Value

Organize teams around value, not competencies, so that each team can deliver value to an end user or customer with minimal dependencies on other teams. Figure 5.5 is an example of teams organized around value in a small development organization.

In the example in Figure 5.5, the product is small enough for each team to be able to contain all the required competencies.

Note that the boxes within each team in Figure 5.5 refer to competencies, not individuals. An individual may have more than one competency, and a competency may be practiced by more than one individual on the team.

The benefit to the business in organizing by value is that it can adapt the product quickly and reliably in response to changing circumstances, new opportunities, and threats.

5.7.3 Feature Teams versus Generic Teams

As a general rule, the best organizational strategy is to create long-lived feature teams that each specialize in a product area. A product area is a subset of the product representing a high-level use case (usage) or feature set. Over time, the team gains expertise in its product area, resulting in optimized performance and reduced turnaround time. For an example of teams of teams by product area, see Figure 17.4 in Chapter 17.

The exception is during the early stages of new product development when teams should be generic. Generic teams at that time enable managers to allocate resources dynamically in response to changing demand. Once the product has stabilized, though, and demand is more predictable, teams should organize into long-lived feature teams.

5.7.4 The Extended Team

Once a product matures and becomes more complex, you typically can’t contain all the required competencies within a small agile team of about ten or fewer members. Fully self-sufficient teams are no longer possible. Instead, teams need to collaborate. They often need to share members, too (as noted in section 5.7.1.6).

Figure 5.6 illustrates the structure of a feature team for a mature product, highlighting dedicated and shared team members. The following is one example. It’s not a general prescription. Individual team structures will vary.

The core development team in Figure 5.6 consists of one team analyst and three or more full-time developers. The extended team includes shared members: these are marketing and business SMEs, high-level business analysts, a development manager shared among no more than two teams, a UX designer shared among one to three teams, QA and DevOps professionals to coach the team in automated testing and integration, and support for the software components used by the team.

5.7.5 Why Organizing by Competency Is Bad for the Business

As noted earlier in the chapter, it’s a common mistake to organize teams by competency instead of by value. Team organization may sound like an issue of little concern to the business or business analyst, but it’s not, because poor organization delays time to market.

Figure 5.7 illustrates why. It depicts a development organization for a messaging product, organized by competency.

In Figure 5.7, there is one team to handle high-level BA and a team for each technical layer of the application: ingestion (loading messages into the app), data layer, API, front end, and Web server. The trouble with this arrangement is that no single team can deliver value on its own. For example, a feature to add a new message type requires

• Analysis by the BA team.

• Work by the ingestion team to load the new message type into the system.

• Work by the data layer team to enable the new message type to be stored in the database.

• Work by the front-end team to allow the new messages to be displayed.

If any of these teams finishes early, the feature can’t be released any sooner. The feature is only releasable once all the other teams have completed their work. This structure also increases the number of handoffs and approvals per feature. Each handoff introduces a time lag to wait for approvals, to plan, and to allocate tasks for the next team—increasing the overall time it takes to bring change requests to the market. If teams are currently organized this way, champion transformational change to prevent these negative impacts. As we’ve seen, that means organizing teams by value into feature teams.

5.8.1 The Negative Expectation That Requirements Delayed Are Requirements Denied

A common expectation of stakeholders new to agile development is that requirements that don’t make it into the first cycle will never get implemented. Stakeholders have often learned this lesson from negative experiences with waterfall development. The consequence is stakeholders who assign high priorities across the board to requirements items. This outcome is anathema to agile development, since the approach is based on the phased rollout of requirements over time.

To head off this problem before it becomes an issue, meet with stakeholders early on to explain the agile trade-off: the customer gets the benefit of shortened time to market and continuous delivery of features instead of the long lag time that is typical of waterfall processes. However, to obtain those benefits, business stakeholders have to prioritize some requirements over others because agile development is, by nature, incremental. Another advantage of agile development to stakeholders is that they can change their minds at any time and reprioritize requirements based on changing circumstances.

Sometimes it helps to flip the terminology: instead of speaking about prioritizing requirements, talk about sequencing them—reframing the conversation from one about values to a practical one about problem solving.

Make sure stakeholders also understand that they don’t have to make prioritization decisions on entire features. For example, they may decide to implement some stories of Feature X first, followed by some stories for Feature Y, followed by more stories for Feature X.

There’s nothing more persuasive than the evidence of one’s own eyes, though, to convince stakeholders that agile’s incremental approach works and that requirements delayed are not requirements denied. Provide opportunities for stakeholders to meet teams and customers who have been using agile development successfully. Arrange for experienced agile teams to invite new stakeholders to sit in as observers during product demonstrations.

5.8.2 Productivity Expectations

A few years ago, I was speaking with an executive about his company’s planned agile transition. He told me that stakeholders were very enthusiastic about “agile getting their products to market much quicker.” I should have been pleased, but I was concerned. Business stakeholders sometimes mistake agile’s promise of early delivery to mean that they can get all the requirements they want in much less time than waterfall. The reality is not so straightforward. For example, in Chapter 2, “Agile Analysis and Planning,” I quoted a QSM study that found that agile projects received a 16 percent productivity increase compared to the industry average.¹³ It is a significant benefit—but far from the expectations of “several 100 percent” gains in productivity made in the early days of Scrum.¹⁴

13. QSM Associates, The Agile Impact Report, Proven Performance Metrics from the Agile Enterprise (Boulder, CO: Rally Software, 2015), 5, https://www.rallydev.com/sites/default/files/Agile_Impact_Report.pdf. Productivity was measured as an aggregate of tooling and methods, technical difficulty, personnel profiles, and integration issues.

14. Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2002), viii.

On the other hand, the same study found that “Agile Projects are 37% faster to market than [the] industry average.”¹⁵ How can agile development result in faster time to market without corresponding increases in productivity? The answer lies in what is delivered: agile development enables a business to bring something to market quickly—but not the whole wish list. What agile development delivers quickly is a minimum marketable product with a limited set of features. Make sure stakeholders understand that the approach speeds time to market by focusing effort on the highest-value features, not by delivering the same set of features in less time. The value of agile development lies in learning that not all the requested features are actually needed—or that less-costly versions will be able to get the job done just as well.

15. QSM Associates, The Agile Impact Report, 4.

Another common but incorrect expectation is that productivity improvements will come quickly as an organization transitions to agile development. More commonly, it can take a few months to a few years for teams to get good enough at agile development for improvements to be realized.

Stakeholders also can have mistaken expectations about what will be delivered frequently. Many expect that software updates will be delivered to the market at least every one to two weeks (the length of a typical Scrum sprint). That may be the case for some updates, but it’s often not so for major features. Although deployment to a testing environment occurs continuously, it can often still take two to three months to deploy significant changes to the market. The benefit of agile development, in this case, is that the delivered solution will be

• More relevant—since it is based on current priorities and requirements.

• More likely to delight the user—since it relies on user feedback throughout the development process.

• More cost-efficient—because it weeds out low-value requirements and eliminates administrative waste.

5.9.1 Customer’s Bill of Rights and Responsibilities

Following is an example of a customer bill of rights and responsibilities.

5.9.2 Developers’ Bill of Rights and Responsibilities

Following is an example of the developers’ bill of rights and responsibilities.

5.10.1 Measuring Success

In traditional waterfall project management, you measure success by the degree to which the solution delivers specified outputs (the deliverables) at a given cost within a specified time. You can’t use this approach on agile software initiatives because there is no baselined set of requirements to be delivered: by intention, agile requirements are subject to change at any time.

Agile initiatives measure success on the basis of desired business outcomes¹⁶ rather than prespecified outputs. You don’t ask, “Did the customer receive a product with the specified features on time and budget?” Instead, you ask, “Did the customer increase market share as much as expected?” or “Did it get the expected return on investment?”

16. Michael F. Hanford, “Program Management: Different from Project Management,” IBM Developer Works, May 14, 2004, http://www.ibm.com/developerworks/rational/library/4751.html

5.10.2 Discovery-Driven Financial Planning

Traditional financial planning approaches rely on past data to make projections into the future. This approach doesn’t apply when the product is novel because there is no historical or trend data to draw from. In such circumstances, financial planning methods need to take uncertainty into account and bake it into the plan.

One approach to doing that is by discovery-driven planning. With this method, instead of projecting an expected bottom line from historical trends, you begin by specifying the bottom line that must be achieved for the venture to be successful. Then you work backward to identify the assumptions you need to make to get there (e.g., assumptions about the price customers will pay and support costs). These assumptions then drive the planning process: you create a plan to test critical hypotheses as early as possible.

5.13.1 Challenge Compliance Assumptions

Be willing to challenge assumptions about compliance rules. There is often much more room for give-and-take than you might first expect. The following real example is instructive: A company was planning to use a third-party vendor for new product development. The auditor was concerned that the vendor might change agreed-upon requirements. This concern was expressed in the following rule: “If a vendor logs in to the requirements repository, the vendor is prevented from changing requirements.” The lead analyst determined that the rule would not be easy to enforce, so he pushed back. They agreed that only a “controlled environment” would be needed for compliance—and that the unique, trackable login identification already provided by the repository on changes was sufficient.

5.13.2 Do Compliance After Process Design

One of the most useful pieces of advice regarding compliance and agile development comes from Andre Franklin, a process and systems analysis expert in drug research and development services—a highly regulated sector—who provided this guidance: Don’t have auditors determine what the process should be. Design the process first the way you want it. Then bring the process to auditors for approval. That way, practitioners do what they do best—design processes—“and auditors do what they do best—audit processes for compliance.”

5.13.3 Focus on Goals, Not Means

Another effective strategy is to argue that though an agile process may use nontraditional lightweight methods, it still achieves the goals behind compliance regulations.

For example, it is sometimes assumed that testing standards strictly govern the testing process, whereas they often only define goals for testing; that there must be a well-defined testing process in place; that it must be followed; and that it must lead to a low defect rate. There is often a great deal of latitude, however, on how to achieve those goals. The DevOps automated environment used in agile development often achieves the goals of standards, because it results in high levels of testing, leading to low defect rates. For example, Cohn reports that CMMI compliance up to level 5 has been achieved with agile frameworks.¹⁹

19. Cohn, Succeeding with Agile, 400. Cohn lists Philips Research and Systematic as examples of companies achieving CMMI compliance with agile processes.

The same is true concerning documentation: while the types of documents required for compliance are often nonnegotiable, there is often flexibility regarding the form the documentation takes. Even minimalist documentation, in the form of photo images of whiteboard designs, can be sufficient to satisfy compliance regulations.

Concerning ISO 9001, a study of agile organizations concluded that “an agile process [can] produce documents that can be used (1) as proof of conformance and that (2) can be reviewed as part of ISO 9001’s verification and validation” and that “there will be no problems whatsoever when a company wants to use agile development and still keep its ISO 9001 certificate.”²⁰

20. Tor Stålhane and Geir Kjetil Hanssen, “The Application of ISO 9001 to Agile Software Development” (conference paper, Product-Focused Software Process Improvement, 9th International Conference, PROFES 2008, Monte Porzio Catone, Italy, June 23–25, 2008), p. 14.

5.13.4 One-Time Experiments

If you aren’t successful at gaining governance and compliance adaptations for agile development at the enterprise level, try negotiating such governance changes as one-time experiments.

5.15.1 Agile Fluency Model

The first step in getting from a current to a desired level of agility is to determine what those levels are. Use the agile fluency model, devised by Shore and Larsen,²¹ to grade your organization’s current and target levels of agile fluency. It characterizes each successive level as a zone, as follows:

21. James Shore and Diana Larsen, “The Agile Fluency Model: A Brief Guide to Success with Agile,” ThoughtWorks, March 6, 2018, https://martinfowler.com/articles/agileFluency.html

• Zone 1: Focusing. Teams produce business value.

• Zone 2: Delivering. Teams deliver value on market cadence (i.e., based on demand from the market).

• Zone 3. Optimizing. Teams lead their market.

• Zone 4. Strengthening. Teams make their organizations stronger.

Zone 4 is the highest agility level, but it’s not necessarily the correct destination for every organization. Your goal should be to choose the right target zone (or zones) for the situation. The entire enterprise doesn’t need to set the same target. Guidelines for assigning zones are provided in the following sections.

5.15.2 Transitioning the Team

If the development team has not practiced agile development before, a coach should mentor the team for the first couple of months, after which you (the analyst) or another full-time team member, such as a ScrumMaster, should take over the role. At this time, the coach moves to the sidelines, returning to work with the team as needed.

The aim should be to advance the team’s agile fluency level to the desired target zone, according to the agile fluency model. The focus should be on improving the structural aspects of the team. The Tuckman model,²² which describes the stages of a maturing team, may be used to guide these improvements at the team level. Teams should be guided through the forming stage (where there is a high dependence on the leader), to storming (where team members jostle for position), to norming (where consensus forms), to performing (where the team is united in purpose and self-sufficient).

22. Denise A. Bonebright, “40 Years of Storming: A Historical Review of Tuckman’s Model of Small Group Development,” Human Resource Development International 13, no. 1 (2010): 111–120, https://doi.org/10.1080/13678861003589099

5.15.3 Transition Activities at the Enterprise Level

If the organization is new to agile development or is practicing it but struggling with the approach, a full change management process will be needed to improve agile practices across the enterprise. The following sections provide guidelines for creating and accelerating that change according to Kotter’s eight-step process.

5.15.4 Transition Timeline

It can take six months or more to get good enough at agile development to begin to realize improvements. The timeline for a complete enterprise transition varies widely according to the organization’s culture, structure, and level of competency in agile development. To give you one example of how such a transformation can play out, the following is a case study, as it unfolded for one of my clients. The client reported these results at the end of Year 2 in the timeline.

5.15.5 Communications Plan

The change management plan should contain a communications plan. The plans should be supported by an active and committed coalition of sponsors and volunteers. Measures in the change management plan, such as stakeholder analysis and the identification of resistance, should drive the communications plan.

The communication plan should describe the communication methods to be used. Aim to optimize the quality of communications within the team, between teams, and between teams and business stakeholders. Use the highest-quality mode possible. In order of preference, these modes are

• In-person conversation.

• Video call.

• Virtual meeting.

• Asynchronous communication: Methods include wikis, SharePoint, messaging services, email, and updates made through software applications and services.

• Conference call (audio).

Teams are increasingly synchronizing their efforts through the asynchronous approach: when CI/CD is practiced (as is advised), then updates to version control and code repositories serve to communicate changes across teams. Changes to requirements, their priorities, and their statuses can also be tracked through requirements management tools.

If teams are colocated, use in-person communication as your preferred method of contact; use the lower forms only when necessary. If teams are distributed, favor video calls because members can see who’s speaking and read body language. The next best option is Web conferencing that enables shared presentations and communication via text or voice. Examples are WebEx and GoToMeeting. This is a good option if the conversation is mostly one-way (e.g., a status update). Use telephone conference calls only as a last resort.

5.15.6 Agile Enterprise Transition Team

If there is no other body in place to do so (such as an agile CoE or a PMO), create an agile enterprise transition team to champion agile practices within the organization and provide resources for those who need assistance applying them. The team should meet regularly (about every two weeks) and keep its own backlog of work items. More information on the enterprise transition team can be found in The Enterprise and Scrum, by Ken Schwaber.²⁶

26. Ken Schwaber, The Enterprise and Scrum (Redmond, WA: Microsoft Press, 2014).

5.16.1 Organizational Readiness Checklist

Use the following checklist of key questions to determine organizational readiness for agile initiatives.

Does the culture invite change and innovation and support a customer focus?