driving business results - pmi hampton roads · 2018-03-02 · 480%. 3 year revenue growth. 114%. 1...

With Agile

Driving Business Results

Business Innovation

Strategy

BuildingSupport

480%3 year revenue growth

114%1 year revenue growth

+20%Net income

200+Software and quality assurance engineers

$500,000Typical project value

3,000 hours

Typical project effort

35+ yearsSoftware development experience

Typical project duration

7 months

5Development centers

(US and Eastern Europe)

1995: Scrum is Born

Schwaber, K., 1995. SCRUM Development Process. Business Object Design and Implementation: OOPSLA ’95 Workshop Proceedings, pp. 117-134.

Jeff Sutherland and Ken Schwaber

1940s: Agile

1986: Agile for Tech

Evolution of Agile

Common Project Challenges

Beck, K. et al., 2001. Manifesto for Agile Software Development. [Online]. Available at: http://agilemanifesto.org/

Past

Dea

dlin

eMiscommunication

Irrelevant Feature

Scope Creep……

.…

Prioritization Issues

Outdated Product

Agile ManifestoWe value Over

Following a Plan

Contract Negotiation

Comprehensive Documentation

Processes and Tools

Responding to Change

Customer Collaboration

Working Software

Individuals and Interactions

Beck, K. et al., 2001. Manifesto for Agile Software Development. [Online]. Available at: http://agilemanifesto.org/

Top 3 Agile Benefits

Ability to Manage Changing Priorities

Increased Team Productivity

Improved Project Visibility

VersionOne, 2017. 11th Annual State of Agile Report. [Online]. Available at: https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2

TechnologyCertain

Requ

irem

ents

Simple

Complicated

Complex

ChaoticW

ell-d

efin

edU

ndef

ined

Uncertain

Noise Level

Agile

Agile is a good fit for complicated and complex projects• Emerging requirements• Uncertain technology and

methods

Schwaber, K. & Beedle, M., 2001. Agile Software Development With Scrum. Upper Saddle River, NJ: Prentice Hall PTR.

Waterfall is appropriate for simple projects• Well-defined requirements• Known technology and

methods

Waterfall

Agile Processes

Scrum Scrum & XP Custom Hybrid Scrumban Kanban Other Iterative Don't Know Lean

68% Scrum or Scrum/XP

Characteristics of Scrum

• Scrum is one of the agile processes, focused on delivering the highest business value in the shortest amount of time.

• The business sets the priorities and teams self-organize to decide the best way to deliver the highest-priority features.

• Progress is made in an iterative and incremental fashion via fixed-length production cycles, called “sprints”.

• At the end of each sprint, the product is usable and the business can decide to release it as-is or continue enhancing it.

Product Backlog

Sprint Backlog

Sprint

1 Week to1 Month

Daily Scrum

24Hrs

Product Increment

Scrum

The Sprint

• Fixed duration production cycle• 1 week to a calendar month at most• All work is done during the sprint

• Design• Build• Test• Accept

Sprint Duration

• No change allowed during a sprint• Select the longest you can go without changes• Sweet spot: 2 weeks

• Enough time to get momentum• Short enough to change direction

The 10 Scrum Things

Roles• Product Owner• ScrumMaster• Development Team

Ceremonies• Sprint Planning• Daily Scrum• Sprint Review• Retrospective

Artifacts • Product Backlog• Sprint Backlog• Product Increment

Product Owner

• Represents business stakeholders• Creates and maintains the product backlog• Prioritizes the product backlog based on business value• Conveys vision to development team• Accepts or rejects work results• Decides when to release the product

ScrumMaster

• Owns the process• Coaches team about Scrum fundamentals• Resolves impediments• Facilitates continuous improvement• Protects the team from outside influences

Development Team

• Typically 3 to 5 individuals• Self-organizing• Decides how to complete the work• Includes all necessary skills (“cross-functional”)

Ceremonies

Sprint Planning

1 Week to1 Month

Sprint

Daily Scrum

24Hrs

SprintReview

Scrum Ceremonies

TeamRetrospective

Sprint Planning

• Development team selects items from the product backlog• In priority order• Based on capacity this sprint

• Specify a sprint goal• “Micro-planning:” breaking down stories into tasks• Repeat until capacity is full

Daily Scrum

• Every day• Time-boxed to 15 minutes• Three things

• What did you get done?• What will you get done?• What’s in your way?

24Hrs

Sprint Review

• Attended by stakeholders• Held at end of sprint• A discussion and collaboration between stakeholders and Scrum team• 2 hour prep time rule• No slides• Discuss upcoming work and re-prioritize

Retrospective

• Typically 30 to 60 minutes• Drives continuous innovation and improvement• Various ways to run the retrospective• One example:

• What went well?• What could we have done better?• What changes should we try next sprint?

• Another example:• Start doing• Stop doing• Continue doing

Artifacts

Product Backlog

• “Requirements”• List of everything envisioned for the product• Prioritized by business value• Re-prioritized before the start of each sprint

Product Backlog

Sprint Backlog

• Product backlog items selected by the development team

• The plan to deliver the product increment and attain the sprint goal

Sprint Backlog

Product Increment

• Sum of the product backlog items driven to “done” during the latest sprint

• Plus all “done” product backlog items from prior sprints

• It must be “done” at the end of each sprint• In useable condition• At a shippable level of quality• Regardless of whether the product owner decides to

release it

• Meets the Scrum team’s definition of done

Walk-through

New (or rebooted!) Project

Strategy1-4 Weeks

• Determine business goals• Clarify user roles• Write backlog stories• Estimate backlog size• Prioritize backlog• Build team

Product Increments2 Week Cycle

• Sprint Planning• Daily Scrum• Backlog Management• Sprint Review• Retrospective

Backlog Grooming

Define Subject

Define Rolesand Features

Write User Stories Sprint Planning

Define Story Summary

Define Acceptance Criteria

Determine Dependencies

Enhance Acceptance Criteria

Add Technical Notes

Split Large Stories

Estimate Stories

Create Sub-Tasks for every action that will

be needed to drive the story to done.

Add hours to the sub-tasks to determine how

much can be fit into sprint.

Leve

l of d

etai

lEvolution of Story Detail

Strategy Phase Sprint Prep Sprint

Sprint Board

Sprint Progress

Release BurndownNumber of sprints remaining to complete this version, given an average velocity of n story points per sprint.

Version Report

Team's progress towards completion of a version. Shows the predicted Release Date, based on team's average rate of progress since the start of the version, and the estimated amount of work remaining.

The Predicted, Optimistic and Pessimistic completion dates are at the bottom of the Version Report.

Sprint Planning

Daily Standup

Sprint Review

Prepare Top Backlog Stories

Stakeholders

Product Owners

Chief Product Owner

Determine Business

Goals

Prioritize backlog

Teams

Backlog Grooming

As needed As needed

Continuous

Workflow and Communication

If interested, listen only



Business Drives Priorities

Team Delivers Consistently

Accurate Schedule

High Degree of Trust

Sustainability

http://bit.ly/davescrumtips

• Short tip every few weeks in your inbox• Not available anywhere else• Early access to new book

http://bit.ly/davescrumtips

Live Session for Your Teamhttp://www.ascendle.com/pmi-hampton-roads

http://www.ascendle.com/pmi-new-hampshire

Ascendle.com/blog

Allison Grappone

linkedin.com/in/[email protected]

Ascendle.com

Thank You!

http://www.ascendle.com/blog

http://www.ascendle.com/

http://www.ascendle.com/

Backup Slides for Q&A

Which Projects Should be Agile?“Routine Execution” “Novel or Strategic Project”

Requirements Defined and given from above General vision and direction, but detailed goals not known and partially emergent

Activities Can be articulated and derived from experience Partially emergent

Capabilities Existent or identified Don’t necessarily exist, not necessarily understood

Uncertainty Variation and risks that can be anticipated Unforeseeable uncertainty: new variables, new effects, new actions, which could not be anticipated at the outset

Characteristics • Known markets and customer reactions• Known performance drivers of the developed

system• Known environmental parameters

• New markets and unknown customer reactions• New performance drivers of the developed system• Unknown technology• Complexity with unforeseeable interactions among drivers

and variables• New geographies with unforeseeable regulatory challenges• New stakeholders with emergent demands

Lenfle, S. & Loch, C., 2010, Lost Roots: How Project Management Came to Emphasize Control Over Flexibility and Novelty [Online]. Available at http://www.sylvainlenfle.com/images/Publications/Lost_Roots_R2_VF.pdf

AgileWaterfall

PMO can make huge contributions• People• Projects• Process

Renaming the PMO

• A new name may better match the revised role

• Examples• Scrum Center of Excellence• Scrum Competence Center• Scrum Office• Development Support• Product Center of Excellence• Agile Center of Excellence• Agile Project Office

People

Develop Training Program

• PMO facilitates creation

• Select outside trainers

• Or deliver themselves

Provide Coaching

• Training is first step

• Needs follow-up with hands-on guidance

• PMO may not initially have skills, but can get trained

Select/Train Coaches

• Needs outstrip PMO as Scrum grows

• Develop internal coaches to help scale

• Coaches keep current job

• ~5 hours/week helping a team

Challenge Existing Behaviors

• Watch out for old habits creeping back in

• Remind teams of need for continuous improvement

Projects

Assist With Reporting

• Satisfy reporting requirements that can’t be abandoned

• Communicate status information about projects

• Example: Prepare weekly report

• Example: Facilitate weekly status meeting

Assist With Compliance

• ISO 9001, Sarbanes-Oxley, HIPAA, PCI, etc.

• Or organization-specific

• Help teams with awareness

• How to comply• Central source of

information

Manage Flow of New Projects

• Limit work flowing into teams

• Prevent overloading teams

• Help organization resist tendency to start projects too quickly

Help Establish and Collect Metrics

• Warning: Scrum teams are leery of “metrics programs”

• Determine how well teams are doing at delivering business value

• Measurements: team velocity, projected release timeframe, meeting projections

Process

Reduce Waste

• Avoid introducing extra “stuff” unless absolutely necessary• Documents• Meetings• Approvals

• Help teams aggressively eliminate what’s not adding value

Communities of Practice

• Group of like-minded or like-skilled individuals

• Examples:• Architects• Front-end developers• Product owners

• Supports• Sharing of ideas• Best practices

• PMO can help with formation and support

Consistency Across Teams

• PMO helps spread best practices among teams

• Caution: Avoid “mandates” dictated to teams

• Best result: All or most teams agree on practices

• Communicated via communities of practice and shared coaches

Provide/Maintain Tools

• Tool selection should be left up to individual teams

• But some universal tools make sense• Example: JIRA

• PMO can help teams acquire tools and help configure them

Process (Continued)

Coordinate Teams

• PMO has cross-team view and can identify problems early

• Can raise a red flag if work of multiple teams begins to diverge or overlap

Model the use of Scrum

• Many PMOs adopt Scrum for their own internal management

• Plan sprints, conduct daily standups, etc.

Work With Other Groups

• Help teams coordinate with other groups such as HR and facilities• Example: Explain why

teams should be co-located

• Adjust performance reviews to eliminate questions that discourage teamwork

History

1940’s

• Toyota hires American W. Edwards Deming

• He helps beginning development of the Toyota Production System (TPS)

• The start of “lean” thinking...

• …And the roots of agile

Araya, H., 2016. When was Agile “born”? [Online]. Available at https://www.linkedin.com/pulse/when-agile-born-heidi-araya-mba-cal-csp-pmp/

1940’s

Lockheed Skunk Works

• Designs and builds the XP-80, the first U.S. jet fighter, in 143 days

• Dedicated, cross-functional team

• Trial and error

• Parallel activities

• Frequent inspection


1940’s

The Manhattan Project


• Trial and error

• Parallel trials


1950’s


X-15


• Iterative development

1950’s

Araya, H., 2016. When was Agile “born”? [Online]. Available at https://www.linkedin.com/pulse/when-agile-born-heidi-araya-mba-cal-csp-pmp/Lenfle, S. & Loch, C., 2010, Lost Roots: How Project Management Came to Emphasize Control Over Flexibility and Novelty [Online]. Available at http://www.sylvainlenfle.com/images/Publications/Lost_Roots_R2_VF.pdf

Project Mercury


• Incremental software development

• Half-day iterations

• Test-driven development

1950’s


Atlas/Titan

• Separate, dedicated organization

• Cross-functional team

• Major overlap between research, development, construction

• Parallel work on both Atlas and its backup, Titan

1960’s

https://commons.wikimedia.org/wiki/File:0811_PMI_logo.gifLenfle, S. & Loch, C., 2010, Lost Roots: How Project Management Came to Emphasize Control Over Flexibility and Novelty [Online]. Available at http://www.sylvainlenfle.com/images/Publications/Lost_Roots_R2_VF.pdf

Late 1970’s – Early 1980’s

Some bucked the waterfall trend…

• Canon• Fuji-Xerox• Honda• IBM

• Dedicated, cross-functional team of 12 engineers• Converted warehouse in Boca Raton, FL• Developed the IBM PC in 13 months

https://en.wikipedia.org/wiki/Canon_AE-1#/media/File:Canon_AE-1_with_50mm_f1.8_S.C._II.jpg • https://en.wikipedia.org/wiki/IBM_Personal_Computer#/media/File:Ibm_pc_5150.jpgTakeuchi, H. & Nonaka, I., 1986. The New New Product Development Game. Harvard Business Review, January-February, pp. 137-146.

1986: What’s Old is New Again

“The traditional sequential or ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility.

Instead, a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”

Hirotaka Takeuchi and Ikujiro NonakaThe New New Product Development GameHarvard Business Review, January-February 1986