Save Dr. G

Human Success and Failure Modes

Cleaning my office after an unfortunate shelving disaster, I came across a cheat sheet from last semester's CS222 class on which I wrote a reminder to myself of Alistair Cockburn's Human Success and Failure Modes. It seems I can never find this when I want it, so I'm copying it here. Interested parties should read his excellent book on agile software development as a cooperative game. In his book, he presents these as considerations when developing a methodology: a methodology that relies on failure modes is less likely to be successful than one built on success modes.

HUMAN FAILURE MODES

• making mistakes
• preferring to fail conservatively
• inventing rather than researching
• being creatures of habit
• being inconsistent

HUMAN SUCCESS MODES

• being able to look around
• being able to learn
• being malleable
• taking pride in work
• taking pride in contributions
• being good citizens
• taking initiative

At some point, I would like to compare these results to the research on pedagogy and explore the correlation between his workplace-oriented perspective and what is know from the science of teaching and learning. For now, I need to finish cleaning the broken glass off my desk...

Current CS222 students: we'll be talking about this soon, probably once you start up your six-week projects.

See Morgan's Raid at the Student History Conference on Feb 25

Tomorrow, February 25, my students will be demonstrating Morgan's Raid at the BSU Student History Conference. We will be in SC304, and sessions begin at 9:15, 1:15, and 2:45. Each session will have a short (~10 min) presentation about the ideas behind the game, and the rest of the time will be open to demos and feedback.

Morgans Raid: Sprint 10

Last Friday was the end of Sprint 10 for the Morgan's Raid team. Here's the burndown:

In Sprint 10, the Sprint Planning meeting was held while I was away at the administrators' retreat, so the students had complete authority. There were a lot of small user stories this sprint, and there was confusion between me and the team regarding whether certain stories were committed but not on the sprint burndown, or whether they had brainstormed some tasks for non-committed user stories. I'm not sure that the burndown chart is accurate: the first dramatic dip may have been a miscalculation. The real lesson here, then, is one of communication: I don't think we talked about the phenomenon adequately until two weeks later at the Sprint Retrospective.

Speaking of the Retrospective, I think the team continues to do great work. I feel that there is a real team identity and that they trust each other. They're really a fun group to work with, and I am saddened when I am called away from them to work on mundane tasks such as committee meetings or advising.

Today, we're heading out to an Indianapolis-area elementary school to do some end-user testing with our current prototype. I'm quite excited about it, and word is that there will be press from both BSU and the Indy Star there. The only downside of the story comes from my efforts this morning to clean up just a few loose ends before the playtesting. There is still a lot of cruft in the codebase, things that should be embarassing but I fear the students still either (a) don't see as ugly or (b) don't consider it worth fixing. Here's an example: there are four different cinematics in the game and they are all driven completely by YAML configurations. Despite the fact that each only differs in which configuration is loaded and what follows the cinematic, folks last semester implemented four different classes for these features via copy-paste coding. In each one, mouse clicks were incorrectly handled by polling in the update method rather than by overriding mouseClicked. To fix the bug wherein mouse clicks were sometimes not recognized, I had to go change this in four places. Since we are literally hours away from end-user testing, the last thing I wanted to do was introduce any risks into the system, but you can bet that before the weekend, someone is going to fix this.

I was inspired by Martin Fowler's recent article on the Tradeable Quality Hypothesis, which can be summarized by the statement, "You cannot trade quality." In the Sprint 10 Retrospective, we talked briefly about how I felt that the students were developing some sense of programming aesthetics, a skill or perspective that I have been contemplating for some time. Working side-by-side with students on design, analysis, and development still seems to be the best way, although it does not scale, and my other job responsibilities are not always conducive to this end.

Brontosaurus and BDUF

My 4-year-old son loves dinosaurs. He draws them, he pretends to be them, we read about them, we tell stories about them, and today we even we ate pancakes shaped like them. Many contemporary children's books on dinosaurs include types I'm sure I never saw as a child, such as carcharodontosaurus, deinonychus, and one of my favorites, therizinosaurus. My son could also tell you—since it comes up a lot—that there really is not such a thing as a brontosaurus. Turns out, what was called "brontosaurus" was really an apatosaurus, and since the latter name had historic precedent, it was the one that stuck.

Yet, in our family furor for all things dinosaur, we frequently find references to the brontosaurus. My first reaction to such occurrences is usually, "Why don't they know better?" A good follow-up question is, "How would they?" That is, why would the designer of, say, dinosaur-shaped pasta even think to investigate whether or not there really is such a thing as a brontosaurus? Second-order ignorance remains the malady of the ignorant.

My son's love of drawing recently blossomed, and it was initiated by a visit from my father—who, I should mention, is an excellent artist. My dad got my son into drawing, unlocking what must be an artistic skill and passion that skips generations. However, every time my dad drew a tyrannosaur, it was standing upright with its tail on the ground. These were fine drawings in their own right, but they also happened to be wrong. How would my father know that his archetypal dinosaur's posture is scientifically passé?

I was idly considering dinosaurs this morning when an analogy popped into my head: teaching children about brontosaurus is like teaching novice software developers to do Big Design Up Front (BDUF). For years, the status quo assumed software development was like manufacturing, and hence one can measure productivity in man-hours and lines-of-code. As long as you design it right from the beginning, all will go well. Of course, as far back as the 1970's, Fred Brooks was predicting agile methods. Despite the popularity of his essays, I have seen little evidence of their impact (q.v. the CHAOS report) until relatively recently, as "agile" is less frequently used as a profanity. From a modern perspective, we know that software development is the process of learning how to develop that software. By necessity, you know the most about a system when you have finished building it. This is why you always feel like you could do it better if you could do it again, or why you should always build one to throw away.

I look forward to a day when software engineers take a page out of modern children's dinosaur books: any time BDUF is mentioned, there's a an explanation that well-meaning people used to think it was a good idea, but now we realize that its really just a shadow of iterative and incremental design processes. The positive side is that I don't foresee BDUF-shaped pasta ever being included in Software Engineer Mac & Cheese.

Bloom meets Design Thinking

I have been working on a book chapter the explores many of the themes on this blog, particularly those relating to the Morgan's Raid project. Here is a sketch that did not make it into the chapter: an exercise in comparing Bloom's Taxonomy of the Cognitive Domain to a design thinking process.

I think the idea is compelling, but I have not had the time yet to fully flesh it out. My initial analysis revealed what one might expect: most of the design thinking steps explicitly involve cognitive activity at the highest level of the cognitive domain. Maybe there's something more there, and maybe there isn't. In any case, it was fun to draw.

Scrum Diagram RFC

I am working on a book chapter on the Morgan's Raid project, and I suspect that a visual representation of Scrum will be of value in explaining how it works. Specifically, I desire an information graphic that illustrates how we specifically have implemented Scrum. The diagram in The Scrum Primer is good but probably overly complex for the intended audience of my work. The CC-licensed one on Wikipedia is too general.

Here is my sketch (CC BY-NC-SA):

Grey boxes represent artifacts and data transformations. Blue boxes are meetings, and blue paths are "human paths". In a sense, I am trying to overlap a data flow diagram with a control flow diagram.

I welcome comments. I'll need to have something finalized within a week, and I'll plan on sharing the final result here, along with a summary of comments if they're received by email instead of posted.

UPDATE: Based on some of the comments, I made this alternative (also CC BY-NC-SA) that shows the data path from the Executable Release (nee Potentially Shippable Product) to the Sprint Review.

Winters at a Glance

The Star Press of Muncie, IN. Sunday, February 6. Page 1A.

What happens when the temperature drops below 0 inches?

Morgan's Raid, Sprint 9

Sprint 9 ended last Friday, and the team is doing great. Starting with the Spring semester, we are not using Google Docs for the Product and Sprint Backlogs, since now we have a persistent space in which to work. Since I don't have an electronic log of activity, then, it has become important that I archive a few of the details here.

In the burndown chart, green is steady progress and blue is actual progress. The bump around Monday and Wednesday coincides with the big ice storm, and the fact that we only had such a small bump is a testament to the team's commitment. A few team members were able to come to campus that Wednesday afternoon to hammer out the most ambitious part of the sprint: the implementation of the new raiding system. Others continued to work from home, using email and chat to keep in touch.

The team's total estimate of hours ended up being fairly accurate, although the specific allocation of estimated hours to tasks was off by quite a bit. The team recognized this and agreed to draw upon this experience in the Sprint 10 Planning Meeting. This meeting happened on Monday, but I still know nothing about it since I was at the strategic planning roundtable retreat. I left the team with a prioritized Product Backlog, and I'm eager to see how they chose user stories and broke them down into tasks.

A quick word about bowling

I just finished the first day of the Strategic Planning Roundtable, which is part of the administrators' retreat here at BSU. I am there as a member of the nascent Strategic Planning Committee, not as an administrator. I hope to write more about this experience in the coming days, but for now I want to share briefly my experience at our end-of-day event. We all went down to Jillian's in downtown Indianapolis for dinner and "crazy bowling."

We were formed into teams, and each frame of the game had a different theme. The first round involved using your non-dominant hand; the next had us throwing the ball without using the fingerholes; and this pattern continued with breakdancing, ballerina, backwards-through-the-legs, and pirate bowling. (By the way, I have determined that this last one is physically dangerous. The constraint is that you hop up to the foul line on one foot and throw the ball, while holding one eye closed. If you are not used to hurling 10-16 pound objects, doing it while on one foot can lead to significant muscle strain. I'm glad I brought Aleve.)

After the game, scores were tallied. When we were told that there would be another round, there was an audible moan. We did then play another round, same as the first, and then the winners got some prizes.

Two things struck me about this experience. The first and less important is that it was not Fun. (I will remind the reader that there are important distinctions between the colloquial "fun" and the scholarly "Fun.") At least on my team, we would have rather just bowled. Big-F Fun emerges---at least in part---from the balance of challenge and skill. Doing these little one-off silly tasks did not give room for skill improvement. The challenge far exceeded our skill, and so we were all just frustrated, essentially relying on random chance for points. As an alternative, knowing that there were prizes at stake, there was always the option to cheat, too. There were some laughs and a few lucky shots, but at least on my team, the general feeling was one of malaise, a frustration at our inadequacy to meet any of our goals and expectations.

This leads me to my second and more pertinent point: we pull this kind of crap on students all the time. We put students into uncomfortable situations, where their abilities will be measured against their peers, and where they have little or no existing skills. They do not know why they are doing what we make them do, and we do not give them the time necessary to develop skills that escalate with the challenge. Some people will cheat, and usually they will get ahead for it. Then, we're off to a new topic or a new class or a new semester, which may seem to have as little to do with the previous one as ballerinas to pirates. "Ballerinas? Pirates? I came here to get better at bowling!"

Now if that was the real intended lesson of the administration in planning this activity, I will be duly impressed.


Aside: I don't mean to be overly critical of the retreat planners' goals: they wanted a nice team-building activity where no one had an unfair advantage. I will be the first to admit that "team-building activities" are not my forte, and the lack of them has probably had negative impact on some of the teams I've formed over the years. I have developed a preference for designing situation where the team feels good about themselves by actually accomplishing something. I try to bring this into my teaching and mentorship by following an early win design: setting up a team so that on the first iteration, they have readily achievable goals that they can feel good about. This has been recommended in several of the agile software development books I've read, notably Cockburn's and Keith's, if I recall correctly.

Sandwich

When I conceptualize a sandwich, I generally think of it the same way that I perceive it, combined with memory of the flavors, textures, and emotional connotations. However, when I design a sandwich, I approach the problem from the inside out.

What is the feature of the sandwich? Roast beef. The point of this whole sandwich is that it is a roast beef delivery system. Now that I have decided on the feature with the most value, I can approach the rest of the design challenge as one of finding the best complements to the feature.

Cheese? Swiss. Roast beef and swiss just sounds right.

Veggies? Of course! Tomatoes, lettuce, some bell peppers, and for salty complement, a pickle on the side.

Condiments... horseradish sauce. Mmmm.

What's the best way to wrap this up? The bread is a key component, but it is a servant to the rest of the sandwich experience. Sure, sometimes the bread is the feature, like when my wife makes peanut butter and banana sandwiches on graham bread, but not this time.

Regardless of whether I was ordering this sandwich or building it myself, I would have to consider these ingredients in a different order. As a sandwich builder, I need to select my bread first, then spread the condiments, then stack up the fillings.

When you go to The Atrium at BSU and go to the deli sandwich counter, they have a touchscreen display for selecting what you want. It's screen-oriented, with the first (pertinent) screen showing breads, then meats, cheeses, vegetables, and condiments.

This sequence of screens is builder-centric. The order of selection is exactly the order that the staff behind the counter will use to build the sandwich. From each screen, you cannot see the options on the other screens, because they are not pertinent to the assembly-line approach to creating the sandwich.

The touch screen interface is less user-friendly than the paper-based system that preceded it. Previously, any number of clients could grab a sheet, check the meats, cheeses, breads, etc. that they want, put it in the bin, and wait for the sandwich. Now, you have to wait in line behind the single touchscreen station. I find that this pressure adds to my frustration, but I usually approach the counter without knowing what I want. That is, I use the sandwich design experience to explore both the design space and my own desires.

Also, they forgot my horseradish sauce.