The Agility Continuum Where is your project (or product or team) on - - PowerPoint PPT Presentation

The Agility Continuum

Where is your project (or product or team)

• n the agility scale?

Thene Sheehy October, 2017 PMP, ACP, CSP, ScrumStudy SMC & Trainer

Who am I?

Thene Sheehy Program Manager/Specialist, Center for Enablement PetSmart, since Nov, 2016

15 years in Telecom IT 8 years in Healthcare IT …. And various others Data Analyst/Architect Data Management Director, App Dev & Project Management Project/Program Manager Scrum Master … Lifelong Learner

“We might be the Mobile Dev team, and yes… we are delivering new features every two weeks, but we aren’t agile enough.” “My team plans and delivers upgrades to our vendor package software that the store/merchandise planning team uses. Since we don’t do real Dev work, we can’t be agile.” “Our vendor gives us a MS Project plan for upgrades, and we just plan and deploy it. No need for agile on this. We prefer waterfall.” “We use offshore developers, and offshore testers, so we can’t be agile.” “We can’t deliver to production every 2 weeks, so we shouldn’t use agile.”

Who has heard these Sound Bites ?

4

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Consider the Agile Founding Fathers

No ‘black and white’ agile here!

Agilemanifesto.org

5

The Agility Continuum

An approach to increase agility a little bit at a time

Waterfall/ Planned Agile/ Flexible

6

The Agility Continuum

A Million Points on the Continuum Where is your team now? Where do you want to be? Given the culture & constraints, can you be a little more agile?

7

The ‘Simple’ Prototype

Waterfall Agile 10 Dimensions to Assess

8 Traditional Strong Controls Sequential Phases Known & Optimized Tasks Low Tolerance for Change Delivery at End

The Agility Continuum 1-Dimension

A Million Points on the Continuum Where is your team now? Where do you want to be?

Iterative Lighter Controls Iterate Phases* Some Tolerance for Change Delivery in Phases Highly Iterative Lightest Controls Iterate Constantly High Tolerance for Change Adaptive & Empirical Ongoing Releases

If waterfall is your most appropriate style, can you still gain benefits from some agile techniques?

9

Project/Team Dimensions

Governance & Change Management Scope Management Schedule Management Team Management Cost Management Quality Management Communications Management Risk Management Vendor Management Stakeholder Management

The Agility Continuum – 2nd Dimension

Look familiar to the PMP’s in the room? These are 10 Knowledge Areas in the PMP Process Chart.

10

• Consider one of your projects.
• As we discuss each facet of the project, score your project as:
• Waterfall level 1, 2, 3 (3 is the extreme)
• Agile 1, 2, 3 (3 is the extreme)
• Add the Waterfall and Agile points at the bottom of each column (W3 and A3 are 3 points)
• Highlight the facet(s)/ dimensions where you want the benefit of Agile Thinking and

Agile Methods, but have constraints or culture holding you back.

The Agility Continuum - Assessment

Scoring

11

Ready?

12

13

Project Governance & Change Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Centralized command/control structure
• Project Charter, PBC, FBC – require

detailed scope, schedule, and cost up front, and little tolerance for change

• PLT includes multiple stakeholders who

govern as a committee

• ePMO has oversight and monitors

progress

• CR’s for all Changes
• PLT governs and approves all changes
• Strong Project Management role
• Cost estimates determined centrally, by

PM

• Product Owner (PO) take lead for prioritization,

scope

• PO funnels and channels other stakeholder

input

• Product Roadmap is defined but flexible
• PO defines the MVP and releasable Versions
• ROI of each enhancement is justified

independently and used in ongoing re- prioritization

• Scrum Master coaches on process, facilitates

team, removes impediments

• PO is actively involved on a daily basis to clarify

questions, check progress, validate results, and answer business questions

• Backlog can be groomed constantly, and re-

prioritized every sprint (usually 2 weeks)

• Distributed and shared governance – product
• wner, scrum master, and team

W3 W2 W1 0 A1 A2 A3

14

Scope Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Pure waterfall – requirements

documented in advance and approved.

• Phases follow in sequence…. Design,

Dev, Testing, Deployment (no iterations)

• Requirements fully documented, in detail,

and signed off by PLT team (or proxies)

• All architecture and design is completed

up front, before any Dev work begins. No room for error.

• Epics & User Stories can be planned up front in

Product Roadmap, and loosely planned in Release Plan (over multiple Iterations/Sprints).

• Adaptive planning approach – scope is loose and

can be adjusted by Product Owner every iteration.

• Kanban approach has no planning; just pick and

pull, whereas scrum includes sprint planning

• Single Product Backlog ensures prioritization is clear
• Product Owner manages Scope and Prioritization
• Product Owner defines User Stories with Acceptance

Criteria

• Requirements evolve as business needs change
• Requirements (in User Stories) are small units of work

that can deliver value quickly

• Lightweight documentation encourages a focus on

conversation with scrum/project team members (and minimizes overhead time)

• Tasks to deliver each story are handled within the

work for the User Story so that done is ‘done’ (including testing, as much as is possible)

• User Story work should include the creation of Test

Cases, Test Data, and Automated Tests, where possible

W3 W2 W1 0 A1 A2 A3

15

Schedule Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Project tasks are knowable and

estimable

• Project tasks have known dependencies
• Schedule is trustable and fixed
• Low tolerance for schedule changes due

to dependencies

• Project schedule is optimized to be

repeatable

• Project schedule often includes ‘wait

times’ for approvals and resource availability issues

• Project delays in the early phases crunch

remaining work toward the same immovable end date

• Delivery speed and dates provided by

business owner and PM

• Short (bi-weekly) cycles for PDCA (plan, dev, check, adjust),

but do not dictate production releases

• Ongoing releases (anywhere from daily to monthly)
• Release to production in smallest possible units to get

maximum value into the hands of the business

• Stable teams enable stabilizing velocity, enabling accurate

work estimates

• Minimized story dependencies enables independent delivery

into production and simplified planning

• Schedule/work estimates are completed by

scrum/project/work team to increase accuracy, and ensure clarity/understanding

• Product Owner protects the project/scrum team from

interruptions and distractions during the sprint cycle to ensure they meet commitments

• Scrum Master and Product Owner clear daily impediments to

increase team ‘flow’ and help ensure they meet sprint commitments.

• Project/Scrum team commitments align to sprint end dates;

precision for mid-sprint deliveries not required to reduce

• verhead; short time-boxes increase accountability
• Delivery speed and dates provided by team

W3 W2 W1 0 A1 A2 A3

16

Team Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Team members often on multiple

projects

• PM’s often manage multiple projects
• Team members report directly to their

‘resource’ manager, and dotted line to the PM; priority conflicts arise often

• Project delays for team members

working the early phases often compress time schedules for the team members working the latter phases (usually QA and Ops)

• Project Manager ‘cracks the whip’ to

hold on to scope, schedule, cost, and quality expectations

• Team members are fully allocated to short ‘burst’ projects

to minimize wait times, increase focus, and reduce ‘context switching’

• Consistent teams over time increases accuracy of

estimates, and enables the team to move into the ‘performing’ phase (Tuckman model)

• Higher team autonomy and responsibility increase

engagement and quality – team commits based on their understanding of work items and recent velocity

• Scrum master acts a facilitator, negotiator, servant leader

W3 W2 W1 0 A1 A2 A3

17

Cost/Budget Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Full scope and schedule defined up

front so that cost and ROI can be calculated

• Changes to cost are avoided and

require significant levels of approvals

• Focus on meeting original cost

estimates despite changing business needs during the project

• Smaller deliverable work units allow for less work to create

estimates along with higher accuracy

• Stable teams enable higher accuracy in cost and

schedule estimates

• Cost estimates are sub-servient to flexible scope to serve

changing business needs

• Work units delivered to production sooner and more

frequently increase the overall asset value (because pieces are in production/usage sooner) – ROI goes up naturally

• Cost, value, and ROI are defined per User Story to

increase flexibility in delivery schedule

• Large project estimates are allowed a greater margin of

error; re-forecasting is limited to (maybe) quarterly (infrequently, to avoid overhead work

• Lean Thinking looks for ways to eliminate waste from the

project and minimize overhead

• Total project cost can be estimated based on release

plan, list of user stories, story points, and historical team velocity

W3 W2 W1 0 A1 A2 A3

18

Quality Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Product is tested after fully developed
• Bugs are found by QA during late-stage

testing, long after the developer did the initial work; Developer has to find and re- focus attention late in the project

• Dev team has often moved on to the

next round of work when QA team begins and bugs are found

• Sprint Review/Demo for Product Owner and Stakeholders

every 2 weeks holds team accountable for quality delivery throughout

• Sprint Review/Demo every 2 weeks holds Product Owner

accountable to their product; issues are found early when they are less costly to modify (minimize rework)

• Sprint Review/Demo every 2 weeks keeps PO from

business engaged in the project and gets them ‘hooked’

• n seeing the product come to life
• Integrating testing during development prevents bugs

and enables fixing bugs quickly (reducing cost) to increase quality

• Pair programming shares the testing and quality burden,

and increases quality of code, and can increase engagement

• Sprint Retrospectives every 2 weeks allows the team to

reflect and improve process throughout the project lifecycle

• Including the development of test cases, test data, and

automated tests within the sprint helps grow the test bed, and speed testing

W3 W2 W1 0 A1 A2 A3

19

Communications Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Weekly/Bi-weekly status report is written

(spun) by the Project Manager for the management team

• Communication by the PM with PLT and

the project team is less frequent and more formal

• Use of MS Project often reduces the

visibility of status (tough to use tool)

• Product Owner is actively engaged in the project and

needs less formal status reporting

• Work tools (JIRA/Confluence) make the project

information public at all times, and easily shareable

• Project wiki (confluence space) enable all team

members to see and edit project information; tool can present information and capture approvals, when needed

• JIRA reports can display on project wiki (confluence

space) with live up-to-date status information.

• Scrum Ceremonies keep team members (including

Product Owner) engaged and communicating verbally – Sprint Planning, Daily Standups, Sprint Review/Demo, Sprint Retrospective

• Daily Standup helps clear issues quickly and keep the

team on track to meet their sprint bi-weekly commitment

W3 W2 W1 0 A1 A2 A3

20

Risk Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Formal Risk & Issue Logs
• Formal mitigation planning for risks
• Risks and Issues often defined by PM and

PLT, and less by project team

• Risks and Issues are often just the major

items, and less often include the daily team issues

• Risk and Issue Logs often reviewed and

updated infrequently (along with status)

• Less formal Risk/Issue logs, if at all
• Risk Mitigation Tasks in Backlog
• Risk-adjusted Backlog
• Daily Impediments may be tracked in

JIRA/Confluence, but are often solved without the overhead of tracking

• Product questions are asked/answered

daily by the Product Owner; no time delays

W3 W2 W1 0 A1 A2 A3

21

Vendor Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Vendor contracts define the full scope of

work and expected result (needing more detailed requirements)

• Vendor contracts often have a high

Change Fee with change approval process

• Vendors often do their work separately

from the client with infrequent status reporting and less frequent review/demos

• Vendor contracts are written to purchase

skills and knowledge within a collaborative, iterative approach

• Changes have no added cost because

no detailed scope of work was defined up front

• Vendor contract defines iterative cycle

expectations, and process expectations for bi-weekly re-planning, daily standups, and bi-weekly product reviews; vendor monitoring and accountability is built into the process

W3 W2 W1 0 A1 A2 A3

22

Stakeholder Management

The Agility Continuum

Characteristics at the endpoints of the spectrum

• Stakeholders are identified upfront, and

PM meets with them to gather their needs, expectations, communication style, risks and issues.

• Formal stakeholder management is the

PM’s responsibility

• PM produces formal status reports for

Stakeholders, often different styles for each one

• Stakeholders often function as a

requirements approval committee (and change approval); conflicting priorities

• ften arise
• Product Owner is chosen to act as ‘front

man’ for stakeholders, and is granted authority to make decisions, prioritize enhancements (user stories), define acceptance criteria, and review/approve work product

• PO interacts with the Stakeholders, leaving

the project/scrum team to focus on developing/delivering the work product

• Unlike Stakeholders, the PO is intimately

involved in the project on a daily basis to clear up questions and impediments immediately

• Stakeholders and PO have full transparent

access to project info whenever they need it, via the work tools (JIRA/Confluence)

W3 W2 W1 0 A1 A2 A3

23

The Agility Continuum

How did your project/team score? Can you make any incremental improvements? Which culture/process constraints are holding you back?

24

Top 10 Agile Accelerators

….. Useful EVEN in a Waterfall World

Governance & Change Management Scope Management Schedule Management Team Management Cost Management Quality Management Communications Management Risk Management Vendor Management Stakeholder Management Fully-involved Product Owner/Manager 3-month Roadmap & 2-week Planning Daily Standups, 2-week Reviews, 3 mo Road-mapping Fully-allocated & Focused Teams Estimates per Item w/Frequent Delivery to Production Embedded & Continuous Testing 2-week Reviews & Team Status Wiki (Transparent Information Radiators) Risk-adjusted Backlog & Fully-involved Product Owner/Manager Collaboration without Handoffs Product Owner as Visionary, Prioritizer, Negotiator, Engagement, Newsperson

25

Agile is a way of thinking, not a methodology. Even waterfall projects can inject a bit of agile thinking & techniques. Many of the agile techniques are not unique to agile, and useful. All project teams can use agile techniques to improve outcomes. Like yoga, Agile is a ‘Practice’ which allows for ongoing improvement Agile isn’t JUST about the delivery cycle! Where is your team now? How far could you take them?

The Agility Continuum

Discussion Time

26