The biggest change for buyer’s staff is moving from large batch to small batch. Lean’s small-batch processing means we only work on a few items at a time, completing one, and then moving on to the next work item. This changes the experience of all involved. Anyone formerly used to large-batch processing has most of their expectations altered by this small-batch processing approach. The following figure shows the change in approach.
The easiest way of describing this is large-batch versus small-batch. Traditional ADDIE is often performed in large batches. The following figure depicts all the work for analysis performed on the entire course before moving to design. The entire large batch gets processed before anything moves on.
The next scene in the large-batch movie of progress shows the entire course moving to the next phase. Again, all the design work for analysis is performed on the entire course before moving anything to development. More of the work waits on the rest before proceeding through the workflow.
As the large-batch movie continues, yet again, all the development work gets performed on the entire course before moving anything to implementation.
Okay, that’s enough of that movie to see how it plays out. Now let’s switch to small batch processing.
Contrast the previous large-batch movie of progress with the following small-batch movie of progress. Scene one shows the team working on smaller chunks of the course. Smaller batches of work effort move along the entire workflow without waiting until the entire course is processed for that workflow step.
As we continue to watch the small-batch movie, scene two shows the team continuing to work on smaller chunks of the course. Note that the improvement ideas they come up with (illustrated by the dolly) do not have to wait until the entire course is processed to be applied. These improvements tend to speed the workflow.
The preceding series of batch movies shows the big picture.
Next, let’s drill down to another level of detail. Rather than just simple blue boxes, now we’ll depict training-specific work items. The following figure shows the work effort for each ADDIE part of the workflow represented as A for analysis, LO for learning objective, Eval for evaluation (formative or summative), LL for lessons learned, and Pilot for validating the courseware with sample students, etc. Note that the granularity of these work items is intentionally lower than lessons, and reduces in size to learning objectives (LOs) instead. This is because LOs tend to vary in size of effort less than lessons tend vary in size of effort.
Just as the preceding large batch movie, the following large batch movie performs all work items in one large batch for each step in the ADDIE workflow.
Now for the Lean-Agile mind shift. Let’s switch to small-batch processing, and have the following small-batch movie showing the detailed work items too. The entire courseware effort has been split into ten iterations. This small-batch movie will only show a single iteration. Also because we’ll cover Lean-Agile planning in later sections, we’ll start this movie from Analysis.
When this movie ends for iteration one, the iteration’s scope is complete. Note that only ten LOs are included in the increment’s scope, in this example, rather than the entire course worth of LOs. Each LO shows some design and development effort. The lessons learned are distributed across the iterations too, allowing the team to make improvements sooner.
When this movie ends for iteration two, the following scope is complete with both iteration 1 and 2 work done.
Adding one iteration batch at a time continues until the entire course is done. When all the Agile iterations are done, the course is completed. The following figure shows how each small batch was completed like a layer cake.
Notice that instead of the buyer stakeholders reviewing the entire course analysis, and then much later reviewing the entire course design, and then later reviewing the entire course development, Lean-Agile changes the approach. They buyer’s stakeholders using Agile will interact with the development team more frequently because each iteration is only two weeks in duration. The buyer’s stakeholders do NOT need to spend more time reviewing the courseware increments when using Agile. Instead, they simply split the large batch of review effort into smaller batches of review effort and perform those smaller efforts more frequently.
Some organizations stakeholders initially seem to prefer to focus on scheduling their stakeholders efforts, like they were traditionally used to doing. Then we help them realize that the traditional scheduling of a large chunk of time was a countermeasure to address the difficulty of finding such large batches of review time. Large batches of review were so disruptive and hard to find that they compensated by scheduling it as far in advance as possible.
To help change the mindset, we sometimes coach stakeholders about why their more frequent collaboration is so vital at each iteration, and how the feedback provided improves quality and reduces the buyer organization’s risk by inspecting what they expect every two weeks rather than waiting longer and potentially having more hidden issues get discovered later in the project lifecycle.
It has proven helpful to remind all involved that the earlier we can fix expectation mismatches or defects, the less risk exists to both schedule and budget. When they see that each iteration only requires a 1–2 hours of their time rather than 10–20 hours, then they are willing to try it. Because the increment size is constrained by what can be built in two weeks, it tends to be more manageable in a short iteration demo/review.
Let the buyer’s reviewers know that the iteration demo is the main place for feedback to the development team and for review of key areas.
Let the buyer’s staff know that the cadence is faster than with traditional projects.
Though the demo does not prevent personal asynchronous reviews outside the demo, it is critical that all reviewers stay in-flow with the short cycle times.
The task to referee potentially conflicting feedback quickly still applies with Lean-Agile.
The buyer’s people are needed more frequently, but for smaller durations. In the end, the amount of time each person spends reviewing should be the same as a traditional project, but it is distributed across each iteration rather than batched all at the end of the development lifecycle.
Let buyer SMEs know that our instructional/LX designers may seek feedback more frequently.
Our instructional/LX designers may request input with a short turnaround expectation, but the scope is small, so it should not interfere too much with their regular duties. The benefit to buyer SMEs is that rather than having to switch their attention back and forth amongst work items in the entire course, they only have to focus on the courseware increment based on the committed iteration goal for that two weeks. This one-piece flow helps reduce what Lean calls ‘context switching waste’ when people have to wrap their head around something they haven’t touched in a while. This prevents our requests for SME support from wiping out the SME’s entire day. Supporting only a small work item per day means the calls with us are typically short. SME timely responsiveness is still crucial to maintain the fast cadence both parties are using.
Notify the SMEs of key input period.
It is important for the buyer’s SMEs to note the timing of the courseware increments on the schedule because this is where the majority of their inputs are required. SMEs may also want to review the backlog to see how the LOs they need to support are prioritized. This helps the buyer’s SMEs allocate their schedules better.
The iteration retrospective meeting is an integral part of the Plan-Do-Check-Adjust (PDCA) process.
So if buyer staff want to bring up an improvement, the demo is the place for it. They should not wait until the end of the course development lifecycle to mention their change or improvement idea.
Because the buyer will have many chances to redirect priorities, be cautious of using an antagonistic stance between the buyer and the contractor/supplier.
Lean-Agile includes a principle of respecting people. Lean-Agile aims at frequent collaboration between the buyer and the contractor/supplier. This collaboration is aided by a friendly tone of communications between both parties. Because you will know more surely the state of the progress during the lifecycle, it is less necessary to start off using the contract as a bludgeon, or behaving as if all contractors/suppliers are out to take advantage of you. Use the data from each iteration demo to determine how to respond to the contractor/supplier.
Be sure your stakeholders know the inspect and adapt or PDCA cycle of Lean-Agile is intentional.
Every engagement between the buyer and contractor/supplier includes some degree of getting to understand each other and what is meant by specific statements and behaviors. Even the best thermostats overshoot as they transition to the target. If buyer stakeholders want 'zero defects' or think of adaptations as failures, and they interpret those adaptive efforts as bad, then the buyer will have uncomfortable meetings. It is better to set that expectation up front. All endeavors with humans have some degree of adaptation. Lean-Agile has a systemic way of moving both the contractor/supplier development team(s) and the buyer’s staff and stakeholders towards improvement. Lean calls it 'strive for perfection', ISO 9001 calls it continual improvement. Agile has mechanisms to ensure these improvements are getting incorporated into your project. Conduct a communications campaign with all stakeholders during kickoff meetings to help this be a common understanding among all parties. Help stakeholders notice the accretion of adaptive improvements over the project lifecycle and help them interpret that as a good thing.