Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


3 Transformative Agile Ideas for Education

Three transformative Agile ideas for Learning Sciences

Chris Riesbeck

on 28 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 3 Transformative Agile Ideas for Education

Three Transformative Ideas for Education
Test-Driven Development
Minimum Viable Product
Agile Software Development
Extreme Programming (XP)
Lean Agile
Agile Manifesto
write code
write tests
run tests
fix code
This is a design process, not a testing one!
Requirements are unambiguous, testable
Builds a huge regression library
Enables rapid but safe code changes
Critical to have a hard definition of "done"
Only get to count features when all tests passed
first, set the deadline
then, estimate what you can do in that time
when time's up, count what got done
reflect, recalibrate, redefine, repeat
short timeboxes (1 to 2 weeks)
estimate how many test areas you can pass in that time
tests first, of course
reflect, recalibrate, redefine at each timebox end
Aren't courses already timeboxes?
"foundational knowledge," e.g., writing FOR loops, is not a viable minimal skill
start with just one useful desirable new skill
when learned, review and revise backlog, repeat
define a course syllabus
allocate weeks to each topic
fall behind syllabus
talk faster!
define a product, e.g., pension site
define what modules are needed
implement modules
define the minimum viable product
implement and deploy
user feedback defines the next release
timeboxes too long
no reflection and recalibration
tests in the wrong place
releases every month or two
iterations every week or two
Example: A Java course:
Skill 1: make web pages (static HTML)
Skill 2: make web pages with data in back (a little JSP or PHP or...)
Skill N: complex business logic (backend Java, MVC)
define the project
estimate how long it will take
set the deadline
miss the deadline
Timeboxed Iterations
write tests
while tests fail, fix code
start with a test (quiz, project exercise)
while fail test, read, do exercises
even more extreme
-- Google "continuous deployment
The real bugs:
Test-Driven Education
Timeboxed Iterations
I used to think that was a bug.
Courses should go as long as necessary.
Timeboxed Education
Minimum Viable Product
Minimum Viable Skill
Test-Driven Development
maintain a backlog of prioritized candidate features
backlog captures initial vision
backlog is not a schedule
syllabus = a backlog of prioritized related skills
not all students need/want all skills
Example: EECS 325
Do, fail, feedback, try again, repeat
minimum: a lot smaller than you think
viable: new and useful
product: not a mockup
Frequent low-stress testing
Testing for diagnosis not grading
Agile Development is a suite of "turn things on their head" ideas
The real goal is not agility
The real goals are earliest delivery of client value with minimal exposure to risk
The normal model...
The normal model...
The normal model...
The normal model...
The normal model...
Isn't teaching to the test bad?
Only if it's a bad test!
Um, the pressure is really on us now...
These goals exist in all long-term projects, not just in software development
Like designing courses
What if we applied some transformative Agile ideas to educational design?
cramming is the optimal strategy
"Will this be on the quiz?"
Do you really want to open that can of worms?
This could blow making the deadline!
Chris Riesbeck
EECS / Learning Sciences
Northwestern University
“Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006
Full transcript