Your SlideShare is downloading. ×
Evolutionary Stages Case Study
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Evolutionary Stages Case Study


Published on

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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!