Appendix A: Lean-Agile Job Tasks for the Buyers

Job Tasks for Lean-Agile Courseware Buyers

This section is aimed at training buyers.

To better articulate our discoveries about what was really needed on the job for people transitioning to buying courseware using Lean-Agile, we performed a task analysis and developed the following Task List of things people need to be able to do using Lean-Agile on courseware product development projects.

You may need some of these, and others that are not listed. Use this as a start point and adapt for your unique circumstances.

Review Current Strategy

  • Define stakeholder and customer needs

New Strategy–Decide Whether to Use Lean-Agile

  1. Identify timescales and resources available.

  2. Authorize funding the project as you have always done.

  3. Determine to take advantage of improved cost and schedule performance for projects requiring contractors/suppliers use Lean-Agile.

  4. Gain senior leadership buy-in and support up front for using Lean-Agile for cost, performance, and risk mitigation goals. Their support may be necessary to overcome turf tussles, keep stakeholders onboard during the project and to remind all that learning what works is valuable for future efforts. Status quo will not get the gains that Lean-Agile can provide. Without leadership, status quo will win out.

  5. In cooperation with legal counsel, determine the Agile contract terms and conditions you will use to support your goals.

  6. Gain consensus from all approvers and stakeholders that this Lean-Agile project will freeze cost and time, and allow changing scope (content and functionality) based on highest buyer value. Therefore scope juggling may occur during iteration planning meetings.

  7. Determine if the buyer’s staff needs to be trained on how to work within the Lean-Agile approach.

    Be sure any staff training has already tailored for training services and products rather than for software or manufacturing. The principles indicate different methods are appropriate for training.

  8. Develop your business case for Lean-Agile.

New Strategy–Determine How Much Lean-Agile your Organization can Support Now

  1. Determine how much Lean-Agile your organization can support now with your current culture.

  2. Explicitly tell the contractor/supplier your chosen degree of Lean-Agile for this project. We recommend a face-to-face meeting for this communication.

    To avoid buyer and contractor/supplier expectation mismatches and much consequent Lean waste, the buyer should share their Lean-Agile hybrid tailoring decisions. A contractor/supplier assumption that the buyer has decided to go 100% Lean-Agile when they have not will create communications waste and relationship issues.
  3. Buyer’s leadership intervenes if the buyer organization begins to revert back into traditional waterfall approach mid-project and does not stick to the Lean-Agile hybrid tailoring decisions you have made as an organization.

  4. Decide whether courseware instructional/LX design can emerge in the iterations or if a courseware design document is desired up front.

  5. Review buyer’s existing governance policies to ensure they allow for Lean-Agile and don’t create unintended obstacles.

  6. Create new governance policies that accommodate Lean-Agile as appropriate.

  7. Ensure you can allocate SMEs and stakeholders for iteration demos/reviews.

  8. Develop a new culture plan to realign your culture to more successfully fit Lean-Agile.

Market Research

  • Identify contractors/suppliers.

  • Interview contractors/suppliers as needed.

  • Notice training conference presentations which are beginning to include using Agile for courseware projects.

  • Interview other organizations that have attempted Lean-Agile to see what they learned and to avoid mistakes they unintentionally made.

  • Look at the types of contracts being used to purchase Agile software. Determine which contract terms and conditions cross domains into training and which do not.

See how your organization buys custom software products. It is likely that those involved already use Agile and that you may be able to leverage from their experience.

Define the Project

For traditional projects, requirements scope is fixed while costs and schedule are variable. For Lean-Agile projects, costs and schedule are fixed, and requirements scope is variable. This is key to the benefits that Lean-Agile can provide. Efforts to make all three elements fixed will increase project risk.
  1. Treat the budget and schedule for the project as fixed.

  2. Treat the requirements scope as variable and prioritized for highest buyer value to get the highest priority work at the end of the cost and schedule. Lower priority requirements may not make it. This is okay and is the goal with Lean-Agile.

  3. Determine the training need and gaps as you have always done (i.e. Training Needs Analysis).

  4. State the performance deficiencies that will be addressed.

  5. Document goals and objectives. If you are a government buyer, create the performance work statement (PWS) or statement of objectives (SOO) in a way that does not unintentionally constrain Lean-Agile.

  6. Establish design assumptions, freedoms and constraints (i.e. exploiting existing training, accessibility, technology infrastructure, etc.)

  7. Warn stakeholders that there will be no long up front detailed plan, but that more like rolling wave, details will be planned closer to the work beginning.

  8. Draft the requirements

  9. Prioritize the requirements in highest-to-lowest customer/stakeholder value order—to help trade-off lower priority requirements for the highest priority requirements.

  10. Prioritize the most technically challenging and highest priority work items the highest as a risk mitigation method. This is instead of the order in which the learner experiences it.

  11. Visualize the requirements as a prioritized stack of backlog items or Kanban cards.

  12. Require contractors/suppliers to provide visibility into complex technology components that are in process for your stakeholders. The preferred way is seeing snapshots of their Kanban board.

  13. Set the iteration length (for example two weeks, or four weeks) based on the degree of risk mitigation desired. Two weeks has less risk than four weeks.

  14. Read requirements written in user story format—"As a role, I want functionality/content, so that business value."

  15. If defining interaction types, then describe your desired interaction types as user stories.

  16. Require a prototype of each interaction type in early iterations to mitigate risk.

  17. Identify acceptance criteria for requirements.

  18. Build your own risk register or require the contractor/supplier to build it.

  19. If you are a government buyer, be sure that your Independent Government Estimate (IGE) uses a similar approach or is factored appropriately for the Lean-Agile project management approach.

  20. If you are a government buyer, be sure that your Quality Assurance Surveillance Plan (QASP) methods of assessment account for the built-in quality approach in Lean-Agile rather than forcing additional steps all at the end.

    Look to how the QASP is created for Agile software projects for a good start. Keep in mind that learning experience development has less automated testing possible today than software, so test driven development is still a far off objective today.
  21. Evaluate your QASP to see if it unintentionally creates Lean waste.

  22. Establish stakeholder consensus.

Clarify Roles and Responsibilities from All Involved

Let stakeholders know what to expect from a Lean-Agile courseware project.

  1. At the beginning, identify someone to document your lessons learned in the experiment to adopt Lean-Agile to facilitate an easier path on future experiments.

  2. Update your process overview for stakeholders not familiar with details of training design and development.

  3. Set the expectation for no Gantt charts. Fixed iterations every two weeks are the schedule. The plan does not drive the Lean-Agile project, but the value (priority) does.

  4. Clarify with your auditing group what changes will be necessary to use Lean-Agile (i.e. using work item cards as records) and still be able to trace the sequence of events and decisions leading to a training solution.

  5. Structure the project Buyer’s team for fast decision making. Set expectations for all stakeholders to respond in minutes or hours rather than days to avoid them impacting the Lean-Agile project adversely.

  6. Assign a product owner who is empowered to make decisions for the stakeholders and give direction to the contractor/supplier.

  7. Assign the Product Owner the responsibility and authority to prioritize all work items in the courseware backlog to match stakeholder priorities and to internally referee any conflicts.

  8. Assure stakeholders that content and functionality of courseware is still constrained by learning objectives just like with traditional ADDIE approaches.

  9. Assign stakeholders to attend each synchronous, end-of-iteration demonstration to provide feedback to the development team.

  10. Assure SMEs, if you are providing any, that SME effort during design and development is the same amount of effort, just distributed differently from traditional projects.

  11. Inform your stakeholders that the project will use actual courseware increments delivered by the contractor/supplier instead of extensive documentation to have less surprises, less "trust us" and more "show me."

  12. Inform your stakeholders that the primary cadence method is the use of fixed-schedule time boxes for each iteration, meaning no re-schedules for demos/reviews. The scope of each iteration is all that varies.

  13. Let your stakeholders know their engagement will needed during iteration demos every iteration.

  14. Let your stakeholders know the project specifications will be documented using courseware backlog item cards on a Kanban board instead of a really long MS Word file.

  15. Prepare stakeholders and SMEs for courseware increments rather than lessons or the entire course at once.

  16. Inform your stakeholders for a more collaborative and less adversarial relationship with contractors/suppliers because iteration demos allow transparency of progress.

  17. Inform your stakeholders that quality checks happen earlier and the project will have improved buyer opportunities to give feedback to the contractors/suppliers development team.

  18. Inform stakeholders that changes can incorporated even late in the project life cycle by swapping out similarly sized lower priorities for higher priorities.

  19. Prepare stakeholders for higher frequency inspections and evaluations of smaller deliveries, called working courseware increments, than they may have been used on traditional projects. Same effort, distributed differently.

Organizational Adjustments to Buyer Process Documentation

Goal: Ensure buyer’s traditional methods do not contribute to Lean-Agile project risk.

  • Adopt a uniform taxonomy for Lean-Agile so that all stakeholders/customers and contractor/supplier staff are aligned in communication. See the glossary of this book as a starting point.

  • Give those involved new performance expectations ("Help us revise our processes to use Lean-Agile." "We will support not meeting existing process steps.")

  • Review traditional processes with the contractor/supplier before award to identify the scope of change to existing buyer-internal processes.

  • Evaluate using a Lean-Agile set of processes to be used for Lean-Agile projects.

Execute Strategy

  1. If you are a Government buyer, consider a draft request for proposal (RFP).

  2. If you are a Government buyer, issue a RFP.

  3. Select the right contractor/supplier.

  4. Award the contract.

  5. Finalize your Lean-Agile aligned QASP.

  6. Conduct a post-award kick-off meeting with the buyer team and implement transition period, if applicable.

Consider tasks on this list for your post-award implementation/transition.

Performance Management

  1. Build and manage the relationship with the contractor/supplier.

  2. Assess performance.

  3. Train buyer project manager in Lean and Agile as applied to training.

  4. Monitor the contractor/supplier Kanban board snapshots for minimal WIP inventory, to help ensure your desired changes can be negotiated for swap-out without minimal rework.

  5. Conduct a buyer-internal-only stakeholder meeting after the first iteration demo/review because everyone’s expectations will have become even clearer after the first iteration demo conversations as you inspect and evaluate one courseware increment.

  6. If you are a Government buyer, some of the contractor’s performance metrics artifacts will be the work item cards on the Kanban board.

    Insistence on reformatting everything from the Kanban to other formats is a form of Lean waste. Look for ways to incorporate Kanban board data. Consider periodic photos of the board as record-keeping artifacts.
  7. Restrict scope changes to the beginning of each iteration as the contractor/supplier conducts their iteration planning meeting. Do not expect scope changes in the middle of a fixed iteration.

  8. Join the contractor/supplier iteration retrospective to identify lessons learned at the end of every iteration.

  9. Join the contractor/supplier iteration planning meetings to monitor how well the development team feeds forward lessons learned for continual improvement.

As the customer, the buyer should not take over these contractor/supplier meetings when there to observe and become informed of the team’s progress. Leave the development team the time to conduct their meeting. The Product Owner, Lean-Agile Coach and the Development team are responsible for these meetings. Anyone else is an observer. If you attend, shift your thinking from oversight to insight. Hold your comments and questions until after the team breaks and goes back to work to avoid meeting waste. Remember, Lean-Agile emphasizes partnering with the contractor/supplier.
Look at the development team task list for continual improvement tasks to see how much "managing continuous improvement" varies with Lean-Agile instead of the traditional waterfall approach.

Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview