Applying the Dreyfus Learning Model to Focus your Coaching Approach
Over the past five years, Jaron Lambert (@jaronlambert) and I have helped several companies and dozens of teams transition to agile product development processes. In working with the myriad of teams and people, we've learned that the best way for us to help people learn agile principles and techniques is to use the Dreyfus Skills Acquisition Model. This model employs the usage of non-situational rules for novice practitioners. The adherence to these rules promotes the transition to an advanced stage of learning by providing the student with a foundation for recognizing patterns and principles for application in new situations. We've discovered (as the model predicts) that skipping this stage of learning can lead to problems absorbing and implementing the philosophies and principles of the agile manifesto. To that end, Jaron and I have collated a set of rules we have found useful in working with Novice teams. This is a living collation and we'd be very happy to hear what other coaches and ScrumMasters (or others) think does and does not help their teams' learning process.
Jaron and I will be speaking about the 5 stages of learning that teams traverse (not just Novice) according to the Dreyfus model as they learn agile concepts and philosophies.
Environment
Co-locate where ever possible, set up your teamʼs space for optimal teamwork.
Maximize face-to-face communication; minimize email communication within the team.
Minimize distractions. Remove or minimize anything that distracts the team from finishing the work that they committed to (i.e. completing all the Stories in the iteration plan). Inform the Program/Project Manager of any distractions that canʼt be removed directly.
Roles
The Product Manager is the “messenger of the market” and articulates why we should spend time/money on any development. Product Managers describe what the market needs in a Market Requirements Document (M.R.D) and are responsible for describing those needs in User Stories.
Product Managers set the business priority and help define acceptance criteria during iteration planning, answer questions from the team during the iteration, and accept stories before the end of the iteration.
Program/Project Managers (Scrum Masters) shepherd the process. They provide the Product Manager with all currently available information so that the Product Manager can make informed and timely decisions. Program/Project Managers answer process questions from the team.
Program/Project Managers facilitate removal of any/all roadblocks for the team, ensuring that someone on the team is responsible for any roadblock and keeping track of unresolved roadblocks.
All other team members are responsible for delivery: reliably delivering quality software solutions (i.e. implementing stories).
All other team members provide the Product Manager with solution options (alternative ways to implement solutions to stories) with associated costs.
Release Planning
Review the MRD to ensure that the entire team has an understanding of the goals of the release (i.e. Problems, the users who have them, and the situations under which they have them)
Write stories using the template: “As a {persona} I want to be able to {do something} so that {some goal is achieved}”, See “Writing Stories”, Chapter 2 from User Stories Applied by Mike Cohn.
Size all the stories in the backlog using a modified Fibonacci sequence (0,0.5,1,2,3,5,8,13,20,40,100). The size of a story represents the overall complexity, difficulty, and effort to complete the story.
Add up the story sizes to get the total story points in the release.
Backlog Grooming
Product Manager grooms the Release Backlog for their product. They keep it organized and prioritized, and add or remove stories so the Release Backlog always describes expectations for the release.
Team Members are responsible for sizing the stories in the release backlog, and breaking stories from the Product Manager into smaller stories that deliver value within an iteration (see “Twenty Ways to Split Stories”, http://xp123.com/xplor/xp0512/).
Iteration Planning
The Product Manager decides priorities for the team to work on in the next iteration. Team selects the stories they can complete within the iteration and decides how they work on the tasks during the iteration.
Only plan to work on sized stories.
Only plan to work on stories with agreed upon acceptance criteria (discuss and agree on the criteria, and document it during the planning). Team breaks each story into tasks and clearly defined acceptance criteria.
Agree on the definition of ʻdoneʼ for the team (update it whenever necessary).
Agree on ʻRules of Engagementʼ (update them whenever necessary).
Iteration/Sprint Execution
The teamʼs priority of work:
Keep the build/install working and testable (getting a brokenbuild/ install, and getting broken automated tests working, is always top priority).
Keep existing functionality working (fixing defects with functionality that worked before the current iteration is #2 priority).
Keep the functionality being built this iteration working (fixing defects on this iterationʼs stories is #3 priority)
Build out current stories (implementing new functionality is #4 priority)
Philosophies to continually keep in mind:
The fewer stories in progress the better (3 things shippable and 2 things unstarted is better than 5 things ʻalmost doneʼ).
The fewer tasks in progress thebetter.
Donʼt work on anything unless youʼve already agreed with your team mates how it will be tested and how you will know if youʼve been successful.
Donʼt add a new story to the current iteration mid-iteration (unless every other story is complete).
Donʼt split a story mid-iteration. Teams need to consistently complete the stories they committed to and establish a velocity. While they are gaining experience doing that, they will learn better habits faster by recognizing 0 points for incomplete stories and reflecting on how to better deliver on the iteration plan.
Daily Standup
Each member of the team updates the other team members on progress against the stories they are working on:
What did you accomplish yesterday (since the last standup)?
What do you plan to accomplish today (before the next staandup)?
What is getting in your way?
What is your latest estimate of how much time is left on your current task(s)?
Only people with work assigned in the iteration should speak.
Topics outside these questions should be addressed outside the Daily Standup.
Does the plan need to change as a result of the above? If so, change it now!
If anyone doesnʼt have enough to do today, decide what they will do at the standup.
All members of the team watch for “bad smells” in their scrums, and mention any apparent infractions. All members of the team work together to remove “bad smells” from their daily scrums.
Demos
Demonstrate only what the team accomplished (i.e. Stories the Product Manager has already accepted).
Record any issues, bugs, or enhancements that come up (and assign them or add them to the backlog after the demo).
Product Manager accepts (or decides not to accept) any remaining stories.
Avoid troubleshooting, discussing solutions, brainstorming ideas, exploring functionality, or anything else that takes away from clearly demonstrating the work that was completed this iteration.
Retrospectives
What was the teamʼs velocity this iteration? Has the team established a consistent velocity? If so, what is it? If not, what is preventing the team from establishing a constant velocity?
What did we say weʼd improve / stop doing last retrospective? Did we?
Each member of the team has a chance to say (focus on the process, not the people):
What went well / what should we keep doing?
What could be improved / what should we stop doing / what is holding us back?
Team identifies the most important item(s) or issue(s) to focus on next iteration (1 or 2 items / issues is enough).
Change or add to “Rules of Engagement”?
Modify the teamʼs definition of “Done”?
