Megan Torrance's presentation from mLearnCon 2015, Austin, TX. This is the overview presentation for TorranceLearning's LLAMA project management - the Lot Like Agile Management Approach - in which we adopt the best of the software world's Agile project management and combine it with solid instructional design techniques.
[lay this out as a question card, with supporting cards, on the table before class]
Things are changing faster than ever before, and the rate of change is exponential.
This change is being driven by:
New hardware and platforms
New software and tools
Globalization and localization
New development tools
Greater complexity (volatility, uncertainty, complexity and ambiguity, VUCA)
Post-recession continuing cost pressures
Increasing ROI pressure
But what happens when change happens AFTER it’s supposed to?
In any project of any size or complexity (in any project really worth doing), the client or sponsor really often only knows what they want after they've seen the first version. Then they can really hone in on what they want and what they need. Then the requirements shift and change as the project comes closer to each release. Where do these changes come from? They come from shifting business needs, priorities, new tools & technologies, new ideas. Said differently: Any set of meaningful requirements is subject to -- and should! -- change.
This doesn’t mean that EVERY new idea – squirrel! – is pursued.
... something that will help you estimate a project scope, cost and completion date with much more clarity.
But what happens when change happens AFTER it’s supposed to?
A learner persona = fictitious future learner
And a valuable member of your team!
They define scope. They are meaningful to sponsors and users. When we use Action Mapping to define stories, we then tie them to actual performance outcomes of the project.
This covers the WHO, WHAT and WHY aspects of design.
Small = 65
Medium = 235
Large = 579
Every project is one (or maybe two) type of project. Knowing which one it is is critical to making project planning decisions.
Fixed budget projects have no wiggle room to spend more money or time, even if it means we cut out functionality. You'll see this in strict budget-focused organizations and grant-funded projects, for example.
Fixed time projects have to be completed by a certain date. Sometimes that means that functionality gets cut. Sometimes it means that we add resources to the team to get things done. But the date is the date. You'll see this in projects that are or that support other well-publicized milestones.
Fixed scope projects are worked until they are completed. Sometimes that means that you need to spend more time or more budget completing them, but they've got to be right and complete in order to be of any value. These tend to be the rarest of the three.
Every project is one (or maybe two) type of project. Knowing which one it is is critical to making project planning decisions.
Fixed budget projects have no wiggle room to spend more money or time, even if it means we cut out functionality. You'll see this in strict budget-focused organizations and grant-funded projects, for example.
Fixed time projects have to be completed by a certain date. Sometimes that means that functionality gets cut. Sometimes it means that we add resources to the team to get things done. But the date is the date. You'll see this in projects that are or that support other well-publicized milestones.
Fixed scope projects are worked until they are completed. Sometimes that means that you need to spend more time or more budget completing them, but they've got to be right and complete in order to be of any value. These tend to be the rarest of the three.
The high level planning board has a column for each (sub)project, and row for each week.
Each week or so represents a goal (a sprint).The series of sprints (releases) follow the phase-wise plan for the project as a whole. Weekly planning boards should be to meet the big board sprint/release goals.Color-coded cards can be used to signal project starts, major releases and other important dates.
The weekly planning board has a column for each team member, and row for each day of the week.
The weekly board:
- Starts on the planning day (which doesn't have to be Monday),
- Shows all the (work)days of the week as horizontal rows
- Shows vertical swim lanes for each team member's assignment
- Displays all standing activities (weekly client check-in, staff meetings, etc.) and all tasks authorized for the week
- Includes a row for "pull ahead" cards (cards that have been authorized but don't naturally fit into this week)
- Allows for easy access to stickers, push pins, cards, etc. for planning.
Sticker dots make for great status tracking on each card.
Use the approach that works best for your situation.
A traditional Agile approach
Yellow = started
Orange = ready to test
Green = tested and ready for client
Red = blocked
Black = cancelled
At TorranceLearning we use this:
Yellow = started
Green = completed and ready for clientBlue = awaiting clientRed = emergency
You always have a running version of the program, eg, if you run out of time, you can deliver the last iteration, which may not have all functionality, but it does something. This is usually worth more to your instructor than a program which doesn't even compile yet. It helps identify the source of the last error (compilation or execution), because you know it's in the code you just added in this iteration. This makes finding bugs much faster. It's psychologically more satisfying to get positive feedback on your work, ie, a running program. Corrections early in development generally take less time than later in the development process.