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.
Wednesday, June 25, 2014
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.
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.
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.
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
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.
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
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
Increment
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.
Friday, April 11, 2014
Courage in Profiles
(For those under 100, the source of this title.)
At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.
Profiles are friction, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already know they want the services those sites provide and are willing to put up with some friction. Your fledgling app is unknown and probably not all that good yet. Users have no incentive to put up with any friction with your app.
Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.
"Maybe so," the teams reply, "but our app has to have user profiles."
I've yet to see that actually be the case with any team.
The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.
This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. Writeboard (recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.
The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.
This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.
Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.
So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.
Have courage! Put user profiles where they belong, on the backburner, off the main line of development.
At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.
Profiles are friction, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already know they want the services those sites provide and are willing to put up with some friction. Your fledgling app is unknown and probably not all that good yet. Users have no incentive to put up with any friction with your app.
Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.
"Maybe so," the teams reply, "but our app has to have user profiles."
I've yet to see that actually be the case with any team.
The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.
This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. Writeboard (recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.
The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.
This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.
Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.
So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.
Have courage! Put user profiles where they belong, on the backburner, off the main line of development.
Tuesday, July 30, 2013
My Rubric Rant
I'm a calm guy, really. Normal blood pressure, definitely not Type A.
Unless someone gets me started on rubrics for courses. In that case, get a fresh drink, reserve at least an hour, and don't expect to get a word in edgewise.
To save my voice and your time, here's my rant on rubrics in easy to digest PDF form.
Unless someone gets me started on rubrics for courses. In that case, get a fresh drink, reserve at least an hour, and don't expect to get a word in edgewise.
To save my voice and your time, here's my rant on rubrics in easy to digest PDF form.
Saturday, May 18, 2013
EBD: the right way to sell Agile
For quite some time, I've been summarizing agile development as "early and frequent delivery of value." But it has struck me that skeptics have a good reason to be unswayed by such a claim. Of course "early and frequent delivery of value" would be nice. Ditto "easy," "seamless," "fun to use," and all those other claims every product and methodology has promised since the beginning of marketing. It's quite right to treat such promises as so much hot air. What matters is what you deliver.
So instead, let's ask a few easy questions.
So instead, let's ask a few easy questions.
What's better for making decision, more evidence or less?Can I assume we all agree here? Next question.
What kinds of evidence are better:Still with me?
- user surveys or user observations
- historical data or last week's results
- expert opinion or actual measurements
Which kinds of evidence can you get from:Final question.
- requirements
- high-level design
- implementation
- testing
- deployment
How does the above flow of evidence compare to the evidence gained from weekly user tests on working code?
And this is how you explain agile to skeptics: It's EBD -- Evidence-Based Development.
Sunday, February 3, 2013
The Easter Egg Hunt: An Lean Startup Coaching Story (Really)
"Hey, Bobby! Guess what? The Easter Bunny left a whole bunch of Easter eggs outside! Wanna go find them? Follow me!
"Here's your basket. Start hunting!
"Whoops! Not in the house, Bobby. You gotta get out of the building.
"WHOA! Not in the street! Back up! Here, little guy, let me point you. That's right, look in the yard.
"Honey, don't give up already. You're not finding anything, because you're just standing there, looking around. The Easter Bunny hid those eggs. You gotta move around. You gotta look behind things. You gotta pick things up.
"That's better.
"Yay! You got one!
"Whoa! Where are you going, skipper? You're not done yet. There's a lot more out there. Don't stop with just one egg. Keep looking, guy.
"Yay! Another egg! And another! You're doing great now, Bobby. Keep going!
"Um, Bobby? Bobby? Your basket is getting awful full! Watch what you're doing. Some of the eggs you found are falling out of your basket.
"What, you gotta go to the bathroom? Oh, OK, come on in, then. But be careful! Whoa! Slow down! Don't run or you're going to tr...
"Oooooh, Bobby..."
"Here's your basket. Start hunting!
"Whoops! Not in the house, Bobby. You gotta get out of the building.
"WHOA! Not in the street! Back up! Here, little guy, let me point you. That's right, look in the yard.
"Honey, don't give up already. You're not finding anything, because you're just standing there, looking around. The Easter Bunny hid those eggs. You gotta move around. You gotta look behind things. You gotta pick things up.
"That's better.
"Yay! You got one!
"Whoa! Where are you going, skipper? You're not done yet. There's a lot more out there. Don't stop with just one egg. Keep looking, guy.
"Yay! Another egg! And another! You're doing great now, Bobby. Keep going!
"Um, Bobby? Bobby? Your basket is getting awful full! Watch what you're doing. Some of the eggs you found are falling out of your basket.
"What, you gotta go to the bathroom? Oh, OK, come on in, then. But be careful! Whoa! Slow down! Don't run or you're going to tr...
"Oooooh, Bobby..."
Subscribe to:
Posts (Atom)