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 Table 1.2 Plan-driven methodology disadvantages
Disadvantages
• Inappropriate where requirements cannot be fixed, or where customer changes are fre-
quent (inside the development or plan-driven cycle)1
• Inappropriate for small teams, with fewer than 25 developers, since the cost of process often exceeds the cost of the business deliverables
• Inappropriate where uncertain application overwhelms process discipline, causing contin- uous re-baselining and re-analysis of earned value forecasts
• Delivery of business value is late in the lifecycle; inappropriate where near-term value is paramount
• Values the plan, although the plan requires constant maintenance to maintain relevancy over long periods.
• Encourages discipline but discourages process inventiveness
• Changes coming late are very expensive to insert, much more costly than the value of the upgrade in many instances
• Heavy, expensive, process and documentation, prone to errors discovered at the end • Requires high discipline and commitment to maintenance of artifacts of process to keep
them relevant and current over a long project lifecycle • Relies on and requires governance formality
• “Early stage” artifacts have to have a long life, else the end result is wrong
1Boehm, B. and Turner, R. Balancing Agility and Discipline, Addison-Wesley, Boston, 2004, pg 31: Boehm recommends that requirement changes after requirements baselining should be less than 1% for a suc- cessful PD-PDLC project.
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 tacti- cal 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 specified,
built iteratively, and delivered in frequent releases.
• Agile projects are governed by a top-level business
plan that envisions a product goal, top-level require- ments, 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 mar- ket 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 certified 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 ob- servation and reaction, not by defined process control with error bounds, as in Six Sigma.7
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 pro-
duction 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 ab- sorb 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 fea- tured elements. All of these elements are geared toward strategic fidelity to the business plan; all of these elements are complimentary to allowing tac- tical flexibility 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 commu- nicate in a timely fashion.
• Results: Maintain a focus on results, not specifically 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 excel-
lence as enablers for successful projects, discriminating products, and satisfied
customers.8 Be the champion for coherent architecture, unassailable quality,
Guiding Principles for Agile Managers: 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 refined 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 de-
bate 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 spon-
sors, 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, fit, 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 expecta- tion for project outcomes consistent with vision, archi- tecture, and the prospect of benefits.
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.
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 require- ments 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 first 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 in-
structions to guide development; documentation is replaced by daily collaboration and informal means to communicate: e-mail, instant messages, comments em- bedded in the product design, story cards, scorecards, and dashboards.
Module 3—Discussion for Critical Thinking
Unlike the PD-PDLC with its guiding plans and specifications, the agile paradigm gives managers considerable latitude to find 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 specifications? What do you say to those with that issue?