Table of Contents
EVDnC (Extreme Value-driven Coaching, pronounced “evidence”) is an Agile training and coaching framework based on fast paced Scrum, used by Agile Coaches to boost their work with one to three teams at a time within the organization.
The EVDnC framework consists of roles, events, artifacts, techniques, and rules. Scrum Teams, formed by a Product Owner, the Development Team members, and a Scrum Master, run one-day development cycles (“One-Day Sprints”) in a single week of intensive and focused work, aimed to produce high quality, visible and usable value every day. The rapid feedback cycles allow teams to fail fast and learn even faster, speeding up the team’s learning process and bringing long-term benefits. Each team releases a high-value product or product increment by the end of the week.
The accelerated pace stimulates existing dysfunctions to emerge. The EVDnC Coaches deal with the dysfunctions as they appear or put the necessary improvements on a backlog to be worked on afterward, at the Post-EVDnC.
Facilitated by EVDnC Coaches, stakeholders and Scrum Team members collaborate very closely. They quickly learn, feel and become able to show the benefits of Agile approaches.
EVDnC is not sustainable for the day-to-day work in the long term and has a temporary nature, lasting only one week. It is though recommended to do it from time to time, as the team changes and the environment changes. EVDnC can be seen as a short duration training or experiment, which can be useful to get buy in from the involved and provides more freedom of action to the EVDnC Coaches.
EVDnC was created by Carlos Felippe Cardoso, Marcos Garrido, Rafael Sabbagh and Rodrigo de Toledo, the founders of Knowledge21 (http://knowledge21.com). EVDnC was run by Knowledge21 and its coaches on dozens of teams in the last few years, usually as part of Agile Transformation efforts.
EVDnC can bring significant results in a single week of intensive work. It also helps raise a backlog of improvements to the work of the teams and the organization around it, which includes the upstream and the downstream work. EVDnC Coaches work with the team and the organization to address this backlog at the Post-EVDnC.
The participants are coached on how to be more effective and deliver high value in a minimal amount of time. The Development Team members learn how to be more efficient by using good product development techniques. The Product Owner, the Development Team, the Scrum Master, and relevant stakeholders understand the importance of working side by side. This very intensive process imposes severe time constraints, helping all involved to focus on what matters: delivering high value.
These are the primary EVDnC learning objectives for the teams and the organization
The Product Owner holds the authority to define and prioritize the work of the Scrum Team, The Product Owner writes, slices, prioritizes and discards User Stories in collaboration with the team. EVDnC aims to empower the Product Owner, so no one else is allowed to change team’s priorities. Through this work, the Product Owner is responsible and accountable for maximizing the return on the investment of the product and for showing the results quickly.
The Product Owner in only one person for the Scrum Team. It is not a committee or a split role. However, the Product Owner can be shared amongst the different Scrum Teams in the same EVDnC week.
EVDnC may start with a non-ideal Product Owner configuration. In this case, the EVDnC Coaches work with the team and the appropriate stakeholders to find a suitable Product Owner throughout the week.
The Development Team is a small group of skilled people (usually, up to nine). This group must have all the knowledge and skills needed to create the end-to-end product, including technical but, ideally, user-focused and business-focused knowledge as well.
Development Team members work together, on the same item. They use the best of their abilities and knowledge to do the work, but also recognize that they must collaborate intensively, providing help to each other in whatever is needed in every moment to get the top priority done, instead of just working in their own silos. This way, they get work done faster, and they learn from each other, growing as a team.
The Development Team members strongly collaborate with the Product Owner and, together, they self-organize to do the work within the One-Day Sprint.
The Scrum Master is a team facilitator and supports the work of the EVDnC Coaches, facilitating every Scrum Team’s interaction, helping them keep the focus on the EVDnC work and removing any impediments on their way.
On the other hand, the EVDnC Coaches should direct a part of their efforts to train and coach the Scrum Master and reinforce that role with the teams. Therefore, the Scrum Master also learns new techniques and evolves with the team during the week.
The Scrum Master is neutral and as much as possible works on the process level, not on contents level. The effects of the Team Facilitator’s work is leverage for the Scrum Team’s results.
The EVDnC Coaches work full time to coach and mentor Scrum Team members throughout the EVDnC week. They are empowered to make sure all team members understand the EVDnC rules and adhere to them. They identify opportunities for improvements and work with the teams and stakeholders to address them. They work to remove impediments and fix dysfunctions as they emerge. They add whatever they cannot fix during the EVDnC week to a backlog they will use after the week is over, at the Post-EVDnC.
The EVDnC Coaches can focus on any learning topics that prove needed for the EVDnC work. For instance, those can be technical, business or any team matters. The coaches can even pair with Development Team members, the Scrum Master or the Product Owner if that proves to be educational.
The EVDnC Coaches identify one or more stakeholders needed to support and protect the work of the teams during the week. They reach to those stakeholders whenever necessary.
The minimum recommended ratio between EVDnC Coaches and Scrum Teams is two coaches for one team, two coaches for two teams and three coaches for three teams.
If there is more than one team, The EVDnC Coaches should not work alone or split by team. They should collaborate intensively with each other throughout the day, creating visibility among them and making quick but, mostly, shared decisions on what to do next.
A typical setting for EVDnC
All EVDnC events are time-boxed, which means they can be shorter, but not longer than a maximum predefined amount of time.
Before the EVDnC week, the EVDnC Coaches collaborate with management or with the leadership team to seek the necessary alignment for the work to come.
The EVDnC Coaches help identify the people who will participate in the process and, whenever possible, quickly brief them about EVDnC and what is needed from them. Those include one or more Product Owners, Scrum Masters, Development Team members and relevant stakeholders who are critical to support the work. The EVDnC Coaches understand who those people are and how they work today. Forming new Scrum Teams might be necessary if there are no previously established cross-functional teams.
The EVDnC Coaches and stakeholders work to identify and select high-value product ideas to transform them into a working product, at most one per team. The best choice is a new product, not part of an existing one, but it could instead be a product increment. The skills needed to create the product must be totally within the team’s technical and business knowledge.
The Preparation takes place on the first of the five days of EVDnC and is time-boxed to one day.
The EVDnC Coaches explain the EVDnC rules to all Scrum Teams involved and, if possible, to the closest stakeholders. They explain what EVDnC is, how it works and what is expected from them every day and by the end of the week. The EVDnC Coaches aim to align and engage all involved.
Based on the previously selected product ideas, the Scrum Teams craft clearly defined Product Goals. Each team can work on a separate product, or more than one team can work on the same product and share the same Product Goal. If product ideas had not been selected, this is the latest possible moment that this is supposed to be done.
Each Scrum Team then work with the EVDnC Coaches and stakeholders to create an initial prioritized list of User Stories, similar to the Scrum Product Backlog. This list must contain at least sufficient work for the first One-Day Sprint, but it should possibly have sufficient work for the whole four days. The list is dynamic, evolves and is adapted throughout the week. If there is a single Product Owner for more than one Scrum Team, those teams may have to work together to craft that list.
Finally, each Scrum Team, without its Product Owner, does the necessary housekeeping, preparing the work environment and addressing and mitigating, as much as possible, any technical risks that might become an impediment for the week of work.
A Retrospective meeting closes the day.
From the second day of EVDnC on, One-Day Sprints are run. One-Day Sprints have a fixed duration of one day of work.
A One-Day Sprint starts with a quick planning session, the Planning meeting. A full day of development follows, during which one or more Checkpoint meetings take place. The Review and the Retrospective meetings close the day. On the final day, a Big Review and a Big Retrospective take the place of those two last ones.
If more than one Scrum Team is involved in the EVDnC week, it is not unusual to shift the beginning and end of the work day in 15 minutes per team so all the EVDnC Coaches and the Product Owner can be present on each event of all teams involved.
Each One-Day Sprint should be considered as a project in itself, lasting one full day of work. The Scrum Team must generate visible, usable value for the user by the end of each day so that they can get useful feedback for the next One-Day Sprint.
On EVDnC One-Day Sprints, all Development Team members of the same team work together on the same User Story, in priority order (work in progress limited to one), unless otherwise specified by the EVDnC Coaches. They use all their knowledge and skills to transform the User Story into a working product. After the User Story is done, according to the Definition of Done, they call for a Checkpoint meeting and move to break the next User Story into tasks.
The Product Owner and the Development Team work together and collaborate very intensively throughout the One-Day Sprint. The Product Owner makes quick decisions. The Product Owner clarifies questions and makes sure all Development Team members understand, on every step they take, what are the user and business need to be achieved, keeping a strict focus on the problems, not on pre-defined solutions. The Product Owner and the Development Team should also take some time during the day to have the conversations necessary to prepare User Stories for the next day of work.
The EVDnC Coaches collaborate intensively with each other. They work together with each of the Scrum Teams. They identify dysfunctions and opportunities for improvements at the individual, team and organizational level. They address what was raised and add to a backlog what won’t be possible to solve during the EVDnC week.
Each One-Day Sprint day begins with a 15-minute time-boxed One-Day Sprint Planning meeting. Each Scrum Team has its own Planning meeting, and all of its members are present. There is at least one EVDnC Coach following the meeting.
The Development Team and the Product Owner select the User Stories to be developed during this day of work. They usually select up to three User Stories, which is a forecast, not an obligation as otherwise, it would create dysfunctions.
The Development Team then breaks the first User Story into tasks. They might be allowed to break more than one User Story, as directed by the EVDnC Coaches.
Throughout the day, the Scrum Team runs one or more 15-minute time-boxed Checkpoint meetings. The team uses those meetings to plan at the task level, breaking the next User Story as necessary and selecting who will do what.
Similarly to the Daily Scrum meeting, it is usual for the team members to state what they had done since the last meeting, what they intend to do, and what were or are the impediments.
Usually, one Checkpoint meeting is run about halfway the day.
The One-Day Sprint Review is a 15-minute time-boxed meeting and is held at the end of the day, right before the One-Day Sprint Retrospective.
Now that the team had materialized the ideas into a working increment, the Review meeting becomes an opportunity for them to anticipate feedback from stakeholders, which may include real users whenever possible. The Scrum Team presents the product that has been done this far to stakeholders so they can collaborate. They inspect what has been developed and adapt the list of next User Stories to be done, as appropriate.
The Review is held from the second to the fifth day of EVDnC. On the fifth day, it can:
The One-Day Sprint Retrospective is a 15-minute time-boxed meeting, and it closes the day. It is an opportunity for the Scrum Team, including the Product Owner, to inspect and adapt its ways of working together as a team, aiming to become more effective. They create a couple of short action plans around improvements, to be implemented right on the next One-Day Sprint.
It is suggested, as a learning opportunity, that different techniques are brought by the EVDnC Coaches to be used on each of the five Retrospectives.
The Retrospective is held from the first to the fifth day of EVDnC. On the last day, it can be replaced by the Big Retrospective meeting, where all teams do a retrospective together.
By the end of the last day of EVDnC, it is desirable to run a Big Review meeting with all teams together, replacing the regular Review. This meeting is a usually a timebox of 15 minutes per team. Each Scrum Team briefly presents to stakeholders, to the other teams, and to other guests in the organization the working product they created during the EVDnC week. This session is frequently done in a larger room, and with the use of projectors or a big screen, so everyone can watch and provide feedback.
The Big Review is a moment of closure and a time for celebration. At this meeting, frequently the Scrum Team shows, to relevant stakeholders in the organization, an amount of work done and value delivered that they were never able to do before in such a short period. Together with the EVDnC Coaches, they are often proving that those same teams, with the right mindset and techniques, can deliver.
After the Big Review, by the end of the last day of EVDnC, a Big Retrospective usually replaces the regular Retrospective. This meeting is facilitated by the EVDnC Coaches and is time-boxed to 15 minutes.
The Development Team members and Product Owners of all Scrum Teams discuss what was learned, how they felt during the process, and what they will keep doing from that moment on, after the EVDnC week.
EVDnC brings an initial boost to the work of teams, but the coaching work must be continued. One or more EVDnC Coaches frequently stay working with the teams for a number of weeks following EVDnC.
The EVDnC Coach or Coaches create a strategy on how to work on the backlog of improvements raised during the EVDnC week, addressing both team and organizational dysfunctions. The EVDnC Coach or Coaches are responsible for creating high visibility and sharing the results of this work.
The Product Goal is an objective of value that will be incrementally achieved and enhanced within the EVDnC week through the implementation of User Stories. It guides the Development Teams on what is the problem they are working to solve by building the Product and aims to bring alignment between all stakeholders involved.
The Product Goal must be crafted before any of the One-Day Sprints. Very often it is crafted even before the Preparation, within the previous weeks.
There could be one Product Goal per Scrum Team, or a single Product Goal for more than one team if they are working on the same product.
The Product Goal preferably addresses a new product, not part of an existing one. If that is not possible, it could refer to a product increment, but with a good level of independence of previous increments, to reduce unpredictable risks that may pose a threat to the work of the week.
It is also possible to run EVDnC without a clear Product Goal, as part of ticket-oriented maintenance work, though this could be less effective.
The Definition of Done in EVDnC is very similar to the Scrum term. It is a shared understanding of what it means when the team declares a User Story is done, and it is the same for each and every User Story.
Each Scrum Team has its own Definition of Done, or more than one team can share the same Definition of Done if they are working on the same product or product increment. The Definition of Done is shared between all involved in the EVDnC work, including Development Team, Product Owner, EVDnC Coaches, and stakeholders.
The Definition of Done is used to help define what is the work needed to transform a User Story into a potential part of the product. It is also used to assess when this work is complete. Therefore, a User Story that is done, according to the Definition of Done, has everything that is required to be put in the hands of users, including sufficient quality.
The Definition of Done is created at the Preparation but is adapted as needed along the way.
The taskboard is a highly visible board each Scrum Team uses to represent the work to be done in the One-Day Sprint. It shows the User Stories selected for the day and the corresponding tasks for the User Story currently being worked on. It also indicates the status of each task.
The taskboard is a Scrum To Do/Doing/Done board or a Lean Kanban board, in this case reflecting every stage of the work.
The User Story format is a representation of the work to be done to create functionality for the user, from the user’s perspective. The usual pattern states (1) who the user is, (2) what does he/she need, i. e., the functionality to be developed and (3) why does he/she need it, i. e., what is the immediate value the user gets from it.
One of the most important aspects of User Stories is that conversations must take place between the Product Owner and the Development Team to define and detail the functionality to be developed. Therefore, Product Owner and Development Team members should meet during the day to have the conversations necessary to write, slice and prepare User Stories for the next day of work.
Each User Story is a very thin slice of a user need. Each User Story must be completed in at most one day of work. If the User Story is too big to fit on that timeframe, it must be sliced down, keeping the focus on the problem to be solved. The User Stories must be prioritized to deliver end-to-end value to the user as quickly as possible. Usually, a Scrum Team completes from one to three User Stories every day.
EVDnC is a free framework created and offered by Knowledge21 in this guide. EVDnC is defined by its roles, events, artifacts, techniques, and rules. You are allowed to introduce and use any additional techniques or tools to help teams achieve their goals, and you can keep calling it “EVDnC,” as long the basic structure is not compromised.
Copyright © 2013-2017 Knowledge21. Offered for licensing under the Attribution-ShareAlike 4.0 International license of Creative Commons (CC BY-SA 4.0), accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode. A human-readable summary of the license is available at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this guide, you acknowledge and agree that you have read and agree to the terms of the Attribution-ShareAlike 4.0 International license of Creative Commons.
EVDnC - Created in 2013
© 2013 - 2023 - All Rights Reserved