Agile Project Management
The idea behind the Arduino Inventor Licence is for students to work through all nineteen mini-projects, gradually building their knowledge and skills relating to embedded systems. This could very well be achieved individually. At my school, the mandated pedagogy is Explicit Instruction (EI), so you could easily step students through each project. However, where EI falls down is in the 21st Century skills of communication, collaboration and even creativity.
Therefore, I integrated some contemporary agile project management processes into my instruction; using a combination of Extreme Programming (XP) and Scrum.
XP teams use a practice called pair programming, where two people sit at a single computer and write code together. This can really be an effective tool for building high-quality code and many people report that pairs get more work done together than they do when they are separated. It means you are constantly collaborating and communicating with your teammates. Programming is an intellectual activity: writing code means constantly solving problems and puzzles. Talking through those puzzles and problems with one of your teammates is a really effective way to so1ve them.
Scrum and Sprints
Product Owner and Product Backlog
For the purposes of teaching and learning, the Product Owner is the Teacher. In the real world this would be a client, manager or both. The Product Backlog is then established by the Product Owner. This is a list of tasks and features that need to be built for the whole project. The Product Owner keeps the project on track by continuously refining the Product Backlog. This is where the Scrum process is different to the cascade project management process, as each of the phases allows for evaluation and refinement and even re-visiting earlier design phases. Therefore, the Product Owner stays up to date on the needs of the project by adding, removing or re-ordering Product Backlog items. Any feature that hasn’t been included in a sprint iteration yet is fair game for the client users and the Product Owner to change.
Every item has four attributes: order, description, estimate and value. The estimate is the time taken for completion of the task or feature. The time scale just needs to be one agreed on by the team and might be hours or days. The value is another agreed on value, as a relative number, dollar value, or another way to measure or express value. This becomes an important part of the sprint plan later.
For the Arduino Inventor Licence, the Product Backlog was the list of nineteen mini-projects.
A Sprint is a timeboxed iteration of the problem solving process. It might be 2 weeks or a month. Ideally, for Technologies, a sprint would be one of the phases and future sprints may be another iteration, depending on the evaluation and refinement process.
At the beginning of a Sprint, the Scrum team decide the objectives that will be met by the team by completing the Sprint Items. Eg. developed the algorithms necessary to generate a solution
At the beginning of each Sprint, the Scrum team gets together for a Sprint Planning sessions where they choose what items, form the Product Backlog, to include in the sprint.
When Sprint Items are pulled from the Product Backlog, they are added to the Scrum Team’s Sprint Backlog. During the Sprint, all of the development work is focused on building the items in the Sprint Backlog. For example, in our Arduino Inventor Licence unit, the Sprint Backlog for Scrum Teams was something like this:
○ Item 1: The Clock is Ticking
○ Item 2: This Truck is Reversing
○ Item 3: A Cacophony of Dissonance
○ Item4: ET Phones Home
○ Item5: It’s Totally Random
○ Item6: Be Still My Beating Heart
○ Item7: No! The Blue Wire!
○ Item 8: It’s Just Not Cricket!
○ Item 9: Finger On the Button
○ Item 10: Curiosity Killed the Cat
○ Item 11: Good Morning Sunshine
○ Item 12: Burglar Alarmed
○ Item 13: I Love the Night Life
○ Item 14: It’s Just Impossible
○ Item 15: Sci-fi Soundtrack
○ Item 16: Play it Again Sam
○ Item 17: Wag the Dog
○ Item 18: Someone’s Been Sleeping in my Bed
This involves adding stories and points to each item in the Sprint Backlog. A Story is just a brief that you could write on a post-it note, with details of the task, how many points it is worth and who it has been assigned to. The points that each task or story is worth is decided by the Scrum Team and the points are relative. The main thing is that everyone agrees on how the points are allocated so that there is an even spread and that no-one feels unfairly exploited.
This is the Sprint Plan that was generally used.
|1||1.5 AB||1.5 RD||3||93-3=90|
|2||1.5 RD||1.5 AB||3||90-3=87|
|5||3 RD||3 AB||6||81|
|9||3 AB||3 RD||6||75|
|10||3 RD||3 AB||6||69|
|12||3 RD||3 AB||6||57|
|13||3 AB||3 RD||6||51|
|14||3 RD||3 AB||6||45|
|15||3 AB||3 RD||6||39|
|16||3 RD||3 AB||6||33|
|17||5 AB||6 RD||11||22|
|18||5 RD||6 AB||11||11|
|19||5 AB||6 RD||11||0|
Every lesson, the Scrum Team holds a very short Daily Scrum meeting where every person gives an update on their progress, what they’ll work on next and any issues they are having that is blocking progress.
Once a team has assigned a story point value to all of the user stories in the sprint backlog, they can use burndown charts to get a handle on how the project is progressing. A burndown chart is a simple line chart that shows how many story points are completed each day during the sprint. The burndown chart gives everybody a clear sense of how much work is left to be done at any time. Using a burndown chart, it’s clear to everyone on the team how close they are to achieving their sprint goals.The chart below is for a sprint with 24 points worth of stories over 30 days. Then every so often (once a week?) you can plot progress by adding up story points and plotting.
In conjunction with the burndown chart, students also used a Kanban board. Ours was electronic, within OneNote.
Most students handled this process well enough. In future, I will use Explicit Instruction for the first few items and then gradually release responsibility for the rest. A few teams needed constant monitoring to stay on track. For others, I am contemplating using Explicit Instruction throughout the course until they are able to handle the responsibility that comes with the freedom to manage a project at your own pace; even if responsibility is not fully released until the very end.
Sadly, because students come from classes where they are told what to do every step of the way and they don’t collaborate in teams for learning, many students cannot handle the responsibility that comes with the freedom to determine how they will manage their own learning. This has been a problem that we in Technology have been grappling with for years. However, I remain determined to involve students in project and problem based learning.