Week 1: Why Agile?

1.0 Introduction to Week 1

1.1 Agile Basics

Agile Manifesto was codified in 2001 in Snowbird by Scrum, XP, and DSDM practitioners. Agile Manifesto includes:

- Individuals and Interactions OVER processes and tools

- Working software (systems) OVER comprehensive documentation
- Customer collaboration OVER contract negotiation
- Responding to change OVER following a plan

These values are at the core of why agile works and continues to be used on projects with high uncertainty today.

Sprint basics include the three parts of a Sprint:

- Sprint Planning
- Sprint Development
- Sprint Retro & Review

A Sprint is a timebox, or a period that is used to contain the time allowed for work to be completed. It can be anywhere from two
weeks to a month (although shorter is becoming more popular among advanced practitioners).

Sprint Planning starts with the Product Owner selecting the work to be done from the Product's Backlog. The Product Backlog is the
list of work that is prioritized by its importance, either for ongoing improvement or the completion of a new product. The Team
reviews the stories and then selects what work they will be able to complete during the sprint. This process is facilitated by the Scrum
Master who does not participate in the doing of work, but instead is focuses on enabling the team to move quickly with good
processes and best practices. The final set of stories should form a cohesive "product increment" that the team can demonstrate by
the end of the sprint.

- Input: Product Backlog of stories prioritized by the Product Owner

- Process: Review and select stories for the sprint
- Output: Sprint Backlog of stories the team commits to complete by the end of the Sprint

Sprint Development begins with the daily standup. Daily standups are self-reporting of the team on what work they will get done that
day. This is usually done around a Kanban board, or other big visual information radiator (BVIR). The team opens only a few stories at
a time and work story-by-story to analyze, build, and test the work. The result by the end of the Sprint is a shippable increment that
can be demonstrated to the product owner. Meetings are facilitated by the Scrum Master, and the Product Owner determines if a
Story is complete to meet the stakeholder needs.

- Input: Sprint Backlog of stories the team commits to complete by the end of the Sprint
- Process: Daily reporting and execution against a few stories at a time: designing, building, testing and closing
- Output: A shippable product increment that can be demonstrated

Sprint Retro and Review are ceremonies to gain feedback and drive continuous improvement into the team. The first step is the
Sprint Review, where the Product Owner demonstrates the product increment from the Sprint to Stakeholders. This is an opportunity
to gain stakeholder buy-in and feedback, so the team knows its on track with the product direction. The Product Owner can also get
feedback on what should be in the next Sprint. The Sprint Retrospective or "Retro" is the second ceremony used to close a sprint. The
Retro involves the team going into a room to evaluate how the sprint went, and identify opportunities for improvement in the next
sprint. The best Sprint Retros are run as games to facilitate input from the whole team and quickly identify improvements.

- Input: Shippable product increment that can be demonstrated

- Process: Demonstrations and games to facilitate feedback on the product and team processes
- Output: Feedback on the product's direction and actions to improve the next sprint
Iron Triangle helps to explain how the different project management methods align. The Iron Triangle includes:

- Scope - the technical work to be done

- Schedule - the total calendar time to execute the work
- Budget - the total cost of the project in dollars

All aspects of the Iron Triangle are constraints and costs to the organization. More schedule means a delay of project benefits and tie-
up of capital. More budget means more dollars or capital invested. More scope means a larger product to support or maintain for the
organization. These are all forms of cost and constrain how the work can be accomplished when they are fixed.

The three types of project management are Agile, Traditional, and Lean.

- Agile - varies scope against fixed budget and schedule

- Traditional - varies budget against fixed scope and schedule
- Lean - varies schedule (or solution time) against fixed scope and budget

The goals and requirements of each method are essential for understanding the place of each method in the project manager's
arsenal:

- Agile - goal is speed (deliver early versions fast), and requires trust to minimize scope for fast value delivery
- Traditional - goal is efficiency (best price), and requires efficiency to deliver lowest cost on time and budget
- Lean - goal is to innovate (solve problems), and requires expertise to minimize time of delivery

False comparisons across types of projects abound. Many times the objections one hears about using Agile is that it's missing critical
elements, such as design, testing, or documentation. These are all wrong. In fact, every project must have the following to be
successful:

- Charter
- Plan
- Documentation
- Design
- Testing

Remember that we vary scope to target just what the customer needs, so we don't waste time or money in the process. That's the
power of varying scope. It's fast and limits waste by reducing the work to a minimum viable product (MVP) that meets the project
objectives (in the charter). To do this, every Agile project needs:

- Shared Vision Robust to Change (can vary scope and stay on target)
- Whole Teams (customer + cross-functional team)
- Incremental Delivery (learn by doing and using small "sprints")
- Continuous Integration & Testing (teams test increments to ensure they work)

Scrum, SAFe, or Disciplined Agile are all frameworks that help define roles and processes to scale and implement the methodology of
Agile. They provide a shared language. But the method remains the same.

1.2 Proof Agile Works

There are many stories that capture why and how Agile works. One of the most compelling is the P-80 Shooting Star, the first jet
fighter, developed by Lockheed Martin's Skunkworks team:

- P-80 Shooting Star was the first Jet Fighter

- Developed in 1943 for use in WWII
- Led by Kelly Johnson using a colocated team in a tent
- Completed in 143 days

This is unheard of speed in innovation and delivery. Today similar innovation would take many years, if not a decade. Kelly Johnson
did this using principles that align closely with Agile:

- Small, Strong, Self-Directed and Cross-Functional Teams

 - Owners and Vendors had to collaborate and trust each other
- Managed and responded to change; any team could update the designs
- Minimize reports, but record what was important
- Incremental development by teams that could test their own work

This matches the core tenants of Agile closely:

- Shared Vision, but no fixed scope (they never built it before!)

- Whole teams (customer, builders, testers)
- Incremental delivery (as stated, they had to identify and solve problems one at a time)
- Continuous integration and testing (teams test increments early and often)

Example 2: Navy Energy Return on Investment

- Goal: select projects to reduce energy costs and use of "brown power"
- Process: evaluate and select the best projects delivering the highest "bang for the buck"
- Project: build a decision support tool quickly to enable support for selection

The scope of this project was to build decisions support systems for projects to identify and select $500M in energy investments. This
project was executed iteratively over four years for about five million dollars. The team makeup included:

- 2 cross-functional teams
- 8 contract personnel from Booz Allen Hamilton (BAH)
- 5 customer personnel from the Navy

Outcomes included a fifty dollars per dollar return on investment (ROI: 50). That means the Navy gained $50M per year because of
this project and its decisions support systems it developed. This was achieved through iteratively identifying and building the scope
needed in multiple releases:

- $20M were gained per year in savings, by building a quality management tool for projects
- $30M were gained per year in benefits, by building systems to better select projects
- Sustainability was improved by modeling where the next best projects would be with 95% accuracy
- This enabled BAH to win $10M per year in new contracts at the Navy for renewable energy management

Large Scale Agile Examples:

Condor Cluster - result of large amounts of reuse and modular architectures (Agile Engineering Example)

- One of the most powerful super computers

- Strung 2 million miles of cable to connect PlayStation 3 gaming consoles (PS3s)
- Modular enough to be loaded into a spy plane to process images in-flight
- Reduced aerial imagery processing from days to seconds

NASA's Faster Better Cheaper Initiative - reduced scope and size of spacecraft (Lean/Agile Release Designs)

- Major initiative in the 1990s

- Costs were one-tenth the current cost of producing spacecraft
- Achieved unheard of results by reusing old spacecraft designs
- Stardust Mission - slung shot around the earth and sun to catchup and capture dust from a comet
- Shoemaker - asteroid surveillance mission that landed on the asteroid to retrieve high-density readings
- Missions were achieved under budget and on schedule, returning 10X the value of traditional NASA projects

1.3 Evolution of Agile

TQM: The story of Agile as we know it today begins with Total Quality Management or "TQM”, developed by Edward Deming. This
was also the origin of the Lean movement that pushed for continuous improvement and appreciation of workers. The core tenants of
TQM include:

- Improving Quality Decreases Costs - lowers costly defects, customer support, and recalls
 - Continuous Improvement - for the systems and people in the systems
- Pride of Workmanship - the primary driver of knowledge workers and source of quality is joy in good work
- Plan-Do-Check-Act (PDCA) - this cycle allows for testing a complex system that can't be modeled easily

One of the famous beliefs was that the Knowledge Worker is different from the Manual Laborer, because the Knowledge Worker
knows more about the work than their boss does.

Proof that TQM Works: Edward Deming turned around Ford Motor Company in 1986 from billions of dollars in losses to its first
profits in years using the TQM approach.

TPS: The Toyota Production System (TPS) was developed by Taichii Ohno that was the first true Lean system. Focus was on reducing
waste, based on lessons from TQM. The focus was on reducing the wastes in a system:

- Eliminate 7 Wastes - Movement, Inventory, Motion, Waiting, Overproduction, Over-Processing, Defects

- Small Batches - exposes errors and minimizes waste in the system, by using a "Pull System" using Kanban
o Kanban - means "billboard" and it is a system to tell upstream processes to send work downstream
o Kanban boards have at least three columns: To-Do, Doing, Done
o Kanban boards limit work-in-progress (WIP) by limiting the number of items in the "Doing" column and only
pulling in more work once the current work in progress is done
- Continuous Improvement with Key Performance Indicators (KPIs)

Proof that TPS Works: Toyota is a top three (3) manufacturer of cars, with a 70% employee satisfaction rating - that's more than
double the satisfaction rating of employees in the USA, which stands at 30%.

TOC: The Theory of Constraints (TOC) was developed by Eli Goldratt. It emphasizes that the system is always governed by a
bottleneck and there is a competition between local optimization and system (global) optimization. The theory states that
Throughput of the system should be the focus of managers, not "Cost Centers" that drive local optimization. His ideas are captured in
the famous book The Goal which is read widely and cited as critical to the revolution of management in the 1980s.

- Throughput drives cost and revenue

- Throughput is constrained by one process in any system, the constraint
- To improve the System Throughput, one must focus on optimizing around the Constraint
- To do this, use the 5 Focusing Steps for the Process of Ongoing Improvement (POOGI)
1. Identify the Constraint - figure out which process is limiting
2. Exploit the Constraint - try to optimize with existing capacity
3. Subordinate everything to the Constraint - reduce processes to match capacity of the constraint
4. Elevate the Constraint - add capacity to the constraint process
5. Prevent inertia from becoming the Constraint - be vigilant and check if there's a new constraint!

Proof that TOC Works: TOC was used by the BP Oil Spill Cleanup initiative to save over $200M and rapidly deploy 10,000 boats after
the Gulf Oil Spill to skim and clean oil from the surface.

The Waterfall Mistake

- Waterfall was never intended to be linear in its design

- Royce, who proposed waterfall as a simple starting point for modeling work, stated all projects should iterate
- Typical waterfall design:
o Requirements - product requirements as output
o Design - architecture as output
o Implementation - system is produced
o Verification - testing is conducted to fix the system where needed
o Maintenance - support for product in use
- The actual design had at least one iteration going back from verification to implementation to design

Only 10% of software projects were successful in the 1970s and using waterfall we still see that half of those projects fail today.

By 1980s the Waterfall Method was being used by DoD (and continued until 1996), which resulted in the Ninety-Ninety Rule:
"The first 90 percent of coding accounts for the first 90 percent of development time,

The last 10 percent of coding accounts for the other 90 percent of development time" - Tom Cargill, Bell Labs

Important reference: Waterfall Model Probably the Most Costly Mistake in the World.

Iterative Methods: Spiraling to SCRUM

- Rapid Application Development (RAD) - popular during 1970s and 1980s

o Upfront requirements
o Iterate on Design and Development
o System Cutover
- Dynamic System Design Methodology (DSDM) - popular in 1980s and 1990s
o Introduced iteration of requirements (foundation)
o Included going back to design and development as well
o Still had a "Feasibility Stage" upfront
- Extreme Programming (XP) - popular from 1990s to 2000s
o Iterative across all levels (Pair programming, unit testing, standups, testing, and planning)
o Required heavy iterations and redundancy in resources to manage risk
o Continues to be used today

Key Tenants of Iterative:

- Consolidated Up-Front Planning - RAD and DSDM did not refine, but XP does
- Iterate on Designs - design, build, test, refine
- Timeboxes - to ensure continuous, on-time delivery
- User Stories - to describe requirements (introduced as standards in XP)
- Test-Driven Development (TDD) - enables exploration of designs and refinement before release

2013 Cross-industry Study by Ambysoft shows the following:

- Agile is more successful than Traditional

- Agile is less challenged than Traditional
- Agile fails less than half as often as Traditional

1.4 Netflix Case Study

Netflix was not always a streaming company. It moved from mail-based delivery of movies to one of streaming videos online. In order
to achieve the foundational paradigm that would deliver seamless video streaming. These ideas are still aspirational for many
companies today, trying to catchup to this modern model of management:

- Culture of Innovation - ability to respond to opportunities as they presented themselves

- Data Analytics - this allows for comparing changes and determining if it works through real data (truth)
- Decentralized Decisions - the empowerment of employees to procure resources on-demand as needed
- Agile and Self-Service Deployment - the ability for developers to deploy but also be responsible for their code

This led to what was called a culture of "Freedom and Responsibility." By empowering employees and holding them responsible, and
through incredible innovations in cloud and deployment technologies, Netflix was able to achieve unheard of responsiveness to
customers. As a result, Netflix continues to be a market driver and the standard in movie streaming experiences.

What all of these ideas have at their core is an understanding of one core belief: Speed Wins!

When comparing the efficiency of managing the volume of material and delivery of content, or the velocity of delivering changes to
those systems at scale - Speed always wins because at scale you can't expect efficient, perfect solutions. Things will always break at
scale and you'll need to respond quickly to fix and correct those issues in your system. Therefore, all best efforts for perfect designs
up-front and efficiency models in delivery lose, and only speed (for responsiveness to customers and infrastructure issues) can drive
sustainability into the system.

You can learn the details of this concept here:

KEYNOTE: Velocity and Volume (or Speed Wins) by Adrian Cockcroft

https://www.youtube.com/watch?v=wyWI3gLpB8o

1.5 18F Case Study

Agile in Government: GSA's 18F Delivers!

The California Social Services group needed an application for case management of child welfare services. These services were used
by 200,000 social workers. The services provided support for children suffering from abuse and neglect. Over 500,000 cases were
managed annually by the CA Social Services group.

For almost ten years the organization had been stuck doing paper exercises on the design of an application, never getting out of the
requirements and design phase.

18F was brought in and used a number of Agile techniques to drive the process forward:

- Modular Contracting
- Agile Development
- User-Centered Design
- Open-source practices

The result was the release of a functioning system within one year of kickoff. Ten years of paper compared to one year to deploy a
working system - now that's Agile! The project is still in its early stages, but the results have been:

- Greater vendor competition

- Cost Savings
- Improved Contracting
- Improved Customer Experiences
Week 2: Who Uses Agile

2.0 Introduction to Week 2

2.1 Simple PM Methods

This lesson is all about understanding the high-level components for each Project Management Method:

- Traditional
- Agile
- Lean

Traditional Project

- Idea - Traditional projects start with an Idea by the owner or team

- Business cases - Business Cases are performed for each concept; often a qualitative and quantitative process
- Bidding & Proposal - Project scopes of work are written and competed amongst teams
o External vendors will submit bids and proposals to win work against a Request for Proposals
o Internal teams will submit budgets and proposals to win allocated funding from a PMO or Portfolio function
- Waterfall Development - each stage is executed sequentially, with limited iteration or "going backward" in stages
o Requirements - the process of defining high, medium, and low-level needs of the end users and stakeholders
o Design - the process of architecting the solution to meet those requirements within the project contraints
o Implementation - the building of the product to specification
o Verification - the testing and product to ensure it meets specifications and the requirements' intent
o Maintenance - the design of and support of deploying and maintaining the product in operations
o Operations - the use of the product to produce benefits to the organization
o Disposal - the retirement of the project according to regulations and sustainability practices

Often the Traditional Process is controlled further with Stage Gates, where stakeholders agree the project is ready to move from one
Waterfall Development Stage to the next. This can help give executives clear points of approving or disapproving the work; as well as
inform stakeholders of the high-level progress of development.

Standard Stage Gates:

- Idea Readiness Review (IRR): precedes Business Cases

- Concept Readiness Review (CRR):
- Planning Readiness Review (PRR):
- Requirements Readiness Review (RRR):
- Design Readiness Review (DRR):
- Implementation Readiness Review (IRR):
- Operational Readiness Review (ORR):
- Operations and Maintenance Review (OMR):
precedes Bid & Proposal Stages
precedes Requirements phase
precedes Design phase, exits Requirements phase
precedes Implementation phase, exits Design phase
precedes Verification phase, exits Implementation phase
precedes Maintenance (O&M) phase, exits Verification phase
Precedes Disposal phase, exits Operations (O&M)

Agile Project Management

- Idea - (see Traditional above, it's the same)

- Business Case - (see Traditional above, it's the same)
- Bid & Proposal - (see Traditional above, it's the same mostly, except the contract type may differ)
 - Early Agile Development (Pre-Release of first version)
o Sprints - use the Scrum Method to deliver increments of working product iteratively until release ready
 Sprint Planning - Product Owner and Team plan work for the sprint
 Sprint Development - Team designs, builds, and tests increments of work in a fixed time period
 Sprint Retro & Review - Customer reviews the work and team reviews the sprint for improvement
o Deploy First Version to Production - this first version is often called the minimum viable product (MVP)
- Continuous Delivery (Post-Release of first version)
o The same team(s) supports development and operations or "DevOps"
o These are still executed using the Sprint model, only the team must account for supporting Operations
o Development
 Create - try something new or build fixes
 Verify - ensure that it works
 Package - get it ready for release
o Operations
 Release - deploy the new features/enhancements/bug fixes
 Configure - ensure operations and test features on/off
 Monitor - monitor performance of functionality
 Plan - prioritize the next improvement or fix
- Disposal - (see Traditional above, it's the same)

Lean Project Management

- Issue - could be an idea, major problem, or series of problems the client or owner foresees for the business
- Work Concept - work is formed as either a series of small challenges or one big challenge
o Issue Backlog - for support contracts, there needs to be total or sample backlog of work to support
o Technical Challenge - for technical solutions, there is a challenge set with clear performance objectives
- Bid & Proposal - (see Traditional above, it's the same; although contract types will differ)
- Work Definition
o Dispose Issues - issues are classified in urgency and impact to define the priority and who should respond
o Define Work Breakdown - team evaluates and decomposes the Technical Challenge into a work breakdown
structure or "WBS."
- Continuous Delivery
o Value streams - support for solving lots of small problems goes through a series of predefined steps to ensure
quality and drive customer satisfaction the issue is addressed.
 This is often supported using a defined workflow
 The issues are routed based on priority and impact to different team members
 Only the client or customer or their representative can accept it as done
o Incremental Delivery - a team will incrementally work through the WBS to solve a major problem
 Often use a Kanban board to solve highest priority/most uncertain work
 Delivery is continuous and incremental to explore solution sets that COULD work
- Operations - solutions are deployed into operations where customers receive benefits
o Example issue solution - solving someone being locked out of their system
o Example Technical Challenge solution - deploying a new upgraded machine for manufacturing a car
- Disposal - (see Traditional above, it's the same)
2.2 Who Uses Agile?
Understanding who uses Agile also requires understanding the methods employed to control a project's constraints. This brings us
back to the Iron Triangle for the Triple Cost Constraint:

- Scope - controlling the work done

- Schedule - controlling the calendar time for doing the work
- Budget - controlling capital expenditures

Controlling Scope

- Traditional
o Work Breakdown Structure (WBS) - controls work by concretely defining its components
 Often has three levels: Product, Major Features, Feature Components
 Used to define what will and will not be in a project
o Change Control Board (CCB) - controls changes to the WBS by committee review
 Includes all major stakeholders
 Must be organized and often slows changes to a project
- Lean
o Tickets - identify work items and their priority for response (urgency and impact)
o Requests - these are informal or semi-formal requests that could be tickets
o Notes
 Both tickets and requests go into a queue for work, and are executed through a value stream
 Value streams are steps to complete work (e.g. define, analyze, build, test).
- Agile
o Product Backlogs - the list of work to be done for the entire project. It's an ordered list of work increments.
o Sprint Backlog - the work that will get done during the sprint.

Note that Backlogs are used for Tickets in Lean and Stories in Agile. You can also have what's often called the "Kanban Sandwich"
where Lean processes are used to set Sprint Goals, Agile is used to manage a Product and Sprint Backlog, and then work during a
sprint is managed in a Lean process.

Controlling Schedule

- Traditional
o Estimated Tasks and Schedules - work is estimated and modeled for precedence
o Program Evaluation and Review Technique (PERT) - adds stochastic modeling of task completion
o Critical Path Method (CPM) - uses deterministic modeling to identify critical tasks for on-time delivery
o Notes
 Determining the critical series of tasks helps to focus managers in traditional on the important tasks
 This does not necessarily align with business importance
 Schedule and scope are fixed; however, scope modeling comes before scheduling to define estimates
and dependencies in the work
 A schedule is considered the primary tool in Traditional Management for controlling delivery
- Lean
o Kanban & Queues - work is managed in a list and executed based on priority
o Service Agreements - sets the priority of work by defining what is critical, major, or minor
o Notes
 Together the Kanban & Queue techniques, along with the Service Agreements, allow for Lean projects
to adjust when delivery will occur for each work item.
 This is intended since schedule is varied in Lean projects
- Agile
o Timeboxes - a set period of time in which the most important work is done first
o Releases and Roadmaps - sets goals for major features to be release together
 o Notes
 Timeboxes are used at all levels of the project to set deadlines
 Sprints are given a fixed time to drive improvement
 Any work not done in the timebox goes back into the backlogs
 Releases and Roadmaps set objects for multiple sprints that can be met at varying quality levels
 This allows for the most important work to achieve an objective to get done first
 This aligns the business importance with what work actually gets done on time

Controlling Budget

- Traditional
o Earned Value Management (EVM) - compares current performance to the plan
 Planned Value (PV) - shows the cost over time expected to complete the work on schedule
 Earned Value (EV) - shows how much work is completed to date
 Actual Cost (AC) - shows the cost so far to complete the work
o Cost Centers
 Evaluates the differences in performance by cost center
 Cost Performance Index (CPI) is the factor EV / AC, where above 1.0 means good performance
 Schedule Performance Index (SPI) is the factor (EV / PV), where above 1.0 means good performance
 This allows you to estimate the costs or savings expected for on-time delivery of total scope
- Lean
o Service and Severity Levels - sets the level at which the company reaps benefits from the solutions
 Service Levels set the Goal
 Severity Levels set the Impact of meeting or not the goal for different problem types
o Key Performance Indicators (KPIs) - evaluate performance against goals for set time periods
 If the KPI is meeting or exceeding the Service Level Goal, then you're making money
 KPIs will often vary over time, so it's important to look at trending
- Agile
o Return on Investment (ROI) - the net income as a ratio to total investment
 Positive ROIs should be expected after the first or second release of a product
 Allows for selecting and refining the backlogs
o Burndown Charts - shows progress in achieving the backlog over time
 Used for projects that haven't yet released the project, or cannot easily estimate ROI
 Projects often start with a set of stories and story points estimated
 The expectation is a linear burndown - meaning a linear decrease in total remaining work to be done
 Teams often are slow at the beginning and speed up over time, or hit snags that stall backlog burn

2.3 Comparing Methods Across Industries

The central part of this lesson is understanding this table below on Size and PM Method:

Traditional Agile Lean

Project Size Large Medium Small

Industries - Construction - Information Technology - Sales

- Military - Product Development - Customer Support
- Government / Policy - Consulting - Legal
- Relocation - Operations - Research & Development

Planning* Master Schedules Releases Backlogs (Prioritized Lists)

Sourcing Efficiency Trust Expertise

Goals Predictable (Low Cost) Speed (Maximize ROI) Innovation (Problem Solve)
Traditional

- Typically Large
- Many connections between stakeholders
- Impact many stakeholders
o Many departments
o Many technologies and concerns
- Good Examples are
o Large building construction
o Military platform acquisition
o Government civil works projects
- Planning is done using a Master Schedule
- Goal is to be predictable and efficient (low cost)

Agile

- Typically Medium in size

- Good examples are
o Building new products
o Ex. SpaceX used modular designs to launch many types of rockets
o Ex. Apple Operating Systems with regular releases over time (incrementally better)
- Planning is done in Releases
o Goal is to get out to market
o Each cycle builds on what came before in releases
- Goal is to be fast and make money (maximize return on investment, ROI)

Lean

- Typically Small
- Good examples
o Building a new solar panel
o Selling or closing a deal
o How we manage ourselves
 To Do: Get the dog from the vet
 Doing: Pick up kids from school
 Done: Bought the presents for the kids' party
- Planning Uses Value streams and Lists
o Setting up a process (e.g. To-Do, Doing, Done)
o Establishing a backlog of work to go through that process
- Goal is to be responsive and innovate (problem solve)

A key question we should ask after considering is why do these groups form around size? Why are the Traditional projects large? The
Agile projects medium in size? The Lean projects small?

Asking these questions drives us to the next lessons on key concerns: Customers and Engineering.
2.4 Comparing Methods of Costumer Management
Traditional Agile Lean

Project Size Large Medium Small

Industries - Construction - Information Technology - Sales

- Military - Product Development - Customer Support
- Government / Policy - Management Consulting - Legal
- Relocation - Operations - Research & Development

Customer Size >250 participants Up to 250 participants Up to 10

Customer Representatives Part of the Team On-Call

Communication Large, Facilitated Meetings Small Meetings Ticketing / Request

Payment Method Firm Fixed Price / Time & Materials / Cost-Plus /

Custom Pricing (Quote) Retail Purchase (Paid) Subscription (SLA)

Traditional

- Customer Size: >250 participants (customers and team)

o Greater than Dunbar's Number
o Many different groups and sets of concerns
- Customer Communication: Formalized
o Large Facilitated Meetings (Public Meetings or Hearings)
o Large Surveys and Teams of Interviews
o Representatives are sent (such as in government) to represent large stakeholder groups
o Change Control Boards ensure all stakeholder (groups) are heard
- Payment Methods
o Almost always Firm-Fixed Price (cannot change the price)
o Requires custom quotes because of the size and complexity
o This involves complex parametric estimation

Agile

- Customer Size: Up to 250 participants (customers and team)

o Department user groups
o Clear Market Segments
- Customer Communication
o Customers are on the team
o Customers engage in ceremonies and provide immediate feedback
o No delays, and often just one representative can suffice for decisions
o Sometimes working groups help to coordinate across functional concerns
- Payment Methods
o Time and Materials (T&M) to scale resources for fixed periods of time
o Retail Purchase (Paid), where a fixed price and targeted units sold ensure profits
Lean

- Customer Size: 10 people or less (customers and team)

o Single user who needs support
o One product group that needs new technology
o One owner or a small group that needs expert advice
- Customer Communication
o On-Call support (customer calls the vendor)
o Ticketing systems (customer logs an issue)
o Communication is then one-on-one with issue holder
- Payment Methods
o Cost-Plus contracts (guaranteed profit plus any expenses)
o Subscription (SLA) or Fixed Fee

Hopefully these new details are opening up one clear set of constraints on Project Management Methods: The Customer. Scheduling
and managing resources using traditional means, with large meetings and formal communication can really make sense at scale; but
also when you have many differing concerns in requirements (stakeholder groups), or an unavailable customer on large, complex
work. Agile works well when the customer prioritizes your project and there can be a single, decision-making representative. Lean
makes sense when the customer needs immediate attention, but at uncertain intervals. Lean also makes sense when the work and
complexity is very small (although the expertise level may be very high).

But is it always up to the customer? What about the product? What kind of engineering is required or resultant based on these
methods to maximize their potential returns?

2.4 Comparing Methods of Engineering Management

Traditional Agile Lean

Project Size Large Medium Small

Industries - Construction - Information Technology - Sales

- Military - Product Development - Customer Support
- Government / Policy - Management Consulting - Legal
- Relocation - Operations - Research & Development

Design Dependent / Coupled Independent / Decoupled Constrained / Evolutionary

Teams Departmental Matrixed / Projectized Emergent (Ad Hoc)

Development Linear Iterative Incremental

Integration / Testing End Phase Continuous When Possible

Closing 3rd Party Acceptance Team Acceptance Customer Acceptance

Important Note Before Reading Further:

- In this lesson there will be discussion of Applications, Features, and Services

- These are Systems Engineering Terms, and Common Terms for many problems - beyond Software Engineering!
Here's how it breaks down:

- Application - the business use of product(s) or service(s) to support the organization

o (e.g. a new car from the dealership)
- Feature - an aspect of an Application that delivers value to its customers
o (e.g. automatic air conditioning)
- Service - a set of functions that serve a common purpose
o (e.g. air sensor system, air cooling system, air heating system, ventilation)

Traditional

- Designs are Dependent of Coupled & Development is Linear

o Driven by need for efficiency
o Heavy amounts of reuse across components
o Drives multiple dependencies into the system
o Any small change in the services results in BIG costs
o This can be efficient with few changes
- Teams: Departmental
o To be efficient we use multiple departments or contracts
o This specialization will lower costs of delivery
o These teams are then matrixed into the project
- Integration and Testing: End Phase
o Because of tight coupling, only at the end phase can we really test
o All parts are connected and could impact each other
o This delays feedback, which in turn freezes requirements
- Closing: Third Party Verification
o A third-party tester is needed to match requirements to the final product
o Only this way can multiple stakeholders trust the results
o This is also a large job, requiring verification expertise

Agile

- Designs are De-Coupled & Development is Iterative

o Allows for building features one at a time
o This requires additional scope around supporting services to make features independent
o This reduces costs of changes, but increases baseline costs
o This also allows for early release of features or minimum viable products (MVP)
o Each iterative release can build on the release that came before it
- Teams: Matrixed / Projectized
o Everyone is on the team
o All departments see and hear the same intent
o This ensures maximum accuracy in communication
o The customer is also on the team
o This also enables speed, reducing handoffs and delayed decisions
- Integration and Testing: Continuous
o By continuously testing the work, the work can be closed for each release
o This is done on cadence with the owners
o This ensures that new features don't break old ones as we add scope with each release
- Closing: Team Acceptance
o The testers are on the team and can immediately inform customer on quality
o The customer is on the team and can accept the work
Lean

- Designs are Evolutionary & Development is Incremental Only

o Limited up-front planning and control on releases
o Features are built based on immediate need, not market segments
o Services evolve underneath features to be both responsive and efficient
o Designs can be complex to maximize reuse, requiring smart but limited engineering work
o Key is to build "just enough"
- Teams: Emergent (Ad Hoc)
o Teams include only those needed at each stage
o This has a mix of people involved depending on current focus of work
o This minimizes costs immediately, but can cause issues in ownership and handoffs
- Integration and Testing: When Possible
o Lean projects are building on-demand without much up-front planning
o This results in an integration "when possible" approach
o As soon as the work is complete its integrated
o Examples are
 New discoveries introduced from R&D
 Fixes to working systems, such as bug fixes or replacement parts
 Upgrades and updates to legal documents once agreement is reached by parties
 Completing deal stages once customer is ready or response time expires
- Closing: Customer Acceptance
o Closing is based on customer acceptance only
o The work stays open until the customer is satisfied
o Customer is agreed to pay all costs until work meets satisfaction or project is cancelled
o Even testers are simply informing customers, usually without authority

Understanding the impact that the chosen PM Method has on Engineering is essential for any project manager. Depending on your
domain of engineering different types of engineering may be possible or nearly impossible. Can one incrementally build a house? It
wouldn't be allowed by the zoning boards, but it would also be dangerous!

At the same time, you only need a single general contractor and a small team to get those repairs done before putting a house on the
market. You may have a fixed budget and need the best ROI to get that house at maximum attractiveness so buyers offer you the
best bang for your investment buck.

And when it comes time to sell, can we understand the inefficiency of always re-writing the typical contract used for closing a house?
Why redesign a whole new contract when you can just update and modify a template? The legal profession lives on templates.

Every aspect of work has its natural fit, but knowing that Agile delivers the maximum profit - can we make our projects more Agile-
ready? What does that require from the customer and the design?

This is where the world of Engineering is headed today:

- All Industries are converging on Agile

- IT is integrating into every product - Andreessen's claim "Software is Eating the World"
- Examples of this trend include:
o Traditional going Agile:
 Building Information Modeling (BIM) - to drive the use of iterative planning and design for one or many
buildings (e.g. Onuma System)
 Government Modular Acquisitions - to enable products of products and systems of systems in the
government space (e.g. Open-Government Movement)
o Lean going Agile:
 Online Legal Products - grouping concerns of typical Lean processes into automated productized
support (e.g. Legal Zoom)
 "Everything as a Service" - human resources, accounting, and marketing are now productized services or
automated services for small businesses
Onuma Planning System Example

- Building Information Models to drive decisions on building investments

- Example of Agile approaches to modeling and planning large-scale requirements for buildings
- Modeled using "Rapid Planning Sessions" where
o Large ships called "Cutters" drove facility requirements
o Facility requirements then drove modeling new buildings and investment at Coast Guard sites
o All future scenarios were modeled using simulations in Google Earth
o Final details were architectural level, down to the "nuts and bolts."
- While this type of system may seem new, it's actually over a decade old
- This allows for iterative through otherwise static, top-down design processes with many interconnected planning details
o All the stakeholders get in a room
o The buildings are simulated in real time
o Architects, Interior Designers, MEC vendors, and Construction can all contribute to designs in real time
o Result is low costs in construction and significantly reduced numbers of change requests
- To learn more go here: http://www.onuma.com/services/BimStorm.php

Hopefully this has you thinking about scope, schedule, and budget in new lights and you've enjoyed learning about who uses Agile
today - will you tomorrow?
Week 3: How to Scrum And Be Agile?

3.0 Introduction to Week 3

3.1 Scrum Team Formation

The key document that sets up the team is the Charter. This includes:

- Project Objectives - what the sponsors and/or customers expect from this project
- Stakeholders - who "has a stake" from sponsors to customers and why. Includes technical, security, business, and
operational stakeholders
- Constraints - what must the project also do or do not in accomplishing the objective, such as standards, interfaces, and
dependencies
- Risks - what are major risks (internal and external), this includes business, technical, political, social, environmental
- Definition of Done - the agreement among stakeholders of how work is closed by the Product Owner and supporting
stakeholders

Once the Team Charter is in-place, the team should assemble based on the skills needed to do the work:

- Product Owner - person responsible for managing the Product Backlog; can only be one person;
- Scrum Master - person responsible for facilitating and keeping the team on track; leads Sprint Planning and Retrospectives
- Development Team Member - person on the team who takes responsibility for the team's success in completing the Sprint
objectives

These are the general types of team members on a Scrum Team; however, we know that many times we need variations based on
our organization. The following are typical variations

Product Owners variations

- Types
o Business Representative - from the business line using the product, or subject matter expert (SME) for customer
o Technical Expert - from the systems engineering or technology group of the customer, has experience with
building for business lines
o Sponsor - the executive, director, or product manager for a business line (internal or external); focuses on
marketing and feature analysis
o Business Owner - the owner of the business selling the product; often a combination of other types of
representatives
- Level of Availability
o Dedicated - always on the team and available to the team; focusing on the backlog refinement whenever not
supporting other team members
o On-Call - available when needed at all times; however, may have limited time outside of team support for backlog
refinement (e.g. other duties)
o Matrixed - works on multiple products or projects, balancing time based on their own direction or the direction of
departmental goals
o Minimal - available only for Sprint ceremonies and minimal other times
o Absent - available with long lead times for set consultation hours; cannot predict if/when they will be available

Scrum Master variations

- Types of facilitation
o Facilitator - facilitates planning meetings, daily scrums, coordination with stakeholders (requirements, etc.), and
retrospectives
o Project Manager - works as facilitator, as well as managing human resources; and is responsible for reporting and
project success
o Junior Project Manager - works as facilitator and is responsible for reporting and project success for the Scrum
team
 o Business Analyst - works as facilitator and also provides supports for Product Owner and Development Team with
requirements elaboration
- Types of Availability
o Dedicated - soles works on the Scrum team
o Split - works across multiple Scrum teams (can be the same or different projects or product lines)
o Rotating Team Member - can be a rotating member of the Development Team who acts as the Scrum Master for
a Sprint
o Matrixed - can be part of a department with responsibilities to the department, Program, Program Management
Office, etc.
o Minimal / Absent - can be only available for running ceremonies and on-call for other facilitation

Development Team Member variations

- Types of representation
o Generalizing Specialist - a team member that can perform any role as needed, but is trained in a certain skill set
(usually development)
o Developer (Hard/Software) - a technical team member who focuses primarily on building the product to
specifications
o Business Analyst / Tester - an analyst who defines and checks the work being developed by the team meets the
Product Owner's intent
o Technical Writer - an analyst who provides support for other team members in capturing notes, metadata, and
communicating work
o Architect - an experienced team member in a technical or business domains that serves as subject matter expert
(SME)
o Support Team - a team member that provides enabling technology, such as work tracking software, builds,
deployments, machining, etc.
- Types of Availability
o Dedicated - soles works on the Scrum team
o Split - works across multiple Scrum teams (can be the same or different projects or product lines)
o Matrixed - can be part of a department with responsibilities to the department, other projects or product lines, or
Centers of Excellence
o On-Call - is available as needed, when needed by the team to provide surge support or expert guidance
o Absent - available with long lead times for set consultation hours; cannot predict if/when they will be available

There are many advantages to having fully dedicated team members. Most often the objections for fully dedicating team members
arise when considering the Product Owner and the Scrum Master. It appears as if these team members have a lot of "downtime"
during the actual Spring Execution phase. This is hardly the case:

- Product Owners need to use time between ceremonies to liaison with Stakeholders
- PO need to research market changes (Political, Environmental, Social, Technological) to validate product features
- PO need to work with team members and provide quick feedback to keep the Development Team running as fast as
possible
- Scrum Masters should to facilitate meetings, especially with stakeholders - this can take a long time to research and
prepare!
- SM should to help guide requirements, development, and testing based on best practices
- SM should to help escalate issues outside the team; and address real-world obstacles that get in the team's way
- SM should always be analyzing the data of the team's performance to identify continuous improvement opportunities
- SM is often having to "prep" the stakeholders and retrain where necessary the Product Owner and Development Team

How does this compare with your organization? Do you have "professional facilitators" who can ensure productive meetings? What
about dedicated product owners to answer questions and make calls so development keeps on-track?

Consider the difference an approach like this might make, and the challenges in implementing it.
3.2 Three-Part User Story
There are three parts to a User Story:

- Value Statement
- Assumptions
- Acceptance Criteria

These work together to for the complete "User Story." It is NOT just the Value Statement.

Value Statement

The proper means of creating a Value Statement is up for debate, but usually the statements are as follows:

- As a...[Who]...I want to...[What Functionality Desired]...in order to...[Why It's Important].

The "Who" is the user, either directly using or consuming outputs from the product the Development Team is building. It's important
that if this user is not clearly defined already in the Project Charter then they are added by the Product Owner, with consensus by the
Stakeholders. This ensures there's a clear understanding when say the term "End User" is put into the [Who] part of the Value
Statement. Usually "End User" is too vague. It should be a descriptive title such as "Research Librarian" or "Fighter Co-Pilot."

The "What" should be the MOST important aspect of the component being built. Often because product features serve multiple users
and needs or wants of users the User Stories can seem to compete with one another. When multiple types of value or outputs are
created by a new product feature or component, make sure that the one that is put in the Value Statement is the priority. Priorities
matter because a product that does everything for everyone in the end serves no one well.

- Most importantly the "What" or "Functionality Desired" should be stated in only business terms. Examples:
o I want to Login Using My User Name and Password --- WRONG!
o I want to access my account --- RIGHT!

The "Why It's Important" is a critical failing of most User Stories. This is true for experienced and beginning Scrum teams. The easiest
trap is to simply restate the "What" in another way. Such as "I want to Login to access my account." As stated above, the proper
"What" in this statement is "access my account." So what's the "Why?" It could be:

- To check notifications
- To assign work
- To check the rankings of my fantasy football team
- The key is that it's important and the MOST important "Why" of the feature or function. Others that are less important
belong in the Assumptions.

Additional key points:

Assumptions are a bucket for everything else

- Captures less important value created by the User Story

- Captures detailing of Why the user story is important
- Identifies constraints from preceding or proceeding tasks, work, components, etc.
- Identifies all the standards, influences, reference architectures, etc.
- Captures other reasons "Why" this story might be important
- Can limit the Acceptance Criteria and the Value Statement - not just the Value Statement
- The only information that is not needed to be listed here, are standard procedures captured in the Definition of Done.
Acceptance Criteria are NOT restatements of the Value Statement

- Should clearly define the primary use cases for testing

- Must specify any performance or loading that the product increment should meet
- Must be comprehensive in detailing all tests that will be run to close the story

Finally it's important to note that all User Stories should be modular because they capture business functionality. If written correctly
these shouldn't ever be in conflict because of technical dependencies.

User Stories are owned by the Product Owner when in the Product Backlog, and then once they are moved into the Sprint Backlog
they are owned by the Development Team. The Development Team can update these stories with comments, but cannot change the
Value Statement, Assumption, or Acceptance Criteria without the Product Owner and Development Team Members' consent.

All User Stories are governed by the Project's Definition of Done. In this way the Definition of Done is the hidden "Fourth Part" of any
user story, although it is focused on process for closing a story. The Definition of Done captures all the standard requirements for
completing work defined in a User Story, such as:

- Standard approvals,
- Reviews by stakeholders
- Prototyping (if required)
- Documentation (for sustainability, reporting, etc.)
- Design constraints (for compliance, integration, etc.)

In this way the Definition of Done helps to modularize the statements within an User Story; but it also provides a clear set of
expectations around quality control and sustainability. These benefits are further elaborated in part in this course, and in greater
depth throughout the Agile Project Management Certificate program.

3.3 Sprint Planning

Sprint Planning has three key objectives:

- Product Owner presents the updated Product Backlog

- Development Team selects and refines User Stories
- Development Team is able to commit to the Sprint Backlog

However, to ensure the authenticity of those objectives are met the following must happen:

- All voices must be heard

- Team must review and elaborate all User Stories in the Sprint
- The Team must be able to size and select those stores within the timebox of the Sprint Planning!

The "timebox" for sprint planning is usually half a day for a two-week sprint, or a full day for a four week sprint. The same applies for
Team Retro and Reviews. This allows for one day out of two weeks (1:9) ratio to be spent on planning and review.

To do this correctly, the team must avoid:

- Getting into long, drawn-out discussions on requirements

- Conflicts that can destablize the planning meeting
- Not having the information needed to plan

The key to making a good Sprint Planning Work is two-fold:

- Great User Story writing by the Product Owner (and/or Development Team in variations of Scrum)
- Planning Games

Great User-Story writing means that the Scrum Master and Product Owner need to work together to ensure User Story quality. This is
especially important when the team has a new Product Owner, who hasn't worked on a Scrum team or THIS Scrum team. Story
writing is extremely cultural.
The use of Planning Games is essential because it helps to facilitate and elicit creativity from the team. Often this is when many teams
will ask, "why not just talk about the stories?" The key reasons for NOT using unfacilitated discussion or "open discussion" is that it's
NOT open:

- Loudest voice in the room wins

- There's no timebox or time limit on discussions
- There's no way to tell when consensus is reached
- There's no way to improve without structure to improve upon

For this reason we use games in Scrum. The most common is the Planning Poker Game.

- Planning Poker Game. Key source for these rules is: http://agileinaflash.blogspot.com/2009/07/planning-poker-r.html
o Agree on a point scale
o Team briefly discusses the User Story
o Everyone picks a card in silence
o Team members reveal the card
o If an outlier exists (more than one step from the mode), then discuss
o (Optional) After two rounds take an average, and validate with a "yes/no" team vote

This process is used to accomplish three things:

- Validate that the size of the story is correct

- Validate that the User Story is well understood
- Ensure all voices are heard equally when disagreements occur

Many times there are disagreements about how to develop a point scale. There are valid reasons, especially when Story Points are
misused by team members or management outside the team. Here are some key points to consider:

- Points are a relative metric

- Points should consider more than effort
o Complexity - how hard is it?
o Uncertainty - how certain are we know the business reqs and potential technical solution?
o Effort - how much total work?
- Points should be consistent across Sprints, but not necessarily across teams

Please note that many types of "Scaling Frameworks" disagree, with basis, on whether User Story points should be an absolute
metric, or at least shared across multiple teams. For Scrum and it's variations this is not important. Story points are solely to help the
team know how much work can be accomplished and if the team is getting faster Sprint after Sprint.

We continue to explore these concepts of how to use scaling of points and measurements of team performance in the Agile for
Control course in the Agile Project Management Curriculum. As well as briefly in next week's lessons on Scaling Frameworks.

Finally there are few additional items to consider for Planning:

- Work iteratively through picking Stories prior to Sprint Planning

- Select Stories that combine to form a cohesive "Product Increment"
o It's best if the Product Owner has something in mind already
o This Product Increment should be written down as a "Sprint Objective" to help focus Planning
- Work one-by-one through User Stories when performing the Planning Poker game
o This is fastest, because everyone is focused on the same story at the same time
o This is easiest because you only have to think about one story at a time
- Make sure to leave a little buffer on your first Sprint
- Make sure that everyone commits to getting the work done - don't let everyone leave without a clear "confidence" vote
from the team
- You will end up refining the Product Backlog and identifying potential dependencies in this process - that's okay!
o When updating the Sprint and Product Backlogs - do it now. Don't lose those moments of insight that come in
planning
 o Make sure that the tools you use are simple and effective to make this go smoothly
- Finally, be sure to prioritize the Sprint Backlog so the Development Team knows which User Stories to start on first the next
day.

By following these guidelines your planning will be faster, more inclusive, and more accurate than any group discussion or interview
process could hope to achieve.

3.4 Sprint Development

To begin, it's important to review the principles of Sprint Development:

- Daily Stand Ups - daily face to face communication so there's no "scheduling" of coordination
- Whole Teams - Everyone knows what the work is (we planned it together), and works on it together
- Team Ownership - Multiple team members working on the same User Story
- Limit WIP - limit the Work-In-Progress (WIP) to achieve faster, predictable development with focused time

When we look at these principles we see a lot of the Agile Manifesto Values restated within them.

- Individuals and Interactions over Processes and Tools Daily

- Working Software (Systems) over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Plan

Daily Stand Ups

- Two types of daily standups

o "Scrum Standup" - each team member reports on what they did, what they plan to do, and any blockers
o "Forward-Looking Standup" - facilitator asks about work-in-progress, team self selects what they'll be doing

Whole Teams

- Whole team is available to work on closing User Stories

o Product Owner provides input on features as developed, and is available to close stories
o Scrum Master facilitates meetings, workshops, and ensures quality through good User Stories, Story Closing, etc.
o Development Team collaborates to complete work, which may mean switching to help others
- Continuous Planning
o As product takes shape, Product Owner consults with stakeholders to gather feedback
o Scrum Master ensures feedback is facilitated and efficient
o Scrum Master works to engage other stakeholders as necessary, or other teams at scale
o Product Owner write stories, which are audited by the Scrum Master

Team Ownership

- Teams know what work needs to get done, each supporting as needed
- Sometimes that means three Development Team Members work on one User Story
o First gathers user interface (UI) and process requirements from stakeholders, and builds UI
o Second begins working on technical solution for middle (logic layer) and backend (data management)
o Third designs and builds tests based on Acceptance Criteria (automated tests)
o Scrum Master might facilitate meetings with stakeholders or UI rapid prototyping
o Product Owner will validate the final product
- If one User Story begins to fall behind, then pair programming or "war rooms" can be established to solve the problem
o Team members know the work, and can jump in to help
o No individual ownership removes issues of "pride of authorship"
o Team reduces risk of failing to deliver critical functionality
- This "Team Ownership" ensures progress on the highest priority work, which also carries the most value for stakeholders
Limit WIP

- Limiting work-in-progress (WIP) enables all processes to work faster

o Reducing WIP means team members are available to support as needed
o Reducing WIP means fewer meetings and coordination activities
o Reducing WIP means clear, small tasks that can be accomplished and reviewed quickly
o Reducing WIP means more time spent getting work done, and less time organizing multiple acitvities
- Primary means of reducing WIP is to use a Kanban or "Scrumban" board
o Kanban board - manages stories as work items, moving Stories across the value stream of a states
 Stories may have three or more states, often requiring five states (Planned, Ready, In-Development,
Testing, Done)
 Each state is limited in terms of the number of stories allowed (such as only two in Testing at once)
 Limiting the WIP in each state ensures that work must be completed before starting new work
o Scrumban Board - manages tasks as work items, moving tasks and then Stories across a value stream of states
 Like Kanban, there are three or more states that tasks and Stories can be in, often five (Planned, Ready,
In-Dev, Testing, Done)
 Stories can only move forward in states in the Value Stream once all tasks have moved forward
 Stories are only "In-Development" if all tasks are "In-Development" or further in the Value
Stream (e.g. "Testing")
 Stories and tasks are managed in their own row or lane
 Scrumban may also include "fast lanes" for high-priority tasks

Note that many of these techniques are borrowed from Lean approaches; especially the Kanban board for limiting WIP. This is
because once Stories are planned the team should operate like a well-oiled machine cranking through work. The goals of continuous
improvement and reducing waste definitely apply.

However, one key aspect of Scrum that differs and remains Agile is the fact that the Product Owner is on the team, and they can
accept work incrementally. Also with the full transparency of the Sprint Backlog showing what work the team must accomplish by the
end of the Sprint, the Development team can decide to manage their time based on those Sprint Requirements. These Stories also
combine to form a meaningful, shippable increment.

For these reasons, Agile offers sustainability, purpose, mastery, and autonomy to the Development Team not offered in pure Lean
approaches. These elements have been proven to be the most motivating for teams of knowledge workers.

More on these ideas of motivation and team facilitation is presented throughout the Agile Leadership Principles course in the Agile
Project Management Professional Certificate.

3.5 Sprint Retro & Review

Two parts to the end of a Sprint:

- Sprint Review: the Product Owner presents the completed, potentially shippable increment to the stakeholders.
- Sprint Retro: the Sprint Team collaboratively inspects the sprint and looks for ways to build on or change for the better.

Goals of a Sprint Review:

- Validate the product is something the users want

- Discuss what the next features should be
- Build stakeholder buy-in
- Force a shippable product to be ready*

The last point is often missed. People when running Reviews think that the Sprint Review is another lecture opportunity. "Look at all
the great work we're doing....in PowerPoint.." That's NOT what the customer or stakeholders want to see. They want to see the
product!
How to run a great Sprint Review:

- Focus on demonstrating the product

- Keep the presentations simple and small
- Avoid PowerPoint if possible, use skits or other creative tools
- Show planned work using the team's system (such as an electronic Kanban system)
- Prepare for the event, but not too much
- Get the stakeholders involved!

Sprint Reviews are also great opportunities to take what can be a very insular process of "Sprinting" to get work done and bring in
those most impacted by the work.

Then, with a wonderful Sprint Review and lots of positive feedback, it's time to take that positive energy into the Sprint
Retrospective.

Goals of the Sprint Retrospectives:

- Capture what went right during the sprint

- Capture what went wrong during the sprint
- Capture what the team can do to improve

Sprint Retrospectives are much like Sprint Planning, they require practice. However, the benefits are enormous for teams that
perform "Retros:"

- Identify and plan work to improve team systems

- Stop doing the bad stuff early
- Use "lessons learned' on YOUR project (imagine it!)
- Dedicate time to hear from everyone, and gain team buy-in

Just like in the Sprint Planning, the best way to execute the Sprint Retrospective is to play a game. This has become known as the
"Retro Game:"

- You have two parts:

o Evaluate what went right and wrong
o Evaluate what the team can do
- For both parts (you do this twice) the script should be as follows (requires sticky notes or a similar tool). Each step is
timeboxed (e.g. has a time limit):
o Each person writes down on sticky notes what they think - one idea per note
o Each person then puts up on a board their thoughts on a board
o The whole team then works together to group and label similar thoughts
o The Scrum Master then facilitates a discussion, with the group's a talking points
- After the two rounds, the team should then work together to write User Stories on the "Can Do" items.
- Key points are recorded for later review by the Scrum Master

The heart and soul of an Agile team can be made stronger through great Retrospectives and Reviews. However, at first this practice is
going to feel awkward for those in less open speaking cultures. That's why we need the structure and the games to organize input.
That's also why the Scrum Master needs to be a great facilitator.

This process should be in its core a team building exercise. That's why there's one more step often missed, but sorely needed:

The whole team gets out of the building (or area) and does something social together.

If there's anything to remember is that we are all people on this team. It's all about Individuals and Interactions OVER processes and
tools. As you engage in the end of Sprint ceremonies the momentum and potential fatigue from a hard-fought sprint looms over.
Don't let that inertia win. Shake it off and run great, personal Retros and Reviews that treat people like people.

In short order you'll have a high-performing team that likes the way the work and the people they get to work with every day.
Week 4: What Scrum Framework Fits Best?

4.0 Introduction to Week 4

4.1 Scrum in the world of Agile

The World of Agile is HERE!

According to PMI's Pulse of the Profession:

o Only 47% of projects use Predictive / Traditional approaches

o Almost 1/2 of all projects are now Agile in nature

 Half are "pure Agile" and usually Scrum

 Half are hybrid Agile

o Most organizations see Agility as essential to staying competitive (71%)

This means that you've made a great investment learning Scrum, because no matter what you're likely going to need these skills in
one out of two projects you conduct professionally. In fact, if we look at the primary reasons why projects fail we see the likelihood
that Agile will continue to grow.

Here are the top reasons why projects fail according to PMI's Pulse of the Profession:

 Change in the organization's priorities - 39%

 Change in project objectives - 37%

 Inaccurate requirements gathering - 35%

And these were all tied for fourth at 29%

 Inadequate vision or goal

 Inadequate, poor communication

 Opportunities and risks were not defined

When you review these aspects, who do they align to the Agile Manifesto? How do they align to the benefits we've discussed in
Week 3 on how Scrum works? 

The reality is that Agile addresses the primary challenges facing projects today directly: objectives, requirements, and
communication.

Understanding that Agile continues to grow, we also see in Verizon One's State of Agile report that most projects use Scrum:

 56% use "pure" Scrum

 75% use Scrum, Scrumban, Scum/XP, or Kanban methods

This is because Scrum is simple, works, and is great for small teams. But as we've reviewed, there's no greater "organization" in the
Scrum model. So what about Scale? How do these organizations that use Scrum scale their Agile approaches?

There are four major types of scaling methods used today, according to Verizon One's survey:

 Scaled Agile Framework (SAFe) - 29%

 Scrum of Scrums - 19%

 (Internally Created Methods) - 10%

  Disciplined Agile Delivery (DAD) - 5%

 Large Scale Scrum (LeSS) - 5%

This accounts for the major majority of methods used. Often we see that internally created methods tend to look like Hybrid
methods. In the next sections we'll explore SAFe, DAD, and LeSS. Each has the following items in common:

 All use Scrum as the base model for managing teams

 All have Product Owners, Scrum Masters, and Development Teams

 All differ on how to mange "Support Teams" and how to make an organization Agile.

The simplest means of understanding Agile at Scale is to look at the two methods originally used to Scale Agile:

 Scrum of Scrums - teams coordinate work through sending representatives to have Daily Stand Ups
across teams.

 Hybrid Methodology - teams are coordinated by using Predictive or Traditional controls, such as stage
gates, to manage delivery

Scrum of Scrums:

 Scrum of Scrums Stand Ups: Teams send a representative, although usually this is a Product Owner or
Scrum Master

 Can take literally just a long as a standard Daily Stand Up

 Focuses on reporting out completions and blockers

 Opportunity to identify need for coordination among team memebrs

 Scrum of Scrums have a Scrum Master

 Usually a senior person in the organization

 Responsible for facilitating the coordination of work

 Responsible for overall productivity of the Scrum of Scrum Teams

 Scrum of Scrums applies when two teams have potential dependencies

 Share resources (people, services, etc.)

 Shared product in development

 Shared goal or vision

 Originally this was proposed by Jeff Sutherland, one of the founders as Scrum and signatories of the
Agile Manifesto in 2001

 "Agile Can Scale: Inventing and reinventing SCRUM in Five Companies" - Jeff
Sutherland, Cutter IT Journal, 2001

 Provides story of using Scrum of Scrums at IDX, where weekly product line Scrums
and Monthly Management Scrums occurred.

 Some teams became "hyper-productive," a state of Scrum teams that Jeff

Sutherland talks of being 4 to 5 times more productive

Scrum of Scrums offers a very simple, and yet elegant means of scaling Scrum. In fact, the practice has been used by many very large
scale organizations to achieve organizational agility. 
In the HBR Article, Agile at Scale (2018), there are examples of Scrum of Scrums spanning hundreds of people in less than one hour:

 Saab's aeronautics business has over 100 agiel teams for its Gripen fighter jet ($43M project)

 Daily Stand Ups occur from 7:30 AM to 8:45 AM

 By the end of the the Stand Ups using Scrum of Scrum approaches, the executive team knows the
critical issues it needs to address

 That's over 500 people fully reporting using word-of-mouth in less than 90 minutes

This model is having a resurgence now among many Agile practitioners. Especially as many organizations are expanding their
understanding of Agile and using Hybrid means or SAFe to transition into becoming an Agile organization.

The Hybrid model that is most commonly used by organizations is rather simple:

 Traditional means are used to control major decision points

 Stage Gates are leveraged especially for Requirements, Design, and Operations
(Deployment)

 This offers a chance for the Traditional / Predictive leadership to approve the next
"Stage" of the project

 Agile (Scrum) methods are used to rapidly and iteratively develop products in each stage

 Whole teams are used to develop Requirements, Designs, Development, and

Verificatoin

 Whole teams are able to prototype and create reusable document

 Requirements are managed as User Stories

 Stories are generated in Requirements, refined in Design, Implemented and closed

in Development

 Development is often still iterative and incremental for speed and learning

 Development may have multiple releases to a "staging" or "pilot" environment

 Verification is run for system-level requirements against use cases

This effectively looks like iterations between stage-gates; and is often more successful in organizations that resist Agile. Since
organizational resistance to Agile and misunderstanding of Agile are the primary reasons for Agile failing (according to Verizon One),
this makes sense for many new entrants learning Agile for the first time.

When looking at the major reasons that Agile fails, we see the following:

 Organizational culture at odds with agile values - 53%

 General organizational resistance to change - 46%

 Inadequate management support - 42%

 Lack of skills/experience with agile methods - 41%

These statistics show why the Hybrid model is so popular among about half the practitioners of Agile in more traditional
organizations. For this reasons "Internal Agile" is a great means of proving the effectiveness of the method when there's no upper
management support. However, the only means of truly achieving agility is to have leadership support and good Agile training.

So how do we convince the leaders who are disbelievers in Agile? Show them the data:

 Reasons for Adopting Agile

  Accelerate Software Delivery - 75%

 Manage changing priorities - 64%

 Increase productivity - 55%

 Better alignment of business and IT - 49%

 Increased software quality - 46%

 Benefits of adopting Agile (percentages show counts, not impact)

 Better management of priorities - 71%

 Project visibility - 66%

 Alignment of business and IT - 65%

 Delivery speed / time to market - 62%

 Team productivity - 61%

And in terms of impact, the benefits can be four to five times the productivity and value output; as seen in the Ambysoft survey in
2013.

Now that you understand the Scrum in the World of Agile, and you know that world is here (!):

1. What framework will you choose?

2. How will you achieve the benefits (speed and innovation)?

3. How will you manage the change (leadership and control)?

The other lessons in this week will try to help you answer the first question. To answer questions 2 and 3, we highly recommend you
sign up for the remaining courses in the Agile Project Management Certificate. Just like in this course, if you Verify you'll get tools,
additional resources, and insights that go beyond these lectures and notes to enable the change in your projects.

Now, go be Agile and win!

Sources:

 Pulse of the Profession 2018, Project Management

Institute: https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-
leadership/pulse/pulse-of-the-profession-2018.pdf

 12th Annual State of Agile Report, Verizon One: https://explore.versionone.com/state-of-

agile/versionone-12th-annual-state-of-agile-report

 Agile At Scale, DarrellK Rigby, Jeff Sutherland, and Andy Noble, Harvard Business
Review: https://hbr.org/2018/05/agile-at-scale

 Scrum of Scrums, Agile Alliance: https://www.agilealliance.org/glossary/scrum-of-scrums/

 Agile Can Scale: Inventing and Reinventing Scrum in Five Companies, Jeff Sutherland, Cutter IT Journal:
http://static1.1.sqspcdn.com/static/f/447037/6486358/1270929593650/Sutherland+200111+proof.pdf
?token=NxTveQbRt0U%2FEaViggp0AauZLY8%3D
4.2 Exploring the Scaled Agile Framework (SAFe)
SAFe introduces many new roles to the Agile framework beyond the Scrum's three main roles of Product Owner, Scrum Master, and
Development Team member. These roles considered essential to manage the integration and flow of products across many Agile
teams running concurrently. 

o System Teams - those that manage delivery and integration of products produced by individual Scrum teams

o Architecture Teams - manages and promotes the shared architecture framework across teams

o Product Manager - leads the Product Owners as the primary person in charge of targeting features and EPICs

o Release Train Engineer  - leads the Scrum Masters on each of the Scrum teams, and conducts the large team or
team ceremonies

By adding these essential teams, and others when needed, many teams can work together. These teams help make up what is
termed the "Agile Release Train" or ART.

ARTs are how many agile teams work together on a single product or part of the business. For instance if there is a Financial company
that wants to develop a new mobile banking application for loans, then all Agile teams working on that application might be on the
same Agile Release Train. There then might be a separate Agile Release Train or "ART" for developing internal accounting software.

SAFe aligns ARTs to the business Value Stream. By modeling the business as a Lean process (remember Week 2), the organization can
then continuous improve how it delivers value to customers using the Plan-Do-Check-Act (PDCA) cycle.  ARTs are the teams that build
and deploy changes to each step in the business value stream. 

 Agile Release Trains (ARTs) align to one or more similar parts of the Business Value Stream

 ARTs are limited to up to 120 people, keeping on the lowside of Dunbar's number

 ARTs work together through the Sprint process, with shared ceremonies at the Release boundaries

This introduces the need to coordinate very large groups through the typical Sprint processes of Planning, Development, Review and
Retrospectives. One of the most prominent aspects of SAFe is what's called the "Big Room Training" and "Big Room Planning" during
Release Planning. Each Release is called a "Program Increment" and usually takes four to six sprints.

Program Increments (PI) Planning:

 All Agile Teams get in a room (can be up to 200 people, when accounting for stakeholders and Systems
Teams)

 The Release Train Engineer organizes and coordinates the Planning Day

 The Product Manager provides a shared vision, set of features, and priority for the next Release

 Product Owners and Scrum Masters each play their role to execute Planning

 Points are considered absolute (at least at first) to compare across teams with one point equal to one
person for one day

 Teams commit to complete PI Objectives, instead of stories (which belong to the team)

 PI Objectives are given business value points by Business Owners

 Teams identify their dependencies across each other during this planning

 The Program Board captures all work and dependencies across teams

 The Teams "ROAM" risks: Resolve, Owned, Accepted, or Mitigated

 Everyone gives a "vote of confidence" on whether they can meet the objectives, and keeps going until
the whole team puts up "5 out of 5."
Program Increment Inspect and Adapt (IA):

 System demo is performed across all teams

 Often includes the Project Sponsors (Business Owners)

 Humanizes management

 Business Owners give feedback on achievement of business value points

 Retrospectives are run briefly to identify the most important problem to solve

 Problems are then addressed using workshops that include Business Owners, with clear outcomes and
support by leadership

A couple of the principles that make SAFe work are:

o Take an economic view - Instead of just responding to customer wishes, work is evaluated in terms of cost of
delay (CoD).

o Plan on cadence, release on demand  - All teams must plan together, but they can release whenever work is
ready.

o Base milestones on objective evaluation of working systems - The work is only considered done when it is fully
demoed at the system level

o Visualize and limit WIP, reduce batch sizes, and manage queue lengths - leverage the Lean principles of limiting
WIP and managing queues with small batches helps prevent turning independent teams back into departmental-
like groups

Another issue that SAFe addresses at scale is the need to continuously explore, develop, and deploy new solutions. This is embodied
in their ideals of "Continuous Everything;" which promotes the movement of potential work, work-in-progress, and done work
through Value streams.

SAFe has three four levels of implementation to help answer these ideas:

o Essential SAFe - basic SAFe with only Business Owners managing as executives often on a single Agile release train
(ART)

o Portfolio SAFe - includes a portfolio management function to align funding across teams or trains

o Large-Solution SAFe - Introduces the concepts of having Suppliers that integrate delivery along with multiple
ARTs on a Solution Train

o Full SAFe - Includes a Portfolio Management function above the Large-Solution when managing across Solution
Trains and other ARTs

To learn a little more about SAFe, check out these great videos as well that can help guide you through the 

o Explanation of SAFe in 5 minutes: https://www.youtube.com/watch?v=tmJ_mJw8xec

o SAFe Version 4.5: https://www.youtube.com/watch?time_continue=1&v=qTG4I6jUbj4

o Scaled Agile Framework Online: https://www.scaledagileframework.com

If you plan to learn more on the Scaled Agile Framework (SAFe) we're sure you'll enjoy the ride!

All materials and information are courtesy of Scaled Agile, Inc.'s general release at www.scaledagileframework.com/videos-and-
presentations/
4.2 Exploring Disciplined Agile Delivery (DAD)
Disciplined Agile Delivery starts from one single premise: being Agile doesn't permit teams to be undisciplined.

Disciplined Agile Delivery (DAD) grew from origins in Extreme Programming (XP), Scrum, and Lean. As it's original forms were being
codified it was clear that Agile was being used by many teams to avoid good practices of sustainable development. "We don't do that,
we're Agile" was a common phrase that frustrated many in the Enterprise. DAD offers a compromise that many people today find
extremely valuable in fitting into the organization.

The key characteristics of Disciplined Agile Delivery are:

 People first

 Learning oriented

 Agile

 Hybrid

 Goal-driven 

 Delivery focused

 Enterprise aware

 Risk and value driven

 Scalable

In order to achieve these goals, the Disciplined Agile Delivery process uses a hybrid framework with stages that align with the
Traditional Stage-Gate model, from concept to retirement (disposal). It's focus in generally on very large solutions that are required
for organizations or developed within large organizations that roll out a product line. 

The key difference between this model and the typical Scrum Model that starts when a team is initiated with funding is as that DAD
uses a startup phase called "Inception." During this phase many important things happen to help scale:

 Modeling of the solution

 Proof of concepts are explored

 Shared architectures across teams are initiated

 High-level release planning and feature roadmaps are established

During this phase the teams often work in functional and cross-functional groups. This startup phase allows for a shared
understanding going into the solution development or "Construction Phase."

Disciplined Agile also believes in many more roles than Scrum does:

 Primary Roles:

 Stakeholder - these are the same as in Scrum - anyone who is impacted by the
solution being built (owners, support, customers, etc.)

 Team Member - focuses on producing solutions for stakeholders, the Scrum

"generalizing specialist"

 Team Lead - servant leader that coaches and helps organize delivery, and often
considered an "Agile Project Manager"

 Product Owner - provides the "voice of the customer" as either the representative,
actual customer, or business line expert
  Architecture Owner - can be simple as the "senior developer" or an architect; with
the goal of reducing technical debt risk at scale

 Secondary Roles:

 Specialist - may be the specialist in a certain technology or tool that's used in the
solution

 Domain Expert - provides detailed domain expertise on critical topics for parts or
details of complex solutions

 Technical Expert - can be experts in key non-functional areas (user interface,

security, databases, etc.) needed for performance

 Independent Tester - can be required for complex solution environments or for

regulatory requirements (such as government)

 Integrator - can be a separate role for integration and delivery mechanisms in

complex solutions, such as DevOps teams

Disciplined Agile Delivery works by always having the Primary Roles (although sometimes the Architecture Owner and Team Lead are
the same person). Then it adds the Secondary roles as needed.

In order to scale across teams, DAD uses the "team of teams" model, building on the "Scrum of Scrums" concept invented by Jeff
Sutherland.

 DAD Agile teams meet in Daily Standups

 DAD Team Leads meet separately to coordinate delivery, as the Product Delivery Team

 DAD Architecture Leads meet separately to coordinate architecture and remove dependencies, as the
Architecture Team

 DAD Product Owners meet separately to coordinate planning, as the Product Management Team

These teams of teams models are then coordinated, as needed, by an overall Program Manager role. 

From this basic scaling model, Disciplined Agile then extends these concepts to the organizational level. How can we mature the
organization into a "Learning" organization. In fact, the ideas are that the Agile model is a startup model for Disciplined Agile that can
be used to eventually create a lean-agile organization that continuously performs the "stages" of development as needed.

Concepts that are built in are the idea of scaling the "Supporting Cast." Those in the secondary role can become their own Agile
teams that produce products used by the Disciplined Agile teams to delivery new product. Support teams include everything that
could be considered "Development-Operations" or DevOps:

 IT Operations

 Customer Support

 Security

 Data Management

 Release Management

These teams are then further scaled up into the total Product Management realm, deemed the "Disciplined IT" realm including
Governance and Reuse of products (COTS, GOTS, FOSS), as well as Enterprise Architecture, People Managemenet, and Portfolio
Management.

Then Disciplined Agile goes one step higher, suggesting that the entire Enterprise can behave in an Agile manner. Every part of the
organization can be its own Agile team or team of teams. This applies to Sales, Marketing, Legal, and Finance, as well as other
organizational areas.
To keep the entire organization aware of its own structure, there is a need for "Organizational Assets" and the "Knowledge Base."
This means that the Organization becomes its own market for consuming products both internally and externally. By managing a
central portal to access the key information and tools needed to run the organization, each team can run without being directive to
the others.

This is the actualization of the ideas of a adaptive learning organization. The stages of which are below (shorted from longer forms
you can find at http://www.disciplinedagiledelivery.com/dae/):

 Tribal - impulsive, and driven by urgency; management "preys" on its employees

 Traditional - Authoritarian, driven by protocols and formal roles and hierachies

 Scientific - Profit or growth-oriented, driven by innovation and meritocracies of ideas

 Post-Modern - Consensus driven, with values-based decision making

 Living - Cellular models of management with an evolutionary purpose

Do these ideas make sense to you? What kind of organization do you work in?  You can learn more about the concepts and ideas of
Disciplined Agile Delivery here: http://www.disciplinedagiledelivery.com

Other Sources of key pages cited here:

 Introduction to Disciplined Agile: http://www.disciplinedagiledelivery.com/introduction-to-dad/

 Disciplined Agile Lifecycle: http://www.disciplinedagiledelivery.com/lifecycle/agile-lifecycle/

 Disciplined Agile Enterprise: http://www.disciplinedagiledelivery.com/dae/

 Disciplined Agile Teams: http://www.disciplinedagiledelivery.com/roles-on-dad-teams/

 Disciplined Agile Teams at Scale: http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-

teams/

Books referenced:

 Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise, Scott
Ambler and Mark Lines, 2012.

4.4 Exploring Large Scale Scrum (LeSS)

The LeSS system provides two types of scaling of Products to remove other potential roles:

o LeSS - used for up to eight (8) teams of eight

o LeSS Huge - used for up to thousands of teams delivering products together in single increments

This way the organization can avoid unnecessary "dotted lines" that take away power and control from the Scrum Teams which in
turn zaps productivity and pride of workmanship.

According to the philosophy behind LeSS, Scrum works as it is designed for one team. And it shouldn't be changed for one team. No
matter the complexity of the product, it should remain that there are three roles:

 Product Owner (PO)

 Scrum Master (SM)

 Development Team Member (DT)

And in the LeSS these roles persist and remain the only roles for up to eight (8) teams. It's important to note that LeSS suggests that
teams be aligned to features to maximize their ability to "specialize" on the architecture of a product and work independently.
Beyond eight (8) teams only one additional role is added to support the Product Owner. This role is the Area Product Owner, and they
are needed because of the pressure on the Product Owner to manage such a large backlog is too great:

 Area Product Owner (APO) - provides a buffer of work definition and act as intermediaries to help manage an "area" of
requirements

 Product Owner (PO) can have up to ten (10) APOs working with them to manage requirements, forming
the Product  Owner Team

 Can manage up to eight teams

 Cannot override the prioritization of the product backlog items - this still belongs to the PO

At this point there is enough "scaling" that it can handle global operations of product development. Sites can have multiple teams,
and areas can include anywhere from five to ten teams. When multiplied this allows a single Product Owner to manage up to a
thousand or more team members.

But why create such large structures of Scrum?

The answer is using Large Solutions to De-Scale the organization.  Organizations looking to create smaller, more independent teams
to Scrum will drive towards an model that performs "Fake De-Scaling." These ideas are as follows:

o We create "independent" teams with internal and external markets, everyone has customers and are consumers
of Agile teams

o For larger products, "independent Teams" need a portfolio manager to ensure alignment of efforts, because
otherwise they'll diverge

o Portfolio Management leads to integration and dependencies because there are real-word physical dependencies
in products

o Integration and dependencies drive the need for rules so teams can stay independent

o These rules re-introduce the Program Management Office (PMO) to control coordination

o Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to
manage them

So what does the organization then look like for the LeSS company?

For those that there will be an enabling leader who is the "Head of Product." This person will provide coordination and support using
the Servant Leadership model of management. The responsibilities include managing:

o Site Locations - ensuring the teams are supported with facilities, people, etc.

o "Undone Departments" - those departments that are still functionally aligned or separate from Scrum Teams

o Support Teams - these teams provide a lean service of support to the large teams (such as delivery or DevOps)

o Product Owner Team - led by the PO in charge of the product, this team develops and prioritizes the backlog

o Competence & Coaching - the functions of training and coaching to ensure continuous improvement

Higher levels of management are intended to provide similar types of "servant leadership" support for the organization. The goal
being to enable teams to work according to the LeSS principles:

o Large-Scale Scrum is Scrum - LeSS is just dealing with the unavoidable scale of some products, but remains scrum

o Empirical process control - processes should be subordinate to the product and market needs

o Transparency - required to drive fear out and improvement into the workplace
 o More with Less - gain better teams, ownership, and reduced waste with less process and control

o Whole-products - focus on the product in delivery, not just the part of the product, so efforts are aligned

o Customer-centric - by focusing on the customer, everyone aligns to the priorities and needs while reducing waste
of other distractions

o Systems thinking - understand that the system is the focus, not the local performance of a team, so waste is
reduced and flow is optimized

o Lean thinking - continuous improvement and the Go See approach to management drive a respect for workers
and continuous improvement

o Queuing theory - understanding that long queues increase cycle time, reduce feedback speed, increase variability,
and result in multi-tasking

To learn more about these concepts go to: https://less.works/

Sources:

o De-Scaling Organizations: https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html

o How too many rules at work keep you from getting things
done: https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things
_done#t-983376

o Requirements Areas: https://less.works/less/less-huge/requirement-areas.html

o Area Product Owner: https://less.works/less/less-huge/area-product-owner.html

o LeSS Organizational Structure: https://less.works/less/less-huge/organizational-structure.html

o More-with-Less: https://less.works/less/principles/more-with-less.html

o LeSS Role of a Manager: https://less.works/less/management/role-of-manager.html

o LeSS Principles Overview: https://less.works/less/principles/overview.html

Additional Great Video Resources:

o Scaling Agile with LeSS Large Scale Scrum: https://www.youtube.com/watch?v=dKEIaJ7qBew

o Introduction to LeSS (Large-Scale Scrum): https://www.youtube.com/watch?v=1BZf_Oa7W94