1. © 2013 ripplerock
Evolutionary Stages
Helen Meek
July 2013

2. © 2013 ripplerock
What is Evolutionary Stages?
A tool that enables teams to self reflect on where their
Agile, development and testing practices are compared
to best practice and/or to the companies long term goal.

3. © 2013 ripplerock
Benefits of Evolutionary Stages
Provides the ability for teams to:
• Understand what best practice is and transparency of the desired
journey to excellence.
• To map their start point and to track progress through continuous
improvement cycles through a visual tool.
• Create agree and create an action plan on how improve practices.
• Increased cross team visibility and collaboration to facilitate shared
learning and best practice.

4. © 2013 ripplerock
How Evolutionary Stages Is Run
• Evolutionary stages (ES) can be run as an out of the box retrospection tool or can be
tailored specifically towards the long term goals of the company. For our client in
this instance they chose to tailor part of their template based on the development
and testing practices they wanted to introduce. I worked with the client and their
practice leads to understand their Agile adoption, testing strategy and development
practices to tweak the pre-filled template from best practice.
• As I had a large community of ScrumMasters and I needed their support to run the
practice, I got them together to discuss the key aim and benefits of ES. The long
term goal is for the organisation to become self sufficient in conducting the
retrospectives and facilitating the completion of the action plan.
• RippleRock provided facilitators/coaches to facilitate the sessions with the teams. A
key benefit of having the external coaches was to use their experience and
knowledge to help really drive out what was going on in the teams and to provide
challenge where clarity was needed. From working with the team we were able to
understand if they were at foundation, improving, self-sustaining or excelling level.

5. © 2013 ripplerock
The Questionnaire
Here is an example of the questionnaire used. A key part of the role of
facilitator was to really deep dive into the teams practices and challenge
whether they really are meeting the true definitions. This may include asking to
see evidence such as documents, team walls or code.
Stage 1: Foundation Y/N Wt
Scor
e
Stage 2: Improving Y/N Wt
Scor
e
Stage 3: Self-sustaining Y/N Wt
Scor
e
Stage 4: Excelling Y/N Wt
Scor
e
Business interface 10 0 11 0 11 0 7 0
Business involvement
Nominated business person to prioritise and prepare
stories
n 5 0
Product Owner works closely with stakeholders, stakeholders
review sprint output
n 3 0
Business stakeholders attend the Sprint Review in addition to the
PO and actively create backlog items
n 3 0
High levels of trust and active collaboration between business
and Scrum teams with stakeholders actively providing pre-
sprint, in-sprint and post-sprint feedback to support sprint
goals of the team
n 3 0
PO Availability
Product Owner is available during Sprint to answer
questions n 3 0
Product Owner is embedded member of Scrum Team i.e. in
sporadic sprint ceremonies n 3 0
Product Owner is embedded member of Scrum Team i.e. in every
sprint ceremony, actively taking tasks for story development from
sprint backlog
n 4 0
as in self-sustaining
n 1 0
Story Development
Stories, regardless of their granularity are created in
advance of the first sprint starting. n 2 0
Product Owner works with the team to get stories to 'ready'
prior to sprint collaboratively understanding acceptance
criteria, dependencies and priorities
n 5 0
The Product Owner is never ‘surprised’ by Story implementation in
the Sprint Review because they are actively involved in
transitioning the story to software during the sprint
n 4 0
Story may continue to evolve - with any further enhancements
to the story which might be identified are put into the backlog
as new stories
n 3 0
Product Ownership 16 0 25 0 13 0 20 0
Prioritising
There is a list of prioritised requirements provided to
the scrum team
n 5 0
The Stories have been prioritised by the Product Owner based
on a clear and traceable ROI from the business case.
n 5 0
...and the scrum team has re-prioritised stories or created spikes
based on risk
n 2 0
...and where necessary the PO has re-prioritised stories based
on technical dependencies to ease delivery. The PO and team
have agreed the re-prioritisation or 'ordering' based on risk and
dependencies.
n 3 0
Backlog Structure
Project has vision and outline scope
n 3 0
The Product Backlog is correctly scoped and regularly
maintained (at least weekly) and prioritised
n 5 0
The structure of the backlog is aligned to the business case.
A vision, release roadmap, story maps, themes and Epics (or
similar tools) are used to cluster, organise and communicate the
Product Backlog in a coherent manner.
n 2 0
The backlog structure is small and fluid to enable frequent
deployments. Rapid increments are small and do not require
huge structure. The product roadmap evolves based on ROI
n 3 0
Stories
Stories are written by a user or business domain
expert in the standard story format 'As a <role> I
want <functionality> so that <business rationale>.
Followed by acceptance criteria
n 1 0
Story size is relative to position within the backlog - with
small stories at top - and 'epics' lower down. More granularity
of stories at the top of the backlog. An include clear
acceptance criteria
n 5 0
Stories are created in story writing sessions where Product
Owners work with users to write high quality stories
n 4 0
Acceptance criteria is written in the form of testable outputs
including an example output that is used for testing. Developers
and testers contribute to writing of acceptance criteria. n 5 0
Release Planning
Stakeholders are aware of the benefits of dividing
projects into smaller deliverables - including definition
of MMF n 3 0
There is a release plan, with MMF and an outline of
subsequent releases
n 5 0
A release kick-off meeting ensures all aspects are covered,
including; architecture, business value, functionality and non-
functional requirements.
The release planning process includes a retrospective and is
improving.
n 3 0
All elements of the value stream participate in release planning.
Estimates at story point level of stories in Release - in order to
create Release burn down charts. n 5 0
Post-Sprint Activities
PO attends and contributes to Sprint Review -
providing feedback, validation and recognition of
work done
n 4 0
Sprint Reviews generate regular and useful feedback -
stakeholders, other than the PO, sometimes attend n 5 0
PO acknowledges post sprint feedback and always adds new
requirements to the product backlog.
n 2 0
All relevant support documentation and training information is
included in this 'packaged' product – reviewed by the PO n 4 0
Sprint Working 34 0 32 0 28 0 21 0

6. © 2013 ripplerock
Our First Output
Once we have completed the questionnaire we are able to provide an instant
team heat map and a spider diagram to track progress over time.
Foundation Improving Self-sustaining Excelling
Business interface 10 ## 10 11 # 11 11 # 0 7 ## 0
Product Ownership 16 ## 16 25 # 15 13 # 6 20 ## 0
Sprint Working 34 ## 34 32 # 15 28 # 7 21 ## 4
Team Stuff 22 ## 22 28 # 26 24 # 10 20 ## 1
Planning & Estimating 15 ## 15 13 # 13 19 # 19 11 ## 11
Continuous Improvement 8 ## 8 6 # 3 6 # 3 8 ## 5
Development Practices 19 ## 16 20 # 15 21 # 6 15 ## 2
Testing Practices 28 ## 25 28 # 20 30 # 10 25 ## 5
Continuous delivery 22 ## 22 25 # 18 25 # 10 27 ## 8
Categories Different Levels
Met level
Partially met level
Level not achieved
Scores on the left indicate the
maximum points available, and
the points on the right detail
the team score
0
1
2
3
4
Business
interface
Product
Ownership
Sprint
Working
Team Stuff
Planning &
Estimating
Continuous
Improvement
Development
Practices
Testing
Practices
Continuous
delivery

7. © 2013 ripplerock
Action Planning With The Team
Once the team data has been collected, the coaches sat down with the teams
to start creating their action plan and adding appropriate items to the teams
enhancement backlog. We worked through each area of the questionnaire and
brainstormed what it would take to get them to the next level and the risks if
nothing is done. Below is a sample output:

8. © 2013 ripplerock
Action Planning With The Organisation
A number of the challenges identified were not directly within the control of
the teams and so required the organisation to implement or change
tools, process or behaviours. Below is a sample output:

9. © 2013 ripplerock
Overall outcome
Using all the data collected were able to create an ‘Evolutionary Stages
Summary Report’ to present back during a workshop to key stakeholders. The
report was pitched at departmental level and never delved into the individual
findings of the team. This was a conscious decision as we wanted to avoid
cross team comparisons or team.

10. © 2013 ripplerock
Conclusions
• In this particular instance I was asked to create a report for the company.
This is ok, however we need to ensure that we don’t create a culture where
teams fear about being honest. This can be achieved easily by being open
and transparent with all parties up front.
• I worked with this client for 15 months and considering the roller coaster
journey that they has embarked on this would have been fantastic to have
run at the start of the account. I have no doubt that the change curve would
have been quite significant and a great story for them to tell. I am a great
believer on tracking the journey and this is a fantastic tool to do this.
• The tool is great at helping people express what level they are expecting
the company to reach with their agility, testing and technical practices. So it
is critical to write this in conjunction with leaders within the organisation.

11. © 2013 ripplerock
Conclusions
• The exercise was quite lengthy and despite coming across some initial
challenge from the teams, they soon realised the value once the exercise was
completed and the action planning commenced. I have already seen many of
the teams sprint into action. We conducted the full Evolutionary Stages in this
instances, but there is a Evolutionary Stages Lite.
• Whilst this was not about comparing the teams, I have found that actually a
little healthy competition has been good, and this has opened up the
opportunity for them to showcase their practices to other teams.
• All in all I have seen a improvement in the teams continuous improvement
cycles since completing ES. I have since left this client, however I have been
invited back later in the year to re-run the exercise so they can show case
further improvement. I know they will have another great story to tell!