1

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 1/6

1.3 Module 3: Agile Lifecycle Strategically stable, but tactically emergent, iterative, and incremental

Module 3—Objectives Familiarize readers with the constituents of the agile lifecycle

Link the agile manager’s agenda with the features of the agile lifecycle

Agile Lifecycle Agile methods are the antithesis of the PD-PDLC. The Agile PDLC (Ag-PDLC) is strategically aligned with the business case at all times, but the tactical implementation is emergent and sensitive to the demands and priorities as they become apparent throughout the project lifecycle. In this sense, we say:

The agile project is strategically stationary but tactically emergent throughout its lifecycle.

A project management

tip

Agile PDLC, Ag-PDLC

Outcomes are incrementally planned and speci�ied, built iteratively, and delivered in frequent releases.

Agile projects are governed by a top-level business plan that envisions a product goal, top-level requirements, business milestones, and investment funding pegged to affordability.

Scope and quality, the budget, and the schedule are framed by architecture at the top level in the business plan but the details emerge as the project progresses.

Value accumulates incrementally as outcomes are committed to production.

Customers are allowed to change their minds from one release to the next in order to keep the value proposition ever in alignment with business and market realities.

The Ag-PDLC has three distinguishing characteristics that set it apart from the PD-PDLC:

Emergent: The processes and procedures used by the implementation teams are informed by experience; by the enterprise culture; and by the need to be consistent with any certi�ied protocols. Nonetheless, processes and procedures emerge from the team’s analysis of the requirements and tasks. In effect, teams adapt. Process control is achieved empirically by observation and reaction, not by de�ined process control with error bounds, as in Six Sigma.7 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch11#ch01fn7)

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 2/6

Iterative and evolutionary: The Ag-PDLC is a string of development cycles called iterations or sprints. With each iteration, some part of the requirement backlog is put into production and then the backlog is revisited in subsequent iterations until exhausted. The design evolves from iteration to iteration driven by product experience and feedback from customers—the design is iteratively adapted and improved as the backlogs are worked off. Within the framework of the top-level architecture, the customer is allowed to reset priorities, add, delete, and change the backlog according to market and business need.

Incremental: The outcomes of iterations are packaged for release to production as an update to the product base.

To maintain alignment of deliveries with the value proposition in the business case, iterations are relatively short, from about two to three weeks in XP, 30 days in Scrum, to something longer according to circumstances in Crystal and Kanban. Releases are made as frequently as the business can absorb change, but typically no less frequently than a calendar quarter. There are no hard and fast rules; each project sets the agenda with the customer.

An Agile Manager’s Agenda Every PDLC has within it planning, managing, measuring, and accounting for results. In the Ag-PDLC, the project manager’s agenda has a few featured elements. All of these elements are geared toward strategic �idelity to the business plan; all of these elements are complimentary to allowing tactical �lexibility for handling changing and emergent requirements, demand, priorities, and urgent situations.

What Agile Managers Do

Customers: Coach customers’ and end-users’ project participation that is near real time and nearly continuous. Many customers require help to be effective in this role and many organizations will have to make cultural adjustments for such customer intimacy.

Communications: Encourage communications that are open, honest, and real time within and among teams. Manage the trade off between documentation and face-to-face discussion and interaction as a means to accurately communicate in a timely fashion.

Results: Maintain a focus on results, not speci�ically on process and activity. In this respect, value is earned only when a product that serves the customer’s need is put in production.

People: Internalize the idea things are managed; people are led, a principle embraced by Rear Admiral Grace Hopper (1906-1992), a renowned computer scientist. Motivating and inspiring individuals are central to the success of high-performance teams that depend on individuals collaborating effectively, setting aside competitive secrecy, and attacking only problems.

Innovation and technical excellence: Champion innovation and technical excellence as enablers for successful projects, discriminating products, and satis�ied customers.8 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch11#ch01fn8) Be the champion for coherent architecture, unassailable quality, and system cohesion as marks of best practices.

Guiding Principles for Agile Managers:

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 3/6

Agile managers are guided by these principles:

Plans are adaptive: Agile projects are not driven from a single plan. There will be a broad-stroke plan in the business case, and there will be other detailed plans that are incremental, iterative, and just-in-time.

Value is the prerogative of customers: The value of requirements is ultimately a judgment by the business and the customer, envisioned in the business case and re�ined at each iteration.

Schedule and cost are derived: The business case frames the investment and major milestones, but actual costs and schedule are derived from the performance of teams deployed during the course of the project.

Change is embraced and encouraged: Change is not resisted. As a matter of policy and governance, agile practices encourage the end user to maintain the value proposition relevant to the state of the business and current to the market.

Documentation comes after personal interaction: Discourse and debate among individuals is recognized as a valid substitute for many formal documents. Documentation is still important, and acquires more importance with escalating project scale; documentation is just not as important as it is in the PD-PDLC.

Individuals are trusted: The concept of the high-performance team depends on trusting individuals to do the right thing the right way. In this context, doing the right thing means serving the interests of the customer, the project, and themselves while being committed and accountable for the results.

A project management

tip

Agile commitments

Agile project managers commit to best-value for sponsors, customers, and users.

Total cost and resource consumption are dependent on value delivered, but are limited by investment funds and milestones given in the business plan.

The focus is on product quality in terms of form, �it, feature, and function as directed by customers and end-users.

Stakeholders and managers may have to give up the comfort of outcomes planned and forecast by central planning, but they do not have to give up an expectation for project outcomes consistent with vision, architecture, and the prospect of bene�its.

Addressing the Major Risks Agile methods address the major risks of the traditional methodology that are blamed for poor product quality and poor project performance.

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 4/6

Major Risks as Addressed by Agile

BDUF: Agile makes no attempt to do a big design up front that cannot sustain its relevance for the life of the project, nor is it assumed that complex systems can be fully imagineered by structured analysis at the beginning of the project lifecycle.

Unknown or unknowable requirements: Customers are allowed to add, delete, revise, and reprioritize requirements at the beginning of each iteration, but not during an iteration. This approach creates a piece-wise freeze to stabilize requirements for development.

Customers at arm’s length: Customers are included on the development teams and coached for effective participation.

Testing and delivery is all at the end of the project cycle: In XP, test scripts are written as the �irst step in the development process. Test scripts are the means to document design requirements. Working product is delivered at multiple points in the project lifecycle. Only working product earns value, and only working product is integrated into the product base.

Documentation is not cost effective: Documentation is minimized insofar as instructions to guide development; documentation is replaced by daily collaboration and informal means to communicate: e- mail, instant messages, comments embedded in the product design, story cards, scorecards, and dashboards.

Module 3—Discussion for Critical Thinking Unlike the PD-PDLC with its guiding plans and speci�ications, the agile paradigm gives managers considerable latitude to �ind the best path toward satisfaction of the strategic intent. Can you imagine, however, that some managers are very uncomfortable without the tether to up-front plans and speci�ications? What do you say to those with that issue?

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 5/6

1.4 Module 4: Scaling for Enterprise Agile Hybrids and more; team network over linear team threads; complex over complicated

Module 4—Objectives Establish and explain that agile is scalable and not con�ined to small projects

Discuss and explain the hybrid model as a business reality

Discuss and explain team networks as a tool for scale

Scale: The De�inition Scale means enterprise breadth—functionally touching and impacting widely across the enterprise. Such may not necessarily require a huge code base; conversely, a large code base may not require much in the way of scale, if the enterprise touch is narrowly drawn. A small team working forever can produce a lot of code, but this is not necessarily large scale for our purposes.

Scale drives product architecture to a network of functional nodes from something less relational and more linearly interconnected. Scale introduces complexity, de�ined as: system performance and functionality not predictable from its constituent parts.

Agile-Traditional Hybrids The fact is, any project of non-trivial scale is composed of multiple threads, swim lanes, or work breakdown structure activities that are supported by—or are supportive to—software being developed. These activities are most likely plan-driven and handled with traditional methods. With these, agile methods must coexist. The name given to these projects is hybrid or agile-traditional hybrid.

Of course, at �irst examination, having a plan-driven thread or swim lane be dependent upon an emergent or tactically planned development effort seems problematic at best—and simply incompatible and counterproductive at worst.

In fact, it can work if the project is �irst thought of as strategically stationary. That is, the project de�ined in the business case is the project being executed. It really doesn’t matter when you look at it; strategically it’s the same project. This is the essence of stationary in time.

That said, the project can be tactically emergent—in effect, agile—so long as it is architected as a number of objects or containers with de�ined interfaces—the functionality of which are determined �irst and made sacrosanct. Thus, by honoring interfaces, it is possible to develop the internals of the containers with a choice of methodologies—agile or traditional—and join the efforts like a network with the individual functionalities on the network nodes.

We’ll develop this idea more fully in subsequent chapters. However, the principle of strategically stationary while allowing tactical agility is the key to successfully scaling to larger and more functionally complex projects, and to link such projects in a portfolio.

12/3/2019 Print

https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch11,ch15&content=content&clientToken=8980241e-b46c-84c4-ce09-83862eea8888… 6/6

Scale as a Driver Scale drives the product manager to become more than just one individual; scale may require a product committee or an organization. All manner of enterprise support is engaged. Remote, virtual, and contract practitioners may be drawn in. An existing product code base—if there is one—must be honored, thereby imposing constraints, introducing complexity, and perhaps diluting lean practices.

Scale drives the project team to be a greater-than-ordinary multi-disciplinary organization, involving functional, technical, managerial, and artistic constituents. And, scale drives multiple teams to form team networks to exchange information, maintain coordination, and pass partial product among them.

Module 4—Discussion for Critical Thinking We assert that scale is a larger issue than just building more code or maintaining a larger code base. This module identi�ied some of the issues and practices that are tools for scale. Can you think of others that are necessary for larger scale in the enterprise?