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