More #Agile and less #computers in the classroom

As a parent whose children are entering grade 1 and grade 2, I find myself being more and more interested and concerned about the trends and proposed practices that are being used in the educational system now and in the future. One aspect I find myself having concerns with is the addition of computers to the classroom. My concern is not related to the use of computers in general, but more to how computers are being integrated into the classroom activities themselves. As we have seen in Agile and in Software Development in general, adding technology to a system rarely improves the system by itself. In fact I have had experiences where the introduction of technology to an existing system has made the system much worse.

I find it ironic that as we are re-discovering new ways to collaborate in Agile, the educational system seems to be going in a different direction. In Agile, we are looking at non-technology solutions as a better way to collaborate and communicate. From User Story Mapping to Innovation Games to Silent Brainstorming to Paper Prototyping to UI Design Studio, we in Agile have discovered that getting the person-to-person communication maximized has an immediate and impressive effect. In addition, we have also discovered the incredible increase in communication and comprehension when moving from textual to visual communication.

The science behind Silent Brainstorming as a means to generate new ideas and innovate is startling. Steve Rogalsky made an excellent presentation at both Agile 2012 and SDEC12 on the topic. You can find the slide deck by following this link.

More Stickies less Texting

I understand that the computers will be used for educational research purposes and this makes perfect sense. Everyone I know consults the Oracle of Google daily. I feel the more concerning use of technology is to use technology to replace basic mathematical and communication skills. For example, I have heard that exercises will require the answers to be texted or emailed to the teacher. I understand that this is being done to increase the engagement of the children. Although this may very well increase the engagement of the children, I fear that the value of the skills being taught is being lessened. I also believe that any use of technology to perform mathematics that the individual cannot do without the computer is fundamentally wrong. The computer should be an aid for execution, not a replacement for learning.

More importantly, where are we teaching the critical thinking skills, creativity, innovation, and problem solving skills? These are the skills that will drive the economy in the future. I honestly can’t see how the addition of computers to the classroom will help in this regard.

I sincerely hope that group activities and group projects are still a critical component of the education, but how much better would the curriculum be with exercises in Silent Brainstorming? Teams would experience how to self-organize, facilitate, and that the best ideas don’t always come from the loudest or best speakers. There is an excellent TED Talk on the Power of Introverts by Susan Cain that you can find by following this link.


When my child’s teacher requires computers in the classroom, I know I will be asking for a description of how they plan to be used. I’ll probably even take the opportunity to discuss principles recently presented by both Steve Rogalsky and Susan Cain.

Our children are worth it. Spread the word.

#Agile Code Reviews

I must admit I was never totally sold on Pair Programming from the start. But I have started to come around and I was looking forward to discussing Pair Programming versus Code Reviews with a fellow co-worker who had done a lot of Pair Programming at his former employer. In the project we are both on now, there are extensive Code Reviews. These Code Reviews can last 1-2 hours with anywhere from 3-5 developers providing feedback. We were driving back to Protegra for a meeting so I thought it was a great time to discuss the Pros of Pair Programming.

Boy was I surprised.

I asked what practice he enjoyed better? Code Reviews.

Ok, but what practice was a better use of everyone’s time? Code Reviews.

Yeah Ok, but what practice did he find provided better feedback on the actual code? Code Reviews.

This definitely gave me something to consider. Now before I go on, I should provide some additional context. The developer in this case is young, quite intelligent and a great developer, inquisitive, social, and all around a good team member. I thought he would have preferred Pair Programming to Code Reviews. Especially since we discussed how Code Reviews can sometimes get sidetracked to focus on style issues rather than design issues.  Especially since he had considerable experience with Code Reviews previously and this was not his first exposure to them.

Nope. He liked Code Reviews. Here is why:

1) He gets feedback from the entire team and from people with different perspectives, experience levels, and in different roles instead of one person. Frequently he mentioned that no one ever paired with the architect so you always missed that critical feedback.

2) He found that many times the person he got paired with was someone with similar experience and expertise. So the opportunity to learn was somewhat limited.

3) He liked the retrospective aspect of Code Reviews and the ability to look back and learn after the work is done.

4) He liked how the code reviews changed the reviewers more frequently than Pair Programming. (I know you are supposed to switch who you are paired with, but this isn’t the first time I have heard the pairings are longer lasting)

So What?

So maybe Code Reviews aren’t a practice that has limited relevance in Agile? Maybe there is a place for them in addition to Pair Programming. Maybe it also depends on the team itself and the problem/solution at hand. I am aware of the benefits of Pair Programming, but if people find that Pair Programming provides limited design improvements and Code Reviews provide great value if they happen very frequently to shorten the feedback loops…..

Do we need Pair Programming if we have very frequent Code Reviews? Did Pair Programming arise due to infrequent or non-existent Code Reviews? I don’t know…

Last thought

The only remaining thing that troubles me is how Code Reviews can be confrontational and not invite input from all teammates. But maybe we can combine frequent Code Reviews with Silent Brainstorming to gather suggestions to facilitate a dialogue before the discussion starts in a Code Review.

Hmmm… I think I want to try that… Has anyone out there have experiences to share on how they have Integrated Silent Brainstorming with Code Reviews?