Wednesday, June 25, 2014

Why competency-based learning is not enough

Critique-based learning and my virtual talk on education in 2025 say much that is also said by proponents of competency-based learning, including the emphasis on proficiency over seat-time, multiple pathways through a curriculum, formative over summative assessments, and teachers as mentors not graders.  When Success Is the Only Option by Sturgis and Patrick as an excellent overview of the ideas of CBL.

So is all I'm saying really CBL? Is CBL sufficient to define what education needs to be? Let's look at two large examples of CBL: the Florida Virtual School curriculum and the 2014 Western Governors University course catalog (course listings start on page 40).  What you see there looks identical to the courses you see offered in any traditional curriculum: Chemistry I, College Geometry, US Government and Constitution, etc. Compare those courses with the role and story driven offerings suggested by slide 21 of my virtual talk or actually offered at XTOL.

CBL is built on the same broken discipline-defined foundations-first content structure of traditional curriculum. Competency rather than seat-time is the right idea -- but competent in what matters just as much.

Friday, June 20, 2014

Education: So much to critique, so little time

I don't mind giving talks but I suck at sending things to conferences.

So I created a standalone virtual talk on what's wrong with education -- it's a long list --  and what it could be like instead. You can see it at Roger Schank's Engines for Education site.

Scrum Grumps

In my software development course at Northwestern, I emphasize early delivery of value and team development. I start with the second and move to the first over the 10 weeks of the course. I constantly refer students to those whose ideas have fed into my understanding of lean agile, including DeMarco and Lister, Brooks, Weinberg, Beck, Cunningham, Jeffries, Cohn, Rothman, Rasmusson, Ries and many more.

The one big thing I don't do is claim to teach Scrum. I teach most of the parts, such as user stories, backlogs, velocity, and daily standups (not "scrums"), but there are a couple of terms I avoid and actively un-teach when students come across them.


Sprint says run like crazy, but not for very long. I know that's not what "Scrum Sprint" means but that's what "sprint" means. Words matter. I want my students to see development as steady loping, not repeated mad dashes. There's just one sprint in my course: a hackathon at project start to get the very first testable slice to the client. This first mad dash has benefits for the product, developers, and client-developer relationship. The one bad side is technical debt but the code base is still small and you have plenty of time to pay off technical debt. I use iteration.

The length of sprints, from two to four weeks, is also problematic. For anyone new to agile, I prefer one week. Move to two weeks when things are humming along -- or move to continuous delivery and drop iterations all together.

Scrum Master

[Edited January 30, 2017]: Master? Words matter. Master sets up a power relationship with developers I am not at all comfortable with. Even worse,  here is how Scrum Master is defined in the Scrum Guide:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

No wiggle room here. A Scrum Master is an enforcer. The Scrum Master tells you when you are and are not doing Scrum properly. This is about as far removed from a role I would want someone to play as can be.

What do I teach is the needed? Agile coaches.  The role of an agile coach is to help you identify ways in which team and business needs could be better served. An agile coach is good at
  • detecting when things are going off the rails before the team does
  • identifying counter-productive processes and attitudes
  • suggesting simple and effective things to try to improve the development of both the product and the team
  • making these ideas real with stories from personal experience and case studies


My minor grump is the definition. The Scrum Guide defines an increment as "the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints." This is an odd use of increment. In normal English, an increment is an increase or addition, not the accumulated total.

But my real grump is with the commentary under the definition of Done: "Each Increment is additive to all prior Increments." I am not the first to note that an additive view of implementation fits very poorly with the realities of product development. I use version with no commitment to steady growth. Build-measure-learn.