Dwight D. Eisenhower is credited as stating that “Plans are nothing; planning is everything” in response to how the plans for the D-Day invasion were made useless as a result of the bad weather that occurred on that day.  The Eisenhower quote was totally appropriate for the experience that the DTCC Learning team had with agile training.  After months of carefully planning every aspect of the learning experience, the plans became useless as a result of the facilities being changed and the preferred instructor being unavailable. The exercise in planning, however, ultimately allowed the session to achieve most of its goals.

The clarity of required outcomes empowered the leadership team to not shy away from stopping the instructor and requesting that he provide more concrete examples.  When the attendees at remote locations had a hard time seeing or hearing interactions at the primary site the students frequently requested that camera angles be changed or that the comments be repeated. While the overall quality of the training left much to be desired, the team walked away with an understanding of some basic but important tenants of agile, an appreciation of how it could be used in a learning development environment, and a desire to start using agile.

What is Agile?

The frequent requests for examples allowed the DTCC Learning team to quickly learn that agile was an iterative approach to development where both the solutions and requirements evolve over time as a result of collaboration between cross functional, self-organizing teams.  This is quite different from the ADDIE model or even the Six Sigma approach.  Both Six Sigma and ADDIE are waterfall methodologies that are heavy in process and documentation. In waterfall approaches, the sequential plan determines the cost and schedule.  Agile on the other hand allows the vision and values to create feature estimates. Its framework is based on just three roles, four artifacts, and five events.

The 3 Roles

• Product Owner – Responsible for what is developed,  represents the customer’s need, defines the right solution, and prioritizes the work to be done.

• ScrumMaster – Responsible for how the work is done, coaches the team, facilitates meetings, and removes obstacles.

• Development Team – Cross functional team that is responsible for completing the work. 

The 4 Artifacts 

• Product Backlog – List of all features that must be delivered.

• Sprint Backlog – List of all features being worked on for a particular release.

• Burndown Chart – A tool used to view the progress of work being accomplished.

• Sprint Increment – The sum of all backlog items completed during a sprint and all previous sprints. 

The 5 Events 

• Sprint Planning Meeting – Meeting to get agreement on what working software will be delivered during iteration.

• Sprint – The set period of time where specific work will be completed and ready for review.

• Daily Standup – Short status meeting (10 to 15 minutes).

• Sprint Review – A demonstration to the customer of the items completed during a sprint.

• Sprint Retrospective – An internal meeting held at the end of a sprint to determine what went well and to find ways of improving for the next sprint.

How Would Agile Work in Learning Organizations?

Ensuing discussions and questions uncovered that what this means for learning organizations is that rather than spending weeks or months analyzing (analysis) the problem to determine what the learning solution should be, and then presenting those findings to a business partner for an approval followed by the creation of a design document or outline and objectives (design) that are then submitted for another review and approval, followed by the creation of a  prototype (development) that would need to go through the same review and approval process, the team gets an agreement on a set of features (learning outcomes) that must be accomplished as a result of the training that divides those features up into prioritized work items that allow the team to develop and deliver a working learning solution within two to four weeks.

Hearing this caught the attention of the attendees who were visibly tired of processes that were review and approval heavy and which frequently resulted in months of work becoming a waste of time as a result of changing requirements.  The agile manifesto where individuals and interactions were valued over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan got further buy-in from the attendees.

Now the Hard Part

The team left the training both excited about using the methodology and concerned that they did not receive enough concrete examples to get it right.  The leadership team assured them that the expectation was not that they “get it right” immediately, but that they continue to perfect the approach.  In the next weeks I’ll be sharing the good, the bad and the ugly of DTCC Learning’s road to agile.