What Is a Sprint?
Imagine that you wanted to lose weight so you decided to start an exercise program. One way to begin could be to research and study all of the best exercise practices and then interview exercise experts after which time you could visit all of the gyms in your area, write down the positives and negatives of each, and then schedule time to negotiate the membership fee, choose the appropriate trainer and finally schedule your first workout. The effort described might take months. In the meantime, you would not have lost a single pound. Another approach to losing weight might be to simply (after getting the OK from your doctor of course) begin some (any) type of exercise program, monitor the results after about two weeks and then make the appropriate adjustments.
The first approach to starting an exercise program is akin to the ADDIE approach to developing training. ADDIE and other traditional ISD models are waterfall methods that encourage the practitioner to get all of the information required upfront, and to plan for every possibility before any development takes place. The second example is more similar to Agile, where after getting a basic understanding of what must be accomplished, the team immediately begins developing content. After short intervals of time, the work is assessed, course corrections are made, and the work continues to progress.
In Agile, the intervals or iterations after which progress is accessed and course corrections are made are called sprints. A sprint is a set period of time where specific work items are completed and then reviewed. Before a sprint begins, a planning meeting is held. In this sprint planning meeting, an agreement is reached about what items will be pulled from the product backlog and completed during the upcoming sprint or timeframe or iteration. At the completion of the sprint, the team provides a demonstration of the completed items to the customer to get their (the customer’s) input on the items delivered. This meeting is called a sprint review or demo. An internal meeting is also held. The purpose of this meeting or sprint retrospective is to determine what went well and to find ways of improving for the next sprint. Every day that a sprint is in progress, a daily standup or 10- to 15-minute status meeting is held. At these daily standups only three questions are asked: What have you done since yesterday? What are you planning to do today? And are there any impediments/stumbling blocks?
The sprint goals are not changed during the sprint, and development is time-boxed, which ensures that sprints end on time. If requirements are not completed for any reason they are left out and moved back into the product backlog. In addition to meetings that are held at the completion of sprints, the progress of the work completed is typically documented in a tool called a burn-down chart.
DTCC Learning’s First Sprint
The newly formed DTCC Learning training teams each began their first sprint with significant anguish. Although they had been through Agile training and participated in creating a product backlog, none of the employees had ever developed learning products in this fashion. They felt uncomfortable attempting to recommend solutions without having “all of the information.” Most were reluctant to committing to the timeframes required to complete the tasks identified. Many had problems decomposing or breaking down learning solution recommendations into smaller learning assets that could be put into production immediately after the sprint was completed. Some felt that their team didn’t have the skill set required to deliver on the learning assets required.
Anguish not withstanding all of the teams performed admirably on their first sprint. One team was able to release more learning solutions to customers after the two-week sprint than had been delivered in the previous quarter. Another team committed to delivering 43 learning solutions and was able to publish 36 of those items to production. What made the sprint even more of a success was that the individuals on the teams were able to self-identify obstacles that prevented them from delivering 100 percent of the value that they committed and to develop plans for getting better in the next sprint. The basic feedback was an overall sense of empowerment. Each of the learning teams were energized and looked forward to their next sprints.
The challenge for the leadership team now became maintaining this energy and analyzing the productivity and quality of the learning solutions produced pre and post Agile. Look for that discussion in my next blog.
