Managed Chaos: How I use Agile and Scrum in the classroom

Agile is great for developing software. It improves quality by committing to transparency and realistic estimates. It improves morale by putting creative people in control of their process and it gives stakeholders visibility into the process and the flexibility to change priorities (pivot for all you trendy wantrapraneurs out there).

And while Agile originated in the software industry, the principles and even the processes now exist outside of it. It works pretty well as a system in any place where there is inherent uncertainty. While traditional management methodologies seek to eliminate uncertainty by careful planning and enforcement, Agile embraces uncertainty as essential and builds teams and processes which can adapt to it.

Now think about traditional education. You have a lesson plan, you have a syllabus, the teacher assumes how will each student will absorb every lesson, how many hours of work they will need to put in to prep for a test, how best to learn each topic, etc. Then you sit in a class room for dedicated amounts of time, you get assignments to complete at home, and eventually, you are evaluated. Contrary to popular belief, a lot of this structure is there for the instructor — to make scaling education to 500 person lecture halls easier.

This might have worked okay in school (did it really? c’mon folks). But when you’re training adults in a fast paced, high-tech environment, is this level of certainty a wise goal? Further, even if we could codify learning to program or build websites like we have for English, algebra, or home economics, is that the best experience to prepare our learners?

Robert A. Bjork, Professor of Cognitive Psychology at UCLA was quoted in Wired recently as saying:

“If information is studied so that it can be interpreted in relation to other things in memory, learning is much more powerful.”

If the end result of training is that an engineer will be placed on a scrum team where they will have to embrace uncertainty, work with a team, research the unknown, estimate and communicate about work and demonstrate progress to stakeholders, why should our training operate in any other way?

Our weekly schedule at Acquia U

Acquia U is Acquia’s internal training program. We just wrapped up the first group. Check out the video for a really brief (2min) and succinct explanation of what it is.

I also gave a talk on our Drupal training methods and madness at DrupalCon Denver.


On Monday the team would have a planning session. We’d have a few major learning objectives for the week and I would have prepared a couple projects and on-the-job training opportunities. In addition, there would be a buffet of other projects to choose from. The teams would meet, size the work and decide on what they could commit to by Friday. Of course, estimating is hard when you’re an expert and even harder when all this stuff is new to you, but they did the best they could, and got better over time.


Daily scrum with the three sacred questions and some post-scrum discussions. Generally took about 20 minutes. In the beginning they were in “reporting” mode — giving me an account of their productivity. Eventually this transformed into a team planning and knowledge sharing exercise. The team also self-organized to force laptops out of scrum and other process enhancements.


Everyone at Acquia was invited to demos. It put the pressure on to not just do the work, but to polish it, to be creative and to impress. It also was a great chance to get public feedback, and integrate themselves into the company. Now, the first time they have to go up in front of a customer, or their entire engineering team with a new project, it won’t feel foreign.


I always say if you do one part of Agile, do retrospectives. Our weekly retrospectives let the participants tell me and our program director Kay VanValkenburgh what was and wasn’t working. They talked to each other about how to effectively work as a team. We used the time to reinvent the curriculum for the next week where necessary.

By staying agile and flexible, we created an environment which was:

  1. Flexible to adapt to the learning needs of participants
  2. Fun, but also rigorous with a high expectation of quality and commitment
  3. Authentic, where people have to have multiple roles and work as a team

What do you think? Would Agile work in your classroom? Would it have succeeded when you were in school / university?

Jacob Singh
CTO in residence at Sequoia Capital. Independent product and Engineering Coach Mediocre guitarist, singer, rock climber, point guard and baker Dedicated dad. American in New Delhi.
New Delhi