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
Roles
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
If interested, listen only
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
Live Session for Your Teamhttp://www.ascendle.com/pmi-hampton-roads
Q&A
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
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
The Manhattan Project
• Dedicated, cross-functional team
• Trial and error
• Parallel trials
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
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/
X-15
• Dedicated, cross-functional team
• 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
• Dedicated, cross-functional team
• Incremental software development
• Half-day iterations
• Test-driven development
1950’s
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
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
Top Related