We have to work within a traditional project management culture for the enterprise, so we still perform planning up-front for the project-level/program-level.
Analysis moving analysis to Agile could be the scope of an entire other book, so we will not address it in this day in the life example.
Design, meaning the course design document—course level design. Moving design to Agile could be the scope of an entire other book, so we will not address it in this day in the life example. We have written a section of this book just on Agile Design.
Learning experience development is where the bulk of our day in the life will be illustrated.
In Lean-Agile, the instructional/LX designer gathers the dispersed team on the phone at the agreed time, and someone starts a 15 minute timer. The team looks at the Kanban board together (virtual or physical), and they discuss what needs to be done, basically applying PDCA at the daily level to keep the project on track. A team member added a "blocker" visual signal to the work item card that cannot be done now because SME#1 is unavailable. The entire team sees the blocker signal and there is a brief discussion about it. Everyone can see if everyone else’s committed work is progressing as they said it would or if there are problems. There is no sliding along in this visual environment. All of them are involved in solving the team’s problems together. Observers have been asked by the project manager not to interrupt during that 15 min daily synchronization meeting, but to hold their questions or comments until later. The Agile Coach may remind the team to apply a particular Agile principle slightly differently as needed.
After the meeting, the instructional/LX designer may have a one-on-one discussion with one of the team members to clarify details on something or another. Other team members will look at the board and pull a work item card into their WIP column and begin work. They all heard the customer say they wanted XYZ different in the next iteration, so they all do that as they do their work items. When completing a work item, the team member "tests" the work item against the checklist that we use of manual test cases to confirm that the quality is sufficient to call the work items "done." If the work item passes the test cases in the checklist, then the team member pulls the work item card from the Work In Process column on the Kanban board and into the "Done" column, which is the ready column for the next step in the development workflow/process.
Because this is training after all, the instructional/LX designer’s storyboard progress is the drum beat of the team. Without that, the team stalls. So assuming the instructional/LX designer is caught up on the storyboard, then the other team members take work items to make the storyboard a reality. If the instructional/LX designer has to do more storyboards, then the team pulls the defect/change request work item cards and fixes those. Everyone knows they all have to demo/show the customer stakeholders another increment of working courseware in the two-week countdown, so a sense of urgency is present. They want to get it right, so the customer stakeholders like what they see.
The Agile Coach sees that new team member, JoAnn, does not seem to understand how to apply the current Agile methods and takes a minute after the meeting to coach her.
The team may indicate they have an impediment, in that SME#1 is unavailable, and the lead SME is also not responding. The project manager may have to help fix the SME issue to remove the impediment.
The project manager needs an update on where the team’s progress is, but instead of interrupting their work, he or she simply looks at the Kanban board to see where the progress is and if there is a crisis that need to be addressed. The project manager also buffers the team from other interruptions, such as organizational metrics seekers by providing that data for them, so the team can work on the learning objectives without context switching waste.
The project manager may have to remind an organizational leader about WIP limits because they asked why so few work items are showing "any progress" at a time.
The SME’s manager calls to bear the bad news that the loss of the SME#1 is unavoidable, so the Product Owner pushes that LO work item to the next iteration and brings another LO from that next iteration forward in its place. The instructional/LX designer notes that he or she will need to point out at the start of the next iteration review/demo that LO#34 moved to the next iteration and that LO#47 moved up to this iteration.
The instructional/LX designer calls SME#4 to remind her that the job-relevant case study details she is working on are due tomorrow.
At the end of the day, one or more LOs are done—meaning ready for student use—and put into the “Ready for Iteration Review” ready queue. This is the one piece flow in action.
This day in the life does not include the pilot because that is the same as without Agile so far. I’m open to your ideas about how to improve that. We do track the defect/change request work item cards on the Kanban board after the pilot to see how close we are to delivery of the post-pilot courseware.