Reflections on Agile Development


I learned over the summer that software development teams often use a process called Agile. The short version is that teams work in short cycles to create functional (but not polished) versions of a piece of software. Then they show it off to everyone and discuss bugs and other issues as well as next steps. This way, there is a constant feedback loop and no one team is given too much time to head down the wrong path.

So I decided to run our first project in AP Computer Science Principles using Agile Development. But I figured it was a bad idea to try to learn Agile and also how to write code at the same time, so we used this activity and made a Lego city using Agile development. Here’s our final product:


Nice, right?!

Here’s the rundown:

  • There are three roles in the process – Product Owner, Scrum Master, and Developers. For this activity, I played the roles of  Product Owner and Scrum Master, and the students were split up into 3-4 teams of Developers.
  • First, we needed what’s called the Product Backlog. This is just a list of the features of the city. For this activity, I had the list already done, so we just put each thing on a post it note and put it up on the board.
  • Next, we “estimated” each of the backlog items. This is where we decided about how hard each item would be to complete. We set up “lanes” on the board and took turns placing the post its into the lanes 1, 2, 3, 5, and 8.


The numbers 1, 2, 3, 5, and 8 are arbitrary. As in, they aren’t minutes or days or anything. It just means that if they decided a 1 story Lego building was a 1, then a 2 story building should be a 2 or 3 because it takes at least twice the work to get done.

  • After we had estimated the difficulty of each of the backlog items, we set about splitting up the work among the teams. This is called sprint planning. A sprint is just a short development cycle (we used 7 minutes for one sprint). Here’s our sprint planning board:


A few things to notice. Not all the backlog items were included in the first sprint. We only had 7 minutes, so we chose what we considered to be the most essential things for our Lego city and focused on those first. Also, one student did a little quick calculating there to estimate how many “points” each team would have to complete per sprint in order to finish the project in three sprints.

  • Then we set a timer and they went to work for 7 minutes. It was pretty hectic! After the time was up, a few of them placed the buildings onto the city board so we could review.


  • This is where I needed to let everyone know when I was playing which role. First, as product owner I basically tore apart their city. “The one story buildings should all be the same color!” “The hospital is too small!” “Where’s my bridge?”


Then I switched roles and had a “Scrum” meeting with each team. The purpose of the scrum meeting is for them to let me (the Scrum master) know what their team needed to be successful.


There was a lot of “we need more white pieces if we’re going to make this 1 story all one color” and “can we get a door with hinges?”. It was nice that I had withheld the fact that I had some special Lego pieces set aside (such as doors and windows) until they asked for them. This made the role of scrum master clear to them. I wasn’t answering questions like “how do I build this?”, just removing obstacles in their way of building. Later on, it should be clear that the scrum master isn’t there to help them learn to code (that’s the developer’s job!) but rather to remove obstacles in their way.

  • After the scrum meetings, we went back to the Backlog and planned sprint 2.

sprint 2.jpg

  • Then we repeated the entire process one more time, moving backlog items into the “finished” area as we went.

sprint 3.jpg

After sprint 3, the Product Owner was very satisfied with his city. We reflected on the fact that this happened through a process of quick bursts of working and then feedback. YES!! The point emerges!!

We used this same process for our first project in which they made a game in Scratch. I have a lot to say about that too, but I’ll save that for another post. I also wanna write more about my assessment plan this year because it is awesome! I haven’t “graded” a single thing this year.  I’ve given tons of feedback (formal and informal), and kids are giving feedback to each other. Beautiful! But that also deserves its own post, so I’ll hold off for now. I’ll write it up soon though, promise! 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s