Johanna Rothman

Part II

Design and Manage an Agile and Lean Project

Chapter 5

Start Your Agile Project Right

Copyright © 2017

Start you Agile project right…

• Projects need direction… teams need to know where

they are “headed” and how do know when they are

“done”

• When teams use agile approaches… value should be

seen at the end of each iteration

Agile approaches allow for release of observable interim

value at the end of each sprint

Why “Charter your project…”

The Charter should provides the understanding of why

… a prescribed set of features are to be “delivered”

and…

… how to know when the project done … the Release

Criteria

Start the project with the project Vision, the Release

Criteria, and the Product Backlog

Rothman

I have a question I ask of all parts of an agile project:

How little can we do to satisfy our needs?

“How little” thinking” is needed

The backlog, the feature set, and any up-front work

How the product is to evolve is key… not a pretense of

a plan for how the product will evolve.

The two parts: Project Vision and Release Criteria

Project Vision

Short but specific… one to three line statement

What the “Product Owner” want the project to provide at the

end of each release

(assumes that there will be multiple release prior to the final release)

Examples (“useful but not compelling”):

• Improvement of performance in three scenarios by a

minimum of 10%

• Adds email functionality

• Changes the UI across the product to our new standard

Project Vision

Short but specific… one to three line statement

What the “Product Owner” want the project to provide at the

end of each release

(assumes that there will be multiple release prior to the final release)

Examples (“useful but more compelling):

• Who is the main recipient of the project’s outcome?

• What can the main recipient do with that outcome?

• What is the vale to the main recipient?

https://www.scrumalliance.org/community/articles/2009/january/the-product-vision

Develop the Release Criteria

that is … the definition of what “DONE” means!

“We can end when there is no more value in the Product

Backlog” … but instead of focusing on having no more

value in the Backlog…

The Product Owner (the customer representative) can

receive more value when “users” can use the product

and then provide feedback.

Type of Scenario Example Description

Performance For a given scenario (describe it in some way), the query

returns results in minimum of two seconds

Reliability The system maintains uptime under these conditions.

Scalability The system is able to build up to 20,000 simultaneous

connections and scale down to fewer the 1,000

connections.

Table 4 - Possible Scenarios for Release Criteria

Defining Release Criteria… Rothman

… instead of waiting for everything in the Product

Backlog to be “done”…

“When the team used an agile approach and

demonstrated working product every two weeks… he

was willing to consider release criteria once he realized

the team was able to deliver value on a regular bass.”

… sprint after sprint

Charter the Project as a Team!

“The team needs to own the Project Charter or Plan …

and any experiments needed to understand the design

and architecture”

The objective is to identify the value the team expects to

create…

… and not to omit and therefore leave any action items

for the future.

Identify your Product type

First, the reference to Product requires that the team

focus on who will use the product… the users!

and… how often the team could release the product

identifies at the start what the “end” means.

Two kinds of products… those released continuously

(as software as a service) and those released

infrequently (as in hardware)

The Continuum of Release Frequency

The Continuum of Release Frequency

• For any a number of reasons, it may be difficult

and/or costly to release often… hardware dependent

development

(“Our Customers Can’t Take the Product Often”, insert)

• However, the cost of digital “Software as a service”

can be released continuously.

Digital-only Product as

Software ServiceBoxed Software

Product with

Firmware

Software with Hardware or

Mechanical Components

Continuous Less Frequently

Continuous Deployment Often: Less Often: Infrequently

As often as But the cost of The cost of Every release might be

several times a day release is still high release is high a major release

Potential for Release Frequency

Intermittent

Project Pyramid: Tradeoffs & Potential Risks for Projects

Inside project risks and Outside project risks

Assess your Project’s Risks

Success is not a “defined process”

There is no “checklist”

Risk of how the team “thinks” about the domain and

solves problems… the technical risks

Just as problematic

Not understanding (that is, knowing with certainty) the

more difficult risks… the scope, cost, schedule… and

the people and their capabilities

Avoid Management Mayhem (page 243)

Avoid Management Mayhem

“I had always worked in a culture of blame. I could

swear all my managers came from the school of:

“You do it, you own it.

I don’t like it, I blame you”

I did the same thing with my managers and their teams.

I wanted to use agile approaches.

I needed the features done and released.

I keep managing the same way I had always managed.”

Start Architecture Thinking

… but not defining the architecture at the beginning of the project

… but do start thinking about the architecture

Agile approach

The architecture evolves as the Product proceeds

“The teem will add features, iterating over the feature set. The team builds, increments, ad refactors the code and tests as the work proceeds”

Rothman

“When I work with people who are accustomed to starting with architecture, I ask them to draw a low-fidelity picture of the architecture as the team progresses.”

Recognize Project-Startup Traps

Trap: Iteration Zero

The “waterfall” bias… the need to complete the architecture plan

and estimation of the work to be done for the entire project.

“It is typical to adopt the defined (theoretical) modeling

approach when the underlying mechanisms by which a

process operates are reasonably well understood…. but

What you cannot know at the start…

When the process is too complicated for the defined

approach, the empirical approach is the appropriate

choice.”

Instead of the Big Design Up Front trap

Spend up to half a day creating a list of experiments so that the team knows what and where to explore

Determine the hardware or other resources the team will need to start that effort… determine if the team can start on anything without those resources

Iterations/sprints require estimates of work associated with stories in the Product Backlog… the team will need to master the process of estimating story points

If the Product Backlog is filled with stories, each of which is too big to complete in a sprint…the team will need to break the large stories into a smaller stories that can be completed in a sprint

“How little can the team do to get ready so they can start a sprint and begin delivering value”

Empirical Process Control

https://www.scrumstudy.com/whyscrum/scrum-

empirical-process-control

Recognize Project-Startup Traps

Trap: Your Organization wants detailed Project Plans

.. but you cannot know what specifically needs to be done and how it needs to be done at the beginning.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning…

Instead development requires empirical process control…

… a process that relies on the three main ideas of transparency, inspection, and adaptation.

Transparency

with the following Artifacts:

Project Vision Statement

Prioritized Product Backlog

Release Planning Schedule

Meetings

Sprint Review Meetings

Daily Standup Meetings

Information Radiators

Burndown Chart

Scrumboard

Recognize Project-Startup Traps

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning…

Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Inspection depicted through:

Use of a common Scrumboard and other information radiators

Collection of feedback from the customer and other stakeholders during the identification of features and stories

Creation of a Prioritized Product Backlog, and Release Planning processes.

Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate the Sprint.

Recognize Project-Startup Traps

In Scrum, decisions are made based on observation and

experimentation rather than on detailed upfront planning…

Empirical process control relies on the three main ideas of

transparency, inspection, and adaptation.

Adaptation

The Scrum Team and Stakeholders learn through transparency

and inspection and then adapt by making improvements in the

work they are doing.

Adaptation in Scrum is depicted through:

Standup Meetings

Constant Risk

Identification

Change Requests

Scrum Guidance Body

Retrospect Sprint Meeting

Retrospect Project Meeting