If Not ADDIE, Then What with Michael Allen #astdtk13

These are my liveblogged notes from a concurrent session with Dr. Michael Allen.  I'm at the ASTD Tech Knowledge 2013 Conference kicking off today January 29, 2013 in San Jose, California.  Apologies for typos and incoherence.

Michael Allen CEO, Allen Interactions

ADDIE (Analysis, Design, Develop, Implement, Evaluate) – it just wasn’t good enough for him. He used to teach ADDIE with confidence. It’s hard to argue.  All of the pieces make sense and are defensible and naturally right.

But we’re pressed to produce a product that changes behavior and creates organizational impact – and do it on time and budget.  If we could do it better, faster, cheaper…

ADDIE’s origins – by the armed services when they needed a cookbook to create a lot of instruction fast by people without a lot of instructional knowledge. And it worked.

Over time, he has evolved ADDIE into Successive Approximation. (SAM)

We’re not after perfection, cuz you’ll never arrive there. Perfection is an impossible journey. But we can keep getting closer to the perfect solution.

Extreme programming, Agile, etc. is going on in other technical disciplines. They use the same principals of Successive Approximation.

Dr. Michael Allen’s Book: Leaving ADDIE for SAM (co-written with Richards Sites, Allen VP – he leads the Allen studio in Tampa)

What we’ll cover today:

• Why not ADDIE – too costly and not enough fun.
• Search for process must consider the desired perfect.
• ADDIE is too content-centric and not learner-centric.
• Agile – what are the bigger challenges and opportunities?
• SAM

If the model you uses gives you the quality products you want on time and on budget then stick with it.

Products need to meet expectations, achieves performance outcomes (it’s not about knowing), stays within budget, delivers on time, unites the team (builds enthusiasm and has everyone excited about the final project – especially if you’re doing it over and over. If it isn’t fun, then it’s really hard).

Agile Product Development

Manifesto (www.agilemanifesto.org):        

Continuous functionality (satisfy the customer through early and continuous delivery of software – every delivery is a usable product. Unlike in ADDIE where people look at a specification document but what they imagine is completely different. For each “sprint” you set required functionality that must be there, then target , future deliverables)

Changes welcome (Welcome changes, even late in development. At the end of the process you start asking yourself “is this what we meant to do?” – this stimulates late breaking ideas.)

Frequent deliveries (Work in two week sprints – deliver working software frequently. And you may throw out everything you did in those first few weeks. And that’s ok.  It turns the ADDIE question around from “what do we need” to “why wouldn’t this work?” We might find out in this process that we’re targeting the wrong audience.)

Buyer involvement (Business people and developers must work together DAILY throughout the project. “We’ll know it when we see it.” Agile is really good when the requirements change. Agile EXPECTS change. Nobody ever asks the senior leader to be involved – why not just ask? Allen tells the story of a project they did with Apple. They wanted him on the project – he said he’d only do it if the person who owned the project was also involved. This was the Chief Counsel. At Apple. So she was asked. And she participated and was fascinated by it.)

Minimum documentation (Keep the documentation as small as possible but as useful as needed.  Even storyboards have this problem. Think hard about what documentation is useful and needed.  Less is necessary when you keep putting product in front of the customer.)

Face to face communication (Written documentation is low on the communication totem pole of effectiveness. Face to face and a whiteboard is really effective. Open space with lots of white boards and in between.  People adapt to that and wear earphones.  We do have virtual teams but we mostly work together. Use Skype a LOT.)

Iterative and incremental (Keep doing things in small steps and build on top of them. If you mess up something in the sprint that was already built, then you have to fix it in that sprint. The product gets more and more complete.)

Breadth vs. depth (We go from one content area to the next and we avoid perfecting things. We do a once over – build the bottom layer of the cake. As we go into other content areas, we see ideas that would be useful in earlier areas. We want to discover those synergies. So then we build the next layer of the cake. This is hard for developers, because they like to perfect things as they go.)

Continuous testing

JIRA – Project Planning Ticketing tool (we use this at Kineo US) great for itemizing all the tasks that needs to be done in sprints.

THE SAVVY START

Allen Interactions does a Savvy Start to kickoff meetings. They try for two days (could be 1-3 days depending on the project). Try to get offsite somewhere.  They spin through the SAM model as many times as they can in those two days. 1 ½ hour cycles to squeeze out all kinds of interesting information.

Ideally, the project owner (the Chief Counsel!) is in the room.

Quick initial evaluation:

• What do we think we know?
• Who are the learners
• What needs to change in their performance?
• What can they do now?
• Where do learners go for help now?
• What delivery means are available?
• What will define success?
• What is the budget? Schedule? Resources are available?
• Who is the key decision maker?

Try to get answers to these question before the meeting so you’re just validating them at the savvy start.

Get all the ideas out there as quickly as possible. And then mock up something as quickly as possible. Sketching is so important!

Sketching User Experiences, Bill Buxton

Sketching is not drawing – it’s about communicating ideas quickly and inexpensively. Sketching invites comments and suggestions. Easy to dispose of and nobody cares. Often the main content idea isn’t discovered until later in the process. 

Do a mock up – an iteration – and then ask “why wouldn’t this work?”

As a rule, throw out your first idea and then try something completely different.

People like their first ideas and feel wedded to it and proud of it. We need to let go of the first idea. Because almost every time, idea 2 is EVEN BETTER!

Three is the magic number of iterations. You get declining return. Two might be enough. Four might be needed.  But plan on three.

For iteration 3 you can borrow from the other two ideas.

Project planning comes AFTER the Savvy Start. Only then do we write a project plan and price it.

Agile based approaches can take a little longer than you expect.  To keep in time and budget you just stop doing iterations. 

Questions from the crowd:

How do you agree with client on contracting and scheduling?

Even with ADDIE there's a lot of strong customer education we have to do.  We have to show them that this is a different process. We have to walk them through it and say it's going to be different.  We do contracting just for the Savvy Start first.  And then they move into full budget.  Then they write up a plan and charge for that.  And the client could go build that themselves.