Lesson Week Topic Knowledge

Check
    Week 1  
1 1 Agile Basics X
2 1 Proof Agile Works X
3 1 Evolution of Agile X
4 1 Netflix Case Study X
5 1 18F Case Study  X
    Week 2  
6 2 Simple PM Methods X
7 2 Approaching the Simple Cost Constraint X
8 2 Comparing Methods Across Industries X
9 2 Comparing Methods of Customer Management X
10 2 Comparing Methods of Engineering Management X
    Week 3  
11 3 Scrum Team Formation X
12 3 Three-Part User Story X
13 3 Sprint Planning X
14 3 Sprint Development X
15 3 Sprint Retro & Review X
    Week 4  
16 4 Scrum in the World of Agile X
17 4 Exploring the Scaled Agile Framework (SAFe) X
18 4 Exploring Disciplined Agile Delivery (DAD) X
19 4 Exploring Large Scale Scrum (LeSS) X
20 4 Pitfalls X
20+ 4 Final Exam  

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.

Name

The software development term scrum was first used in a 1986 paper titled "The New New
Product Development Game". The term is borrowed from rugby, where a scrum is a formation of
players. The term scrum was chosen by the paper's authors because it emphasizes teamwork.[3]

Scrum is occasionally seen written in all-capitals, as SCRUM.[4] While the word itself is not an
acronym, its capitalized styling likely comes from an early paper by Ken Schwaber[5] that
capitalized SCRUM in its title.[6][7]
While the trademark on the term Scrum itself has been allowed to lapse, it is deemed as owned by
the wider community rather than an individual,[8] so the leading capital for Scrum is retained in
this article.

Many of the terms used in Scrum are typically written with leading capitals (e.g., Scrum Master,
Daily Scrum). However, to maintain an encyclopedic tone, this article uses normal sentence case
for these terms (e.g., scrum master, daily scrum) – unless they are recognized marks (such as
Certified Scrum Master).

Key ideas

Scrum is a lightweight, iterative and incremental framework for managing complex work.[9][10]
The framework challenges assumptions of the traditional, sequential approach to product
development, and enables teams to self-organize by encouraging physical co-location or close
online collaboration of all team members, as well as daily face-to-face communication among all
team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what
they want or need (often called requirements volatility[11]) and that there will be unpredictable
challenges—for which a predictive or planned approach is not suited.

As such, Scrum adopts an evidence-based empirical approach – accepting that the problem cannot
be fully understood or defined up front, and instead focusing on how to maximize the team's
ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving
technologies and changes in market conditions.

History

Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product
development in their 1986 Harvard Business Review article, 'The New New Product Development
Game'.[12] Takeuchi and Nonaka later argued in The Knowledge Creating Company[13] that it is a
form of "organizational knowledge creation, [...] especially good at bringing about innovation
continuously, incrementally and spirally".

The authors described a new approach to commercial product development that would increase
speed and flexibility, based on case studies from manufacturing firms in the automotive,
photocopier and printer industries.[12] They called this the holistic or rugby approach, as the
whole process is performed by one cross-functional team across multiple overlapping phases, in
which the team "tries to go the distance as a unit, passing the ball back and forth".[12] (In rugby
football, a scrum is used to restart play, as the forwards of each team interlock with their heads
down and attempt to gain possession of the ball.[14])

The Scrum framework was based on research by Schwaber with Tunde Babatunde at DuPont
Research Station and University of Delaware. Tunde advised that attempts to develop complex
products, such as software, that weren't based in empiricism were doomed to higher risks and
rates of failure as the initial conditions and assumptions change. Empiricism, using frequent
inspection and adaptation, with flexibility and transparency is the most suitable approach.

In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced
Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a
similar approach at Easel Corporation, referring to it using the single word scrum.[15]

Ken and Jeff worked together to integrate their ideas into a single framework, Scrum. They tested
Scrum and continually improved it, leading to their 1995 paper, contributions to the Agile
Manifesto[16] in 2001, and the worldwide spread and use of Scrum since 2002.

In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum framework at
the Business Object Design and Implementation Workshop held as part of Object-Oriented
Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas.[17] Over the
following years, Schwaber and Sutherland collaborated to combine this material—with their
experience and evolving good practice—to develop what became known as Scrum.[18]

In 2001, Schwaber worked with Mike Beedle to describe the method in the book, Agile Software
Development with Scrum.[19] Scrum's approach to planning and managing product development
involves bringing decision-making authority to the level of operation properties and certainties.[6]

In 2002, Schwaber with others founded the Scrum Alliance[20] and set up the Certified Scrum
accreditation series. Schwaber left the Scrum Alliance in late 2009 and founded Scrum.org[21]
which oversees the parallel Professional Scrum accreditation series.[22]

Since 2009, a public document called The Scrum Guide[18] has been published and updated by
Schwaber and Sutherland. It has been revised 5 times, with the current version being November
2017.
Roles

This section possibly contains original research. Please improve it by verifying the claims made and
adding inline citations. Statements consisting only of original research should be removed. (April
2019) (Learn how and when to remove this template message)

There are three roles in the Scrum framework.[23] These are ideally co-located to ensure optimal
communication among team members. While many organizations have other roles involved with
defining and delivering the product, Scrum defines only these three.[18]

Product owner

The product owner, representing the product's stakeholders and the voice of the customer (or
may represent the desires of a committee[24]), is responsible for delivering good business results.
[25] Hence, the product owner is accountable for the product backlog and for maximizing the
value that the team delivers.[24] The product owner defines the product in customer-centric
terms (typically user stories), adds them to the Product Backlog, and prioritizes them based on
importance and dependencies.[26] A scrum team should have only one product owner (although a
product owner could support more than one team)[27] This role should not be combined with that
of the scrum master. The product owner should focus on the business side of product
development and spend the majority of their time liaising with stakeholders and the team. The
product owner should not dictate how the team reaches a technical solution, but rather will seek
consensus among the team members.[28][29][30][better source needed] This role is crucial and
requires a deep understanding of both sides: the business and the engineers (developers) in the
scrum team. Therefore a good product owner should be able to communicate what the business
needs, ask why they need it (because there may be better ways to achieve that), and convey the
message to all stakeholders including the Development Team using a technical language, as
required. The Product Owner uses Scrum’s empirical tools to manage highly complex work, while
controlling risk and achieving value.

Communication is a core responsibility of the product owner. The ability to convey priorities and
empathize with team members and stakeholders is vital to steer product development in the right
direction. The product owner role bridges the communication gap between the team and its
stakeholders, serving as a proxy for stakeholders to the team and as a team representative to the
overall stakeholder community.[31][32]

As the face of the team to the stakeholders, the following are some of the communication tasks of
the product owner to the stakeholders:[33]
Define and announce releases.

Communicate delivery and team status.

Share progress during governance meetings.

Share significant RIDAs (risks, impediments, dependencies, and assumptions) with stakeholders.

Negotiate priorities, scope, funding, and schedule.

Ensure that the product backlog is visible, transparent and clear.

Empathy is a key attribute for a product owner to have—the ability to put one's self in another's
shoes. A product owner converses with different stakeholders, who have a variety of backgrounds,
job roles, and objectives. A product owner must be able to see from these different points of view.
To be effective, it is wise for a product owner to know the level of detail the audience needs. The
development team needs thorough feedback and specifications so they can build a product up to
expectation, while an executive sponsor may just need summaries of progress. Providing more
information than necessary may lose stakeholder interest and waste time. A direct means of
communication is the most preferred by seasoned agile product owners.[27]

A product owner's ability to communicate effectively is also enhanced by being skilled in

techniques that identify stakeholder needs, negotiate priorities between stakeholder interests,
and collaborate with developers to ensure effective implementation of requirements.

Development team

The development team has from three to nine members who carry out all tasks required to build
increments of valuable output every sprint.[26]

While team members are referred to as developers in some literature[18], the term refers to
anyone who plays a role in the development and support of the system or product, and can
include researchers, architects, designers, data specialists, statisticians, analysts, engineers,
programmers, and testers, among others.[23] However, due to the confusion that can arise when
some people do not feel the term 'developer' applies to them, they are often referred to just as
team members.

The team is self-organizing. While no work should come to the team except through the product
owner, and the scrum master is expected to protect the team from too much distraction, the team
should still be encouraged to interact directly with customers and/or stakeholders to gain
maximum understanding and immediacy of feedback.[26]
Scrum master

Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability
of the team to deliver the product goals and deliverables.[34] The scrum master is not a traditional
team lead or project manager but acts as a buffer between the team and any distracting
influences. The scrum master ensures that the scrum framework is followed. The scrum master
helps to ensure the team follows the agreed processes in the Scrum framework, often facilitates
key sessions, and encourages the team to improve. The role has also been referred to as a team
facilitator or servant-leader to reinforce these dual perspectives.

The core responsibilities of a scrum master include (but are not limited to):[35]

Helping the product owner maintain the product backlog in a way that ensures the needed work is
well understood so the team can continually make forward progress

Helping the team to determine the definition of done for the product, with input from key
stakeholders

Coaching the team, within the Scrum principles, in order to deliver high-quality features for its
product[36]

Promoting self-organization within the team

Helping the scrum team to avoid or remove impediments to its progress, whether internal or
external to the team

Facilitating team events to ensure regular progress

Educating key stakeholders on Agile and Scrum principles

Coaching the development team in self-organization and cross-functionality

The scrum master helps people and organizations adopt empirical and lean thinking, leaving
behind hopes for certainty and predictability.

One of the ways the scrum master role differs from a project manager is that the latter may have
people management responsibilities and the scrum master does not. A scrum master provides a
limited amount of direction since the team is expected to be empowered and self-organizing.[37]
Scrum does not formally recognise the role of project manager, as traditional command and
control tendencies would cause difficulties.[38]

Workflow

Sprint
Scrum framework

Not to be confused with Hackathon § Code sprints.

The Scrum process

A sprint (also known as iteration or timebox) is the basic unit of development in Scrum. The sprint
is a timeboxed effort; that is, the length is agreed and fixed in advance for each sprint and is
normally between one week and one month, with two weeks being the most common.[6]

Each sprint starts with a sprint planning event that establishes a sprint goal and the required
product backlog items. The team accepts what they agree is ready and translate this into a sprint
backlog, with a breakdown of the work required and an estimated forecast for the sprint goal.
Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to
stakeholders and identify lessons and improvements for the next sprints.[15]

Scrum emphasizes valuable, useful output at the end of the sprint that is really done. In the case of
software, this likely includes that the software has been fully integrated, tested and documented,
and is potentially releasable.[38]

Sprint planning

At the beginning of a sprint, the scrum team holds a sprint planning event[39] to:

Mutually discuss and agree on the scope of work that is intended to be done during that sprint

Select product backlog items that can be completed in one sprint

Prepare a sprint backlog that includes the work needed to complete the selected product backlog
items

Agree the sprint goal, a short description of what they are forecasting to deliver at the end of the
sprint.

The recommended duration is four hours for a two-week sprint (pro-rata for other sprint
durations) [18]

During the first half, the whole scrum team (development team, scrum master, and product
owner) selects the product backlog items they believe could be completed in that sprint
During the second half, the development team identifies the detailed work (tasks) required to
complete those product backlog items; resulting in a confirmed sprint backlog

As the detailed work is elaborated, some product backlog items may be split or put back into the
product backlog if the team no longer believes they can complete the required work in a single
sprint

Once the development team has prepared their sprint backlog, they forecast (usually by voting)
which tasks will be delivered within the sprint.

Daily scrum

A daily scrum in the computing room. This centralized location helps the team start on time.

Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:[40][6]

All members of the development team come prepared. The daily scrum:

starts precisely on time even if some development team members are missing

should happen at the same time and place every day

is limited (timeboxed) to fifteen minutes

Anyone is welcome, though only development team members should contribute.

During the daily scrum, each team member typically answers three questions:

What did I complete yesterday that contributed to the team meeting our sprint goal?

What do I plan to complete today to contribute to the team meeting our sprint goal?

Do I see any impediment that could prevent me or the team from meeting our sprint goal?

Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved
unfounded)[41] identified in the daily scrum should be captured by the scrum master and
displayed on the team's scrum board or on a shared risk board, with an agreed person designated
to working toward a resolution (outside of the daily scrum). While the currency of work status is
the whole team's responsibility, the scrum master often updates the sprint burndown chart.[42]
Where the team does not see the value in these events, it is the responsibility of the scrum master
to find out why.[43] This is part of the responsibility of educating the team and stakeholders about
the Scrum principles.[36]

No detailed discussions should happen during the daily scrum. Once the meeting ends, individual
members can get together to discuss issues in detail; such a meeting is sometimes known as a
'breakout session' or an 'after party'.[42]
Sprint review

At the end of a sprint, the team holds two events: the sprint review and the sprint retrospective.

At the sprint review, the team:

reviews the work that was completed and the planned work that was not completed

presents the completed work to the stakeholders (a.k.a. the demo)

collaborates with the stakeholders on what to work on next

Guidelines for sprint reviews:

Incomplete work cannot be demonstrated.

The recommended duration is two hours for a two-week sprint (proportional for other sprint-
durations).[18]

Sprint retrospective

At the sprint retrospective, the team:

reflects on the past sprint

identifies and agrees on continuous process improvement actions

Guidelines for sprint retrospectives:[citation needed]

Three main questions arise in the sprint retrospective:

What went well during the sprint?

What did not go well?

What could be improved for better productivity in the next sprint?

The recommended duration is one-and-a-half hours for a two-week sprint (proportional for other
sprint duration(s)).

The scrum master facilitates this event.

Backlog refinement
Backlog refinement (formerly called grooming) is the ongoing process of reviewing product
backlog items and checking that they are appropriately prepared and ordered in a way that makes
them clear and executable for teams once they enter sprints via the sprint planning activity.
Product backlog items may be broken into multiple smaller ones. Acceptance criteria may be
clarified. Dependencies may be identified and investigated.

Although not originally a core Scrum practice, backlog refinement has been added to the Scrum
Guide and adopted as a way of managing the quality of product backlog items entering a sprint,
with a recommended investment of up to 10% of a team's sprint capacity.[18][44]

The backlog can also include technical debt (also known as design debt or code debt). This is a
concept in software development that reflects the implied cost of additional rework caused by
choosing an easy solution now instead of using a better approach that would take longer.

Cancelling a sprint

The product owner can cancel a sprint if necessary.[18] The product owner may do so with input
from the team, scrum master or management. For instance, management may wish the product
owner to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is
abnormally terminated, the next step is to conduct a new sprint planning, where the reason for
the termination is reviewed.

Artifacts

This section needs additional citations for verification. Please help improve this article by adding
citations to reliable sources. Unsourced material may be challenged and removed. (March 2013)
(Learn how and when to remove this template message)

Product backlog

The product backlog is a breakdown of work to be done[45] and contains an ordered list of
product requirements that a scrum team maintains for a product. Common formats include user
stories and use cases.[38] The requirements define features, bug fixes, non-functional
requirements, etc.—whatever must be done to deliver a viable product. The product owner
prioritizes product backlog items (PBIs) based on considerations such as risk, business value,
dependencies, size, and date needed.

The product backlog is what will be delivered, ordered into the sequence in which it should be
delivered. It is visible to everyone but may only be changed with the consent of the product
owner, who is ultimately responsible for ordering product backlog items for the development
team to choose.

The product backlog contains the product owner's assessment of business value and the
development team's assessment of development effort, which are often, but not always, stated in
story points using the rounded Fibonacci scale. These estimates help the product owner to gauge
the timeline and may influence the ordering of product backlog items; for example, if two features
have the same business value, the product owner may schedule earlier delivery of the one with
the lower development effort (because the return on investment is higher) or the one with higher
development effort (because it is more complex or riskier, and they want to retire that risk earlier).
[46]

The product backlog and the business value of each product backlog item is the responsibility of
the product owner. The effort to deliver each item is estimated by the development team in story
points, or time. By estimating in story points, the team reduces the dependency in individual
developers; this is useful especially in dynamic teams where developers are often assigned to
other projects after sprint delivery. For instance, if a user story is estimated as a 5 in effort (using
Fibonacci sequence), it remains 5 regardless of how many developers are working on it

Story points define the effort in a time-box, so they do not change with time. For instance, in one
hour an individual can walk, run, or climb, but the effort expended is clearly different. The gap
progression between the terms in the Fibonacci sequence encourages the team to deliver carefully
considered estimates. Estimates of 1, 2 or 3 imply similar efforts (1 being trivial), but if the team
estimates an 8 or 13 (or higher), the impact on both delivery and budget can be significant. The
value of using story points is that the team can reuse them by comparing similar work from
previous sprints, but it should be recognized that estimates are relative to the team. For example,
an estimate of 5 for one team could be a 2 for another having senior developers and higher skills.

Every team should have a product owner, although in many instances a product owner could work
with more than one team.[27] The product owner is responsible for maximizing the value of the
product. The product owner gathers input and takes feedback from, and is lobbied by, many
people, but ultimately makes the call on what gets built.

The product backlog:

Captures requests to modify a product—including new features, replacing old features, removing
features, and fixing issues
Ensures the development team has work that maximizes business benefit to the product owner

Typically, the product owner and the scrum team work together to develop the breakdown of
work; this becomes the product backlog, which evolves as new information surfaces about the
product and about its customers, and so later sprints may address new work.

Management

A product backlog, in its simplest form, is merely a list of items to work on. Having well-established
rules about how work is added, removed and ordered helps the whole team make better decisions
about how to change the product.[47]

The product owner prioritizes product backlog items based on which are needed soonest. The
team then chooses which items they can complete in the coming sprint. On the scrum board, the
team moves items from the product backlog to the sprint backlog, which is the list of items they
will build. Conceptually, it is ideal for the team to only select what they think they can accomplish
from the top of the list, but it is not unusual to see in practice that teams are able to take lower-
priority items from the list along with the top ones selected. This normally happens because there
is time left within the sprint to accommodate more work. Items at the top of the backlog, the
items to work on first, should be broken down into stories that are suitable for the development
team to work on. The further down the backlog goes, the less refined the items should be. As
Schwaber and Beedle put it "The lower the priority, the less detail until you can barely make out
the backlog item."[6]

As the team works through the backlog, it must be assumed that change happens outside their
environment—the team can learn about new market opportunities to take advantage of,
competitor threats that arise, and feedback from customers that can change the way the product
was meant to work. All of these new ideas tend to trigger the team to adapt the backlog to
incorporate new knowledge. This is part of the fundamental mindset of an agile team. The world
changes, the backlog is never finished.[48]

Sprint backlog

A scrum task board

The sprint backlog is the list of work the development team must address during the next sprint.
[49] The list is derived by the scrum team progressively selecting product backlog items in priority
order from the top of the product backlog until they feel they have enough work to fill the sprint.
The development team should keep in mind its past performance assessing its capacity for the
new-sprint, and use this as a guideline of how much 'effort' they can complete.
The product backlog items may be broken down into tasks by the development team.[49] Tasks on
the sprint backlog are never assigned (or pushed) to team members by someone else; rather team
members sign up for (or pull) tasks as needed according to the backlog priority and their own skills
and capacity. This promotes self-organization of the development team and developer buy-in.

The sprint backlog is the property of the development team, and all included estimates are
provided by the development team. Often an accompanying task board is used to see and change
the state of the tasks of the current sprint, like to do, in progress and done.

Once a sprint backlog is committed, no additional work can be added to the sprint backlog except
by the team. Once a sprint has been delivered, the product backlog is analyzed and reprioritized if
necessary, and the next set of functionality is selected for the next sprint.

Increment

The increment is the potentially releasable output of the sprint that meets the sprint goal. It is
formed from all the completed sprint backlog items, integrated with the work of all previous
sprints. The increment must be complete, according to the scrum team's definition of done (DoD),
fully functioning, and in a usable condition regardless of whether the product owner decides to
actually deploy and use it.

Extensions

The following artifacts and techniques can be used to help people use Scrum.[18]

Sprint burndown chart

A sample burndown chart for a completed sprint, showing remaining effort at the end of each day.

Main article: Burn down chart

The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint
backlog.[50] Updated every day, it gives a simple view of the sprint progress. It also provides quick
visualizations for reference. The horizontal axis of the sprint burndown chart shows the days in a
sprint, while the vertical axis shows the amount of work remaining each day (typically representing
the estimate of hours of work remaining).
During sprint planning, the ideal burndown chart is plotted. Then, during the sprint, each member
picks up tasks from the sprint backlog and works on them. At the end of the day, they update the
remaining hours for tasks to be completed. In such a way, the actual burndown chart is updated
day by day.

It should not be confused with an earned value chart.

Release burn-up chart

A sample burn-up chart for a release, showing scope completed each sprint (MVP = Minimum
Viable Product)

The release burn-up chart is a way for the team to provide visibility and track progress toward a
release. Updated at the end of each sprint, it shows progress toward delivering a forecast scope.
The horizontal axis of the release burn-up chart shows the sprints in a release, while the vertical
axis shows the amount of work completed at the end of each sprint (typically representing
cumulative story points of work completed). Progress is plotted as a line that grows up to meet a
horizontal line that represents the forecast scope; often shown with a forecast, based on progress
to date, that indicates how much scope might be completed by a given release date or how many
sprints it will take to complete the given scope.

The release burn-up chart makes it easy to see how much work has been completed, how much
work has been added or removed (if the horizontal scope line moves), and how much work is left
to be done.

Definition of ready (DoR)

The start criteria to determine whether the specifications and inputs are set enough to start the
work item, i.e. a user story.

Definition of done (DoD)

The exit-criteria to determine whether a product backlog item is complete. In many cases, the DoD
requires that all regression tests be successful. The definition of done may vary from one scrum
team to another but must be consistent within one team.[51]

Velocity
The total effort a team is capable of in a sprint. The number is derived by evaluating the work
(typically in user story points) completed in the last sprint. The collection of historical velocity data
is a guideline for assisting the team in understanding how much work they can achieve.

Spike

A time-boxed period used to research a concept or create a simple prototype. Spikes can either be
planned to take place in between sprints or, for larger teams, a spike might be accepted as one of
many sprint delivery objectives. Spikes are often introduced before the delivery of large or
complex product backlog items in order to secure budget, expand knowledge, or produce a proof
of concept. The duration and objective(s) of a spike is agreed between product owner and
development team before the start. Unlike sprint commitments, spikes may or may not deliver
tangible, shippable, valuable functionality. For example, the objective of a spike might be to
successfully reach a decision on a course of action. The spike is over when the time is up, not
necessarily when the objective has been delivered.[52]

Tracer bullet

Also called a drone spike, a tracer bullet is a spike with the current architecture, current
technology set, current set of best practices that result in production quality code. It might just be
a very narrow implementation of the functionality but is not throwaway code. It is of production
quality, and the rest of the iterations can build on this code. The name has military origins as
ammunition that makes the path of the bullet visible, allowing for corrections. Often these
implementations are a 'quick shot' through all layers of an application, such as connecting a single
form's input field to the back-end, to prove the layers connect as expected.[53]

Limitations

The benefits of Scrum may be more difficult to achieve when:[54][55]

Teams whose members are geographically dispersed or part-time: In Scrum, developers should
have close and ongoing interaction, ideally working together in the same space most of the time.
While recent improvements in technology have reduced the impact of these barriers (e.g., being
able to collaborate on a digital whiteboard), the Agile manifesto asserts that the best
communication is face to face.[56]

Teams whose members have very specialized skills: In Scrum, developers should have T-shaped
skills, allowing them to work on tasks outside of their specialization. This can be encouraged by
good Scrum leadership. While team members with very specific skills can and do contribute well,
they should be encouraged to learn more about and collaborate with other disciplines.
Products with many external dependencies: In Scrum, dividing product development into short
sprints requires careful planning; external dependencies, such as user acceptance testing or
coordination with other teams, can lead to delays and the failure of individual sprints.

Products that are mature or legacy or with regulated quality control: In Scrum, product increments
should be fully developed and tested in a single sprint; products that need large amounts of
regression testing or safety testing (e.g., medical devices or vehicle control) for each release are
less suited to short sprints than to longer waterfall releases.

Tools for implementation

Main article: Comparison of Scrum software

Like other agile methods, effective adoption of Scrum can be supported through a wide range of
tools.

Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as
the sprint backlog. There are also open-source and proprietary software packages for Scrum—
which are either dedicated to product development using the Scrum framework or support
multiple product development approaches including Scrum.

Other organizations implement Scrum without software tools and maintain their artifacts in hard-
copy forms such as paper, whiteboards, and sticky notes.[57]

Scrum values

Scrum is a feedback-driven empirical approach which is, like all empirical process control,
underpinned by the three pillars of transparency, inspection, and adaptation. All work within the
Scrum framework should be visible to those responsible for the outcome: the process, the
workflow, progress, etc. In order to make these things visible, scrum teams need to frequently
inspect the product being developed and how well the team is working. With frequent inspection,
the team can spot when their work deviates outside of acceptable limits and adapt their process
or the product under development.[26]

These three pillars require trust and openness in the team, which the following five values of
Scrum enable:[18]

Commitment: Team members individually commit to achieving their team goals, each and every
sprint.

Courage: Team members know they have the courage to work through conflict and challenges
together so that they can do the right thing.
Focus: Team members focus exclusively on their team goals and the sprint backlog; there should
be no work done other than through their backlog.

Openness: Team members and their stakeholders agree to be transparent about their work and
any challenges they face.

Respect: Team members respect each other to be technically capable and to work with good
intent.

Adaptations

The hybridization of Scrum with other software development methodologies is common as Scrum
does not cover the whole product development lifecycle; therefore, organizations find the need to
add in additional processes to create a more comprehensive implementation. For example, at the
start of product development, organizations commonly add process guidance on the business
case, requirements gathering and prioritization, initial high-level design, and budget and schedule
forecasting.[58]

Various authors and communities of people who use Scrum have also suggested more detailed
techniques for how to apply or adapt Scrum to particular problems or organizations. Many refer to
these methodological techniques as 'patterns' - by analogy with design patterns in architecture
and software.[59][60]

Scrumban

Main article: Scrumban

Scrumban is a software production model based on Scrum and Kanban. Scrumban is especially
suited for product maintenance with frequent and unexpected work items, such as production
defects or programming errors. In such cases the time-limited sprints of the Scrum framework may
be perceived to be of less benefit, although Scrum's daily events and other practices can still be
applied, depending on the team and the situation at hand. Visualization of the work stages and
limitations for simultaneous unfinished work and defects are familiar from the Kanban model.
Using these methods, the team's workflow is directed in a way that allows for minimum
completion time for each work item or programming error, and on the other hand ensures each
team member is constantly employed.[61]

To illustrate each stage of work, teams working in the same space often use post-it notes or a large
whiteboard.[62] In the case of decentralized teams, stage-illustration software such as Assembla,
JIRA or Agilo can be used.

The major differences between Scrum and Kanban is that in Scrum work is divided into sprints that
last a fixed amount of time, whereas in Kanban the flow of work is continuous. This is visible in
work stage tables, which in Scrum are emptied after each sprint, whereas in Kanban all tasks are
marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban
makes specialized, functional teams possible.[61]

Scrum of scrums

The scrum of scrums is a technique to operate Scrum at scale, for multiple teams working on the
same product, allowing them to discuss progress on their interdependencies, focusing on how to
coordinate delivering software,[63] especially on areas of overlap and integration. Depending on
the cadence (timing) of the scrum of scrums, the relevant daily scrum for each scrum team ends by
designating one member as an ambassador to participate in the scrum of scrums with
ambassadors from other teams. Depending on the context, the ambassadors may be technical
contributors or each team's scrum master.[63]

Rather than simply a progress update, the scrum of scrums should focus on how teams are
collectively working to resolve, mitigate, or accept any risks, impediments, dependencies, and
assumptions (RIDAs) that have been identified. The scrum of scrums tracks these RIDAs via a
backlog of its own, such as a risk board (sometimes known as a ROAM board after the initials of
resolved, owned, accepted, and mitigated),[64] which typically leads to greater coordination and
collaboration between teams.[63]

This should run similar to a daily scrum, with each ambassador answering the following four
questions:[65]

What risks, impediments, dependencies, or assumptions has your team resolved since we last
met?

What risks, impediments, dependencies, or assumptions will your team resolve before we meet
again?

Are there any new risks, impediments, dependencies, or assumptions slowing your team down or
getting in their way?

Are you about to introduce a new risk, impediment, dependency, or assumption that will get in
another team's way?

As Jeff Sutherland commented,[63]

Since I originally defined the Scrum of Scrums (Ken Schwaber was at IDX working with me), I can
definitively say the Scrum of Scrums is not a 'meta Scrum'. The Scrum of Scrums as I have used it is
responsible for delivering the working software of all teams to the Definition of Done at the end of
the sprint, or for releases during the sprint. PatientKeeper delivered to production four times per
Sprint. Ancestry.com delivers to production 220 times per two-week Sprint. Hubspot delivers live
software 100-300 times a day. The Scrum of Scrums Master is held accountable for making this
work. So the Scrum of Scrums is an operational delivery mechanism.

Large-scale Scrum

Large-scale Scrum (LeSS) is a product development framework that extends Scrum with scaling
rules and guidelines without losing the original purposes of Scrum.

There are two levels to the framework: the first LeSS level is designed for up to eight teams; the
second level, known as 'LeSS Huge', introduces additional scaling elements for development with
up to hundreds of developers. "Scaling Scrum starts with understanding and being able to adopt
standard real one-team Scrum. Large-scale Scrum requires examining the purpose of single-team
Scrum elements and figuring out how to reach the same purpose while staying within the
constraints of the standard Scrum rules."[66]

Bas Vodde and Craig Larman evolved the LeSS framework from their experiences working with
large-scale product development, especially in the telecoms and finance industries. It evolved by
taking Scrum and trying many different experiments to discover what works. In 2013, the
experiments were solidified into the LeSS framework rules.[67] The intention of LeSS is to 'descale'
organization complexity, dissolving unnecessary complex organizational solutions, and solving
them in simpler ways. Less roles, less management, less organizational structures.[68]

Limitations

The benefits of Scrum may be more difficult to achieve when:[54][55]

Teams whose members are geographically dispersed or part-time: In Scrum, developers should
have close and ongoing interaction, ideally working together in the same space most of the time.
While recent improvements in technology have reduced the impact of these barriers (e.g., being
able to collaborate on a digital whiteboard), the Agile manifesto asserts that the best
communication is face to face.[56]

Teams whose members have very specialized skills: In Scrum, developers should have T-shaped
skills, allowing them to work on tasks outside of their specialization. This can be encouraged by
good Scrum leadership. While team members with very specific skills can and do contribute well,
they should be encouraged to learn more about and collaborate with other disciplines.

Products with many external dependencies: In Scrum, dividing product development into short
sprints requires careful planning; external dependencies, such as user acceptance testing or
coordination with other teams, can lead to delays and the failure of individual sprints.
Products that are mature or legacy or with regulated quality control: In Scrum, product increments
should be fully developed and tested in a single sprint; products that need large amounts of
regression testing or safety testing (e.g., medical devices or vehicle control) for each release are
less suited to short sprints than to longer waterfall releases.

Tools for implementation

Main article: Comparison of Scrum software

Like other agile methods, effective adoption of Scrum can be supported through a wide range of
tools.

Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as
the sprint backlog. There are also open-source and proprietary software packages for Scrum—
which are either dedicated to product development using the Scrum framework or support
multiple product development approaches including Scrum.

Other organizations implement Scrum without software tools and maintain their artifacts in hard-
copy forms such as paper, whiteboards, and sticky notes.[57]

Scrum values

Scrum is a feedback-driven empirical approach which is, like all empirical process control,
underpinned by the three pillars of transparency, inspection, and adaptation. All work within the
Scrum framework should be visible to those responsible for the outcome: the process, the
workflow, progress, etc. In order to make these things visible, scrum teams need to frequently
inspect the product being developed and how well the team is working. With frequent inspection,
the team can spot when their work deviates outside of acceptable limits and adapt their process
or the product under development.[26]

These three pillars require trust and openness in the team, which the following five values of
Scrum enable:[18]

Commitment: Team members individually commit to achieving their team goals, each and every
sprint.

Courage: Team members know they have the courage to work through conflict and challenges
together so that they can do the right thing.

Focus: Team members focus exclusively on their team goals and the sprint backlog; there should
be no work done other than through their backlog.
Openness: Team members and their stakeholders agree to be transparent about their work and
any challenges they face.

Respect: Team members respect each other to be technically capable and to work with good
intent.

Adaptations

The hybridization of Scrum with other software development methodologies is common as Scrum
does not cover the whole product development lifecycle; therefore, organizations find the need to
add in additional processes to create a more comprehensive implementation. For example, at the
start of product development, organizations commonly add process guidance on the business
case, requirements gathering and prioritization, initial high-level design, and budget and schedule
forecasting.[58]

Various authors and communities of people who use Scrum have also suggested more detailed
techniques for how to apply or adapt Scrum to particular problems or organizations. Many refer to
these methodological techniques as 'patterns' - by analogy with design patterns in architecture
and software.[59][60]

Scrumban

Main article: Scrumban

Scrumban is a software production model based on Scrum and Kanban. Scrumban is especially
suited for product maintenance with frequent and unexpected work items, such as production
defects or programming errors. In such cases the time-limited sprints of the Scrum framework may
be perceived to be of less benefit, although Scrum's daily events and other practices can still be
applied, depending on the team and the situation at hand. Visualization of the work stages and
limitations for simultaneous unfinished work and defects are familiar from the Kanban model.
Using these methods, the team's workflow is directed in a way that allows for minimum
completion time for each work item or programming error, and on the other hand ensures each
team member is constantly employed.[61]

To illustrate each stage of work, teams working in the same space often use post-it notes or a large
whiteboard.[62] In the case of decentralized teams, stage-illustration software such as Assembla,
JIRA or Agilo can be used.

The major differences between Scrum and Kanban is that in Scrum work is divided into sprints that
last a fixed amount of time, whereas in Kanban the flow of work is continuous. This is visible in
work stage tables, which in Scrum are emptied after each sprint, whereas in Kanban all tasks are
marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban
makes specialized, functional teams possible.[61]

Scrum of scrums

The scrum of scrums is a technique to operate Scrum at scale, for multiple teams working on the
same product, allowing them to discuss progress on their interdependencies, focusing on how to
coordinate delivering software,[63] especially on areas of overlap and integration. Depending on
the cadence (timing) of the scrum of scrums, the relevant daily scrum for each scrum team ends by
designating one member as an ambassador to participate in the scrum of scrums with
ambassadors from other teams. Depending on the context, the ambassadors may be technical
contributors or each team's scrum master.[63]

Rather than simply a progress update, the scrum of scrums should focus on how teams are
collectively working to resolve, mitigate, or accept any risks, impediments, dependencies, and
assumptions (RIDAs) that have been identified. The scrum of scrums tracks these RIDAs via a
backlog of its own, such as a risk board (sometimes known as a ROAM board after the initials of
resolved, owned, accepted, and mitigated),[64] which typically leads to greater coordination and
collaboration between teams.[63]

This should run similar to a daily scrum, with each ambassador answering the following four
questions:[65]

What risks, impediments, dependencies, or assumptions has your team resolved since we last
met?

What risks, impediments, dependencies, or assumptions will your team resolve before we meet
again?

Are there any new risks, impediments, dependencies, or assumptions slowing your team down or
getting in their way?

Are you about to introduce a new risk, impediment, dependency, or assumption that will get in
another team's way?

As Jeff Sutherland commented,[63]

Since I originally defined the Scrum of Scrums (Ken Schwaber was at IDX working with me), I can
definitively say the Scrum of Scrums is not a 'meta Scrum'. The Scrum of Scrums as I have used it is
responsible for delivering the working software of all teams to the Definition of Done at the end of
the sprint, or for releases during the sprint. PatientKeeper delivered to production four times per
Sprint. Ancestry.com delivers to production 220 times per two-week Sprint. Hubspot delivers live
software 100-300 times a day. The Scrum of Scrums Master is held accountable for making this
work. So the Scrum of Scrums is an operational delivery mechanism.

Large-scale Scrum

Large-scale Scrum (LeSS) is a product development framework that extends Scrum with scaling
rules and guidelines without losing the original purposes of Scrum.

There are two levels to the framework: the first LeSS level is designed for up to eight teams; the
second level, known as 'LeSS Huge', introduces additional scaling elements for development with
up to hundreds of developers. "Scaling Scrum starts with understanding and being able to adopt
standard real one-team Scrum. Large-scale Scrum requires examining the purpose of single-team
Scrum elements and figuring out how to reach the same purpose while staying within the
constraints of the standard Scrum rules."[66]

Bas Vodde and Craig Larman evolved the LeSS framework from their experiences working with
large-scale product development, especially in the telecoms and finance industries. It evolved by
taking Scrum and trying many different experiments to discover what works. In 2013, the
experiments were solidified into the LeSS framework rules.[67] The intention of LeSS is to 'descale'
organization complexity, dissolving unnecessary complex organizational solutions, and solving
them in simpler ways. Less roles, less management, less organizational structures.[68]

Criticisms

Ceremonial Scrum meetings have been reported to be hurting productivity and wasting time that
could be better spent on actual productive tasks.[69][70]

Scrum practices, when not correctly implemented in the spirit of the Agile Manifesto, have a
tendency to become a form of micromanagement.[71]

Scrum also assumes that the amount of effort required for completing certain tasks can be
accurately quantified using metrics, although most of the time this can be quite unpredictable.
[72]

1.2.2 Proof Agile Works Summary Points

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)
o One of the most powerful super computers
o Strung 2 million miles of cable to connect PlayStation 3 gaming
consoles (PS3s)
o Modular enough to be loaded into a spy plane to process images
in-flight
o Reduced aerial imagery processing from days to seconds
 NASA's Faster Better Cheaper Initiative - reduced scope and size of spacecraft
(Lean/Agile Release Designs)
o Major initiative in the 1990s
o Costs were one-tenth the current cost of producing spacecraft
o Achieved unheard of results by reusing old spacecraft designs
o Stardust Mission - slung shot around the earth and sun to
catchup and capture dust from a comet
o Shoemaker - asteroid surveillance mission that landed on the
asteroid to retrieve high-density readings
o Missions were achieved under budget and on schedule, returning
10X the value of traditional NASA projects
Some of the best examples of proof that Agile works come from the basis for these books:

Critical Chain
Author: Eliyahu Goldratt

Publication date: 4 September 1997

ISBN 0-88427-153-6 (first edition, paperback)

Critical Chain explores the basis for delays that have historically plagued the delivery of projects
using traditional management methods. The basis for examination in the book is the success of
Skunkworks and their ability to deliver new, ground-breaking technology in less than a year. This
book focuses on U-2 instead of the P-80 shooting star, but the ideas are the same. We can do
better, and Skunkworks shows us a repeatable method to emulate.

F.I.R.E - How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation

Author: Dan Ward

Publisher: HarperBusiness; 1 edition (April 29, 2014)

Publication Date: April 29, 2014

ASIN: B00FJ3A6FC

F.I.R.E is a wonderful book that captures many ideas, stories, and principles. It's one of the books
that shows how throughout history, from WWII to the turn of the 21st century there are standout
projects and methods that emphasize the reduction of scope. This book focuses on all aspects of
systems development, from Portfolio Management to Program and Project Management.

One of the crucial examples of this book are the Faster, Better, Cheaper (FBC) initiatives that we
discuss in this lesson. It's incredible to learn their details through Dan Ward's fun, engaging style.
Filled with amazing Sci-Fi and unbelievable real-life examples - it's a must read (just not required
for this course).

Proof of Agile

Many people believe that Agile is a new approach born of software that is taking
the world by storm quickly, out of nowhere. However, like many overnight
successes the real work to develop Agile goes even farther back than you might
expect!

Agile's roots are as deep as Traditional Management, with the origins strongly
rooted in WWII. However, modern history of management offers some great stories
and insights into why Agile is culminating in today's fast-paced, information-driven
world.
So, Why Agile? The answers are its origins, and you probably know a few of these
techniques already.

Get ready to open yourself up to the idea that Agile is not new, it's society's  
pressure for performance forcing us to take a new look at how we govern our work
and ourselves!

1.3.2 Evolution of Agile Summary Points

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:
http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en
 
The original paper from Winston Royce on Waterfall Methodology: 
Winston W. Royce (1970). "Managing the Development of Large Software Systems" in:
Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los
Angeles, USA
Iterative Methods
 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 (see the details of the survey
here http://www.ambysoft.com/surveys/success2013.html):

 Agile is more successful than Traditional

 Agile is less challenged than Traditional

  Agile fails less than half as often as Traditional

Note: This table is reproduced from the summary

Project Agile Traditional graphics of Ambysoft's survey found
Measure here: https://clearcode.cc/blog/agile-vs-
waterfall-method/
Successful 64% 49%

Challenge 28% 33%

d

Failing 8% 18%
These sites each offer additional insights
into the methods mentioned in this class:

 Extreme Programming
(XP): https://en.wikipedia.org/wiki/Extreme_programming

 Rapid Application Development

(RAD): https://en.wikipedia.org/wiki/Rapid_application_developme
nt

 Dynamic Systems Development Methodology

(DSDM): https://en.wikipedia.org/wiki/Dynamic_systems_developm
ent_method

The basis for comparative performance of Agile and Traditional comes from these
sources:

 http://www.se-rwth.de/~rumpe/publications/Quantitative-
Survey-on-Extreme-Programming-Projects.pdf

 http://www.drdobbs.com/architecture-and-design/2010-it-
project-success-rates/226500046

 http://clearcode.cc/2014/12/agile-vs-waterfall-method/

 http://www.ambysoft.com/surveys/success2007.html

References for the "Lean Revolution" in management on Total Quality

Management (TQM), Toyota Production System (TPS), and Theory of Constraints
(TOC):

 https://en.wikipedia.org/wiki/Lean_manufacturing
  http://www.leanproduction.com/theory-of-constraints.html

 https://en.wikipedia.org/wiki/Toyota_Production_System

 http://www.industryweek.com/companies-amp-
executives/theory-constraints-tapped-accelerate-bps-gulf-
mexico-cleanup

 http://www.manufacturingglobal.com/top10/38/Top-10:-Lean-
manufacturing-companies-in-the-world

 http://www.forwardfocusinc.com/jumpstart-change/the-
importance-of-empowering-employees/

 https://www.bloomberg.com/news/articles/2013-09-19/forget-
employee-engagement-u-dot-s-dot-companies-need-
passionate-workers

 http://www.skymark.com/resources/leaders/deming.asp

 https://en.wikipedia.org/wiki/W._Edwards_Deming

 Womack, James P.; Daniel T. Jones (2003). Lean Thinking.

Free Press. p. 352.

1.4.0 Prep for Netflix Case Study

The Netflix Case Study is an example of how speed, innovation, and leadership all
drove a new form of controlling success at scale.

Netflix was smart enough to know that there was no guarantee in the new world of
online streaming video when it came to infrastructure or applications. The needs
were changing fast and the demand was growing faster.

As a result, Netflix underwent a dramatic transformation to become a new beacon

for the Cloud-Based Software-as-a-Service (SaaS) company. The following case
study dives into their transformation to become truly democratized and Agile in
their approach to engineering software at scale. Even today, most companies are
still striving to achieve what Netflix accomplished almost have a decade ago.

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.0 Prep for 18F Case Study

Bookmark this page

The 18F Case Study is a shining example of how Agile can drag you from the
dredges totally stuck Waterfall process. 
Imagine spending a decade in a paper design process. Now imagine the system
stuck in design is one that will enable better case management for children in need
of social services.

This example of government agencies adopting Agile to benefit society shows how
even the government is seeing the need to ditch the documents, and start
delivering with Agile

Agile in Government: GSA's 18F Delivers!

The California Social Services group needed an application for case management
of child welfare sercices. 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 Scoial Servics 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

You can learn more about the techniques used by 18F

here:  https://modularcontracting.18f.gov/strategies/

You can also see the blog of successful 18F modular contracting stories
here: https://18f.gsa.gov/tags/modular-contracting/
And you should take time to watch this video of Kevin Gaines, from Digital Services
director at the Child Welfare Digital Services for California.  Listen to his story
here: CWDS Digital Services Director Kevin Gaines Discusses Project's Progress.

 Applied Scrum for Agile Project Management - Learn the project

management processes, roles, mechanics, and philosophies behind Scrum, the
simplest and most pure approach to managing work at the team level.

 Sprint Planning for Faster Agile Team Delivery - Learn how to drive
speed into any project by selecting and limiting work-in-progress through
agile planning and task management.

 Agile Innovation and Problem Solving Skills - Learn how to deliver

greater value through Agile solution targeting and theory of constraints that
unleash your team’s innovative potential.

 Agile Leadership Principles and Practices - Accelerate and improve

team decisions by learning Agile’s facilitating leadership principles to
unleash team productivity, motivation, and problem solving.

 Agile Process, Project, and Program Controls - Learn Agile controls that
get work done with confidence by using true transparency (actuals not
estimates) and continuous improvement to ensure your people, process,
and products deliver valuable, working solutions.

2.0.0 Goals and Objectives of Week 2

Where is Agile employed and how do we know they are truly Agile?

Do you think you're Agile? Do you know where Agile might be employed with
success?

To Answer these questions we'll get into the foundational things you'll need to
know about what differentiates Agile in the workplace. These include:

 What are the Project Management Methods (Traditional, Agile, Lean)?

 How do they differ in managing a projects resource constraints?

With those essentials understood we'll dive deeper into the reasoning that Agile
and the other methods are used today. These include diving into three primary
areas of concern:

 Industries - comparing where methods fit best today

  Customers - how their demands and availability drive PM method selection
 Engineering - when the engineering is forced to be linear, modular, or
evolutionary

In many ways, we'll be exploring the world of work. By the end of this lesson you'll
see clearly why industries are organized the way they are today; and what the
limitations and benefits are for picking a PM Method that best fits your work in
context and scale.

Stay curious, and enjoy the journey on Week 2 of Applied Scrum!

2.1.0 Prep for Simple PM Methods

Have you ever wondered - where did my project come from?

This lesson will give you the high-level understanding to know the source and
reasoning for projects across each Project Management method. If there was one
course that captured the "cheat sheet" of Project Management, it would be this
one.

As you go through this next lesson, think about:

 Which of these processes are you involved in?

 Does your organization get involved in the full project lifecycle?

 Are you aware of how your project is paid for, and the benefits that
spur the investment?

 What happens when your project is done? What is done?

The project lifecycle is similar to all project types, but there are some clear differences that
are apparent right away when you consider each method and its goals:

 Traditional aims for Predictability

 Agile aims for Speed

 Lean aims for Innovation

Which aim would suit you best in your workplace? 

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
 Bid & 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
 Operations - the use of the product to produce benefits to the organization
 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) precedes Bid & Proposal Stages

Planning Readiness Review (PRR)  precedes Requirements phase

Requirements Readiness Review precedes Design phase, exits Requirements phase

(RRR)

Design Readiness Review (DRR) precedes Implementation phase, exits Design phase

Implementation Readiness Review precedes Verification phase, exits Implementation phase

(IRR)

Operational Readiness Review precedes Maintenance (O&M) phase, exits Verification phase
(ORR)

Operations and Maintenance Precedes Disposal phase, exits Operations (O&M)

Review (OMR)

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)
Most of these "Simple PM Methods" are the abstraction of the standard project
lifecycle.

However, a couple of extended readings that helped in building these diagrams,

include:

 Stage Gates and Waterfall

 Primary Source was CDC's Stage Gate

Governance
Process: https://www2.cdc.gov/cdcup/library/hhs
_eplc/56%20-%20Stage%20Gate
 %20Reviews/EPLC_Stage_Gate_Reviews_Pract
ices_Guide.pdf

 Backup Sources:

 https://en.wikipedia.org/wiki/Phase-
gate_process

 https://www.stage-gate.com/stage-gate-
model/

 Agile Project Management:

 Scrum: www.scrumalliance.org and scrum.org

 SAFe: www.scaledagileframework.org

 DAD: www.disciplinedagiledelivery.com

 Lean Project Management:

 https://www.lean.org/WhatsLean/

 https://blog.capterra.com/the-ultimate-guide-to-lean-
project-management/

2.2.0 Prep for Approaching the Triple Cost Constraint

Understanding WHO uses agile can also be done by looking at the techniques for
addressing project constraints.

How do you keep a project on task, time, and total cost? Is that really the goal?

 Agile projects the answer the goal is to deliver early

something of value, before time is up (varied scope). 

 Traditional says yes! Fixing scope, schedule, and

monitoring performance to manage the budget (varied
budget or cost or profit).

 Lean focuses on meeting a service levels with fixed

resources, changing what gets delivered first by the
need and impact (varied schedule). 
Each Method has it's goals, but it also has it's paradigms of managing against the
goal. The result can be very different and similar means of managing each
element:

 Scope - WBS, CCB, Backlogs, Tickets

 Schedule - CPM, PERT, Timeboxes, Severity Levels

 Budget - EVM, ROI, Burndowns, and KPIs

What techniques do you employ? Do you understand their connectivity? Are you
meeting the goal?

Enjoy the exploring these techniques across each PM Method. Think what makes
most sense to you, and what intrigues you as perhaps a better way!

2.2.2 Approaching the Triple Cost Constraint Summary

Points
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.2.4 Approaching the Triple Cost Constraint
References
Interesting Resources to extend your learning:

 Basics of the Program Evaluation and Review Technique

(PERT): https://en.wikipedia.org/wiki/Program_evaluation_and
_review_technique

 Basics of Critical Path Method

(CPM): https://en.wikipedia.org/wiki/Critical_path_method

 Good, simple reference on Earned Value Management

(EVM): https://www.e-education.psu.edu/geog871/l6_p6.html

 Interesting discussion that blends PERT's six-point estimate

and Burndown charts: https://codetiburon.com/manage-cost-
time-agile-software-project/

 Good discussion of Lean Performance

Management: https://bsm.ie/blog/adrian-fegan/understanding-
service-level-agreements-lean-projects

2.3.0 Prep for Comparing Methods Across Industries

Industries have gravitated towards project management methods over time.

What appears most obvious when looking across these industries is that they
naturally group by size and PM method of choice.

Consolidate your understanding so far and think deeper on these industries:

 What are the Goals of the Industry?

 What about Planning Methods?

 How and why do these Industries source their vendors?

This is a topic we've covered a lot in great detail, but the new dimension of the
Industry begins to open a question: is it all about size? What kind of size or scale
matters in these industries to drive them towards one PM Method or another?

Enjoy this new layer of understanding work and answering the question, "Who
Uses Agile, Why?"

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

Military

Government / Policy

Relocation

Information Technology

Product Development

Consulting

Operations

Sales
Customer Support

Legal

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

Many departments

Many technologies and concerns

Good Examples are

Large building construction

Military platform acquisition

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

Building new products

Ex. SpaceX used modular designs to launch many types of rockets

Ex. Apple Operating Systems with regular releases over time (incrementally better)

Planning is done in Releases

Goal is to get out to market

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

Building a new solar panel

Selling or closing a deal

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

Setting up a process (e.g. To-Do, Doing, Done)

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.
The 4 basic principles of the Kanban Method
David J. Anderson (recognized as the thought leader for the adoption of
Lean/Kanban for knowledge work) formulated the Kanban method as an approach
to the evolutionary and incremental process and systems change for work
organizations. The method is focused on carrying out the tasks at hand and the
most important principles can be divided into four basic principles and six
practices.
Principle 1: Start with what you do now
Kanban requires no configuration and can be applied to real workflows or active
processes to identify problems. That's why it's easy to implement Kanban in any
type of organization, since no drastic changes are required.
Principle 2: Commit to Seek and Implement Incremental and Evolutionary Change
The Kanban method is designed to be implemented with minimal resistance, so it
deals with small and continuous incremental and evolutionary changes of the
current process. In general, radical changes are not considered, as they are usually
met with resistance due to fear or uncertainty of the process.
Principle 3: Respect current processes, responsibilities and positions
Kanban recognizes that existing processes, roles, responsibilities and positions can
have value and are worth keeping. The Kanban method does not prohibit change,
but neither does it prescribe it. It encourages incremental change, as it does not
provoke so much fear as to slow down progress.
Principle 4: Encourage leadership at all levels
This is the newest principle of Kanban. Some of the best leadership comes from the
day-to-day actions of the people who lead their teams. It is important that everyone
promotes a continuous improvement (Kaizen) mentality to achieve optimal
performance at the team/department/company level. This cannot be a
management level activity.
The Six Kanban Practices
While accepting the Kanban philosophy and embarking on the transition journey is
the most important step, every organization must be careful about the practical
steps. There are six core practices identified by David J. Anderson that must be in
place for successful implementation.
Visualize Workflow
The first and most important thing for you is to understand what it takes to get a
product from order to delivery. Only after you understand how the workflow
currently works, can you hope to improve it by making the necessary adjustments.
To visualize your process in Kanban, you will need a board with cards and columns.
Each column on the board represents a step in your workflow. Each kanban board
represents an element of your workflow.
When you start working on element X, you drag it to the "To Do" column and when
the element is finished, you move it to the "Done" column. This way, you can easily
follow the progress and detect bottlenecks.
Eliminate interruptions
Changing focus can seriously damage your process and multitasking could lead to
waste generation. This is why, the second Kanban practice focuses on setting the
limits of the work in process (the WIP limits). If there are no work-in-progress
limits, you are not doing kanban.
Limiting work in process (WIP) means that a pull system is applied on parts or all
of the workflow. Setting a maximum number of items per step ensures that a card
is "pulled" to the next step only when there is capacity available. Such restrictions
will quickly illuminate problem areas in your flow so you can identify and resolve
them.
Managing the flow
The idea of implementing a Kanban system is to create a continuous and
uninterrupted flow. By flow we mean the movement of work elements through the
production process. What is of interest is the speed and continuity of movement.
Ideally, we want a fast and uninterrupted flow. This would mean that our system is
creating value quickly. That is, minimizing the risk and avoiding the cost of delay,
but also doing so in a predictable manner.
Make policies explicit (Encourage visibility)
You can't improve something that you don't understand. This is why the process
must be well defined, published and promoted. People would not associate or
participate in something they do not believe is useful.
When everyone is familiar with the common goal, they will be able to work and
make decisions regarding changes that will move them in a positive direction.
Feedback loops
For positive change to occur, succeed and last, one more thing needs to be done.
The Lean philosophy admits that regular meetings are necessary for knowledge
transfer (feedback loops)
Make policies explicit (Promote visibility)
You can't improve something that you don't understand. This is why the process
must be well defined, published and promoted. People would not associate or
participate in something they do not believe is useful.
When everyone is familiar with the common goal, they will be able to work and
make decisions regarding changes that will move them in a positive direction.
Feedback loops
For positive change to occur, succeed and last, one more thing needs to be done.
The Lean philosophy recognizes that regular meetings are necessary for knowledge
transfer (feedback loops).
Such are the daily standing meetings to synchronize the team. They are held in
front of the Kanban board and each member shares with the others what he or she
did the day before and what he or she will do today.
There are also meetings for service delivery review, operations review and risk
review. Their frequency depends on many factors, but the idea is that they should
be regular, at a strictly fixed time, straight to the point and never unnecessarily
long.
The ideal average length of a standing meeting should be between 10 and 15
minutes, and other meetings can last up to an hour, depending on the size of the
team and the topics.
Improving collaboration (using models and the scientific method)
The way to achieve continuous improvement and sustainable change within an
organization is through a shared vision for a better future and a collective
understanding of the problems to be overcome.
Teams that have a shared understanding of work theories, workflow, process, and
risk are more likely to create a shared understanding of a problem and suggest
improvement actions that can be agreed upon by consensus.
Advantages of Kanban Tools
With the development of technology, Kanban is also continuously improving.
Kanban digital board solutions have been developed to overcome the problems that
arise in remote equipment.
Most large companies and especially startups have many remote employees. The
teams are often distributed all over the world.
They cannot work on a single physical board and therefore need a digital one that
they can access from anywhere. Cloud-based Kanban dashboards are the most
effective way to get everyone on the same line, as they provide access to all
information from any device, at any time and show live actions.
In addition, Kanban software enables a sophisticated analytical process to help you
track performance in detail, detect bottlenecks and implement necessary changes.
Kanban digital dashboards are also easy to integrate with other systems and can
provide valuable insight into the entire process, saving time and increasing
efficiency.
Kanban at a Glance
Kanban is more than just sticky notes on the wall. The easiest way to understand
Kanban is to accept its philosophy and then apply it to your daily work. If you read
and understand the four basic principles, the practical transition will seem logical
and even inevitable.
Visualizing the workflow, setting the boundaries of work in progress (WIP),
managing the flow, ensuring explicit policies and collaborative improvement will
take your process far beyond what you can imagine. Remember to organize regular
feedback loops and the set of all these pieces will reveal the true power of Kanban.
As you are now embarking on a journey towards understanding Kanban, this is
only the beginning. To gain a deeper understanding of Kanban, explore the
strengths of Kanban boards, WIP limits and Kanban cards.
In Summary
Trying to learn what Kanban is might be difficult at first, but now when you know
what it is, you can take full advantage of the main benefits of Kanban:
Physical and digital Kanban boards help you visualize your work
Kanban is easy to adopt: just start with what you have
WIP limits allow you to be more efficient.
Advantages kanban:
1. Kanban is a very simple and easy to understand system that makes it practical
for the management of a company to apply this system effectively.
2. The main advantage of applying the kanban system is a direct reduction in the
costs and wastage of the company. Kanban system improves the flow and
management of inventory by directly assisting the company to pursue the
company’s existing systems i.e. just in time (JIT) and make to order etc. which
reduces carrying or holding costs and makes sure smoother running of
inventories.
3. Kanban system advocates continuous and sustainable improvements in the
production systems of the company. Kanban not only consist of manual
guidelines or cards but also visualizations of the process outputs which makes
the review of work easier. This could also highlight other potential problematic
areas where additional attention is needed.
4. Kanban system is a very responsive system and does not promote any lags or
delays. As the tasks are continuously shifted between the columns of the
kanban cards, it automatically highlights the areas where any limiting factors
are raised that could hold up the overall output which can be responded to as
soon as possible by shifting and switching the resources from the other tasks.
5. Kanban enhances the effectiveness of human resource of a company. As the
system requires an on-going training, learning and improvement in the
competency levels of the employees. The employees are likely to retain their
experiences in long run. Additionally, kanban system is usually applied in team
situations which harbor a sense of shared responsibility and harmony among
the employees. This enhances their decision making capabilities and raise
prospects of innovation.
Disadvantages of kanban:
1. Kanban cannot be used as an independent tool. It is not a methodology that
could be applied solely rather it can be merged with other processes and
systems of a company like JIT, make to order and scrum etc. making these
systems more visible.
2. As the tasks are continuously shifted between the columns of kanban board,
the prediction of specific timelines for completion of tasks or activities becomes
difficult. This is because kanban acts only as a signaling port in a pull
production system.
3. Kanban is not suitable for the environments that are dynamic in nature.
Because a kanban system assumes the plans that are stable and consistent to
a certain extent, it may become ineffective in industries where the activities are
not static.
4. Kanban will become very difficult to apply if too much activities or tasks are
interrelated in a system. This is because such systems enhance the possibility
 of transfers of goods and expertise amongst different tasks too often and
increases difficulty to keep the pace of all these activities.
5. The implementation of the system may result in poor quality outputs. Kanban
acts like a monitoring structure that makes the flow of tasks smoother. If any
work done is unsatisfactory for the costumer or the company, it would require a
rework that could worsen the situation as it will require more time and
resources to get completed.
6. 2.4.0 Prep for Comparing Methods of Customer
Management
7. We've already seen the correlation between size and the choice of PM
Method, but what drives the size of a project?

8. Many would say the product itself, but in reality most projects are a result of
one prime factor: the customer.

9. How many customers one project has, our means of communication with
them, and the way we are compensated drives many choices in the
management of projects.

10. Many project managers start as either architects, engineers, technicians, or

designers - creative types - that gradually take on more responsibility. It's
natural to think our products drive these choices. But our reality reminds us
that no product is worth more than someone will pay for it; and the customer
has to accept the work before payment!

11. So, time to switch gears and put the customer first in your mind as you
consider which method fits best!

  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 R&D

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

Customer Representatives Part of the Team On-Call

Communication Large, Facilitated Small Meetings Ticketing / Request
Meetings
Payment Method Firm Fixed Price / Time & Materials / Cost-Plus /
Custom Pricing Retail Purchase (Paid) Subscription (SLA)
(Quote)

12. Enjoy the lesson (we'll come back to products soon enough)!

 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).

2.5.0 Comparing Methods of Engineering Management

Depending on the method of Project Management (PM) selected our goals in
Engineering design change. What does that mean for the Project Manager?
Everything, if you're being held accountable for successful delivery!

We sometimes see the product as driving PM Method choice, but this is rarely the
case. The Customer (s) type, availability, and total number of stakeholders drive
the management method. The work must meet those demands, based on the
goals set. 

 Traditional must be efficient in design

 Agile must release early and maximize value with iterative

releases
  Lean must be responsive and provide services or products
based on client priorities

To do this results in very different design paradigms, coupling of services, and

resultant architectures. This lesson will explore those together, along with the
Engineering Team makeup that also derives from the PM method choice. This
forces new design, development, integration, and testing concerns on the
creators. 

Can you imagine how the Project Management method would bind or release your
creativity? What about getting feedback on your designs? What about acceptance?

Enjoy this lesson as you explore the stark differences each method produces in
what's under-the-hood in your final delivery!

Important Note Before You Go:

 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
(e.g. a new car from the dealership) 

 Feature - an aspect of an Application that

delivers value to its customers
(e.g. automatic air conditioning)

 Service  - a set of functions that serve a

common purpose 
(e.g. air sensor system, air cooling system, air
heating system, ventilation)