FIRST OFF, I’m expecting two audiences to be reading this: software producers and educators. So if you’re reading something and thinking, “Of course I know that!” or “Huh?!”, then that bit is for the other folk reading! Before I tell you why I used SCRUM in teaching, let me tell you why I never did so in a full-scale manner:
- Pupils need to be trained to a working methodology, for some classes it’s necessary to work with how they work due to time constraints
- Some work is individual work, particularly in controlled assessments
- Although SCRUM met all of the requirements of the senior leadership team, some of the artifacts look different. This lack of homogeneity makes their work more difficult and means some of your work can be missed.
- It takes time to grow your teaching practice into what you envision. I burnt out and quit the profession before I could do this.
Having said all that, the classes I taught using SCRUM were some of the easiest classes I taught with great pupil engagement and then some. Let’s break it down.
The SCRUM Board = Transparency
AS A teacher you’re expected to have a pretty good idea of what every single pupil knows and is learning with regards to the curriculum. It’s how we identify that a pupil needs to do some catch-up, sit which tier paper, choose appropraite projects and more. It’s also a vital part of our reporting, holding us accountable for our practice.
The SCRUM board provides this, it shows at a glance where everyone is. I can see which groups are lagging and which are storming by the burndown chart. I know what they’re working on right now, what’s done and what’s to do. Furthermore, teaching some hundreds of pupils in many classes, I don’t have to hold all of that information in my head at all times. The SCRUM board reduces cognitive load by visualising the required information.
As a software developer (I still use a Kanban board in my own work), on those days when you’re arriving at work and you’re not at your best, the SCRUM board again reduces cognitive demand. I can just look at it and know what I need to do and get on with it, I also have less information to hold in my head.
A lot of the bureaucratic work we do in both professions is for the sake of tranparency. It’s value is not just in accountability, but also in information dissemination.
Definition of Done ≃ Assessment for Learning
AS A teacher, how do I know that my pupil has learnt something? Well, we have a miriad of techniques we’ll use, which are all lumped together under the “Assessment for Learning” umbrella. The idea is to check a pupil’s learning as we go so any misconceptions or missing learning can be identified early and dealt with. Better to find out during class time than when sitting your exams!
This is a “Definition of Done”. Often in software this is a test suite that needs to pass when run against the code, which ensures the required features have been implemented and there are no bugs.
There’s a clear parallel here between required learning and required feature, as well as misconceptions and bugs. The purpose is the same too, making sure the software/pupil can do what it/they are required to do.
So in the classroom, every task on that SCRUM board has a definition of done. As a teacher this means I can go to any board, pick up any task in the “Done” column and test the pupils against this definition. If they fail, it goes back into the “To Do” column, if they pass then they’ve earnt whatever reward is used as part of the school scheme.
There’s a second benefit of “Definition of Done” that suprises most teachers when they first encounter it. The usual story is you’ve set some homework expecting pupils to write a couple of hundred words about something. Then some pupil hands in a multiple page essay. That pupil didn’t know when they were done, the definition prevents this.
So in summary, everyone knows what “done” actually means. Everyone is working to the same expectations and same understanding, meaning things actually get “done”.
SCRUM Team ≃ Peer Learning
THE OLD adage: “If you want to learn something, teach it” is not lost on teachers. Peer-to-peer learning is a core part of the practice of many, from carefully arranged seating plans, to “lead-learners”, or “think, pair, share”, we have pupils working together because it’s effective for learning.
Now we have to be a bit careful here, this is about developing your people and not about the well-known and poorly misunderstood “teams produce better outcomes”. It’ll take a whole other post to discuss the “better outcomes” case, and it is related to peer-to-peer learning. Suffice to say for now, there needs to be opportunity for such learning, but just because there is opportunity doesn’t mean it will occur, careful management is also required until it becomes a cultural norm.
There’s some parallels to be drawn here with pair-programming, which we’ll leave to the reader as we’re focusing on SCRUM.
End of Sprint Reflection
NOT ALL schools have an equivalent to this, I was fortunate to work in a school that did. At the end of teaching some topic in the curriculum the pupils sit a mini-exam, I mark it, and then we have 1 week of lessons to reflect on it. This time was golden, our summative assessment became informative. Pupils could catch-up and address misconceptions. Their meta-cognitive knowledge about themselves was improved, so they could play to their strengths and work on their weaker areas.
Although not all schools will take whole weeks out for this, many teachers will use self-assessment, where a pupil marks their own work, as a small scale version. This is more akin to a developer running a test-suite and interpreting the results than a deep reflection, but it does still carry some benefit.
However, reflection in schools can also include an aspect of peer learning. We often use peer-assesment where one pupil uses provided marking criteria to assess anothers work, like a code review with reviewer guidance. Actually doing this assessment is a learning process, when they know how to mark then they know how they are marked. So your experts in the team still have an important role to play in reflection and it’s one to benefit not just them but also the learners in the team.
WORKING WITH a SCRUM board, you’re free to grab whatever ticket is in the “To Do” list you want and run with it. You have a deadline on that burndown chart at the end of the sprint, but you’re free to manage your time, within reason. SCRUM constrains your playground, but you’ve got a remarkable amount of autonomy within those constraints. Futhermore, you can understand these constraints, afterall you’ve got something to achieve by a deadline.
Autonomy is empowering. Autonomy improves motivation. Autonomy improves well-being. The effect on pupils who are often denied autonomy is staggering: they were rushing to class and starting work immediately of their own volition. Having seen the same pupils with and without autonomy in their learning, I’d urge any working methodology to provide autonomy in abundance.
SO THESE form the somewhat ad-hoc, non-exhaustive list of features from SCRUM I found beneficial as a teacher described from the perspetive of a teacher. It boils down to knowing what everyone is doing, knowing what you’re doing, knowing when you’re done, working with others, learning from others, taking time out to catch-up/fix/reflect, and having autonomy.
It’s only by knowing the purpose of the artifacts that one can criticize their utility. Having taught using SCRUM I have come to the conclusion that agile is a fantastic bag of tools that can deliver things I find valuable. However, the most powerful tool was autonomy, therefore as any master craftsman would, those managing need to show discretion in their choice and use of tools. No two teams are alike and teams change over time, therefore their needs are different. Like any teacher does, you need to get to know your team, work with them, and lend them a tool/resource/process when they need it.
One of the reasons I gave for not using SCRUM across all of my classes was that pupils need to be trained to use it. This is the same for new teams who aren’t familiar with agile working. This is the only time the methodology needs to be used rigourously, as part of learning it. But it is a learning process, the team will begin with remembering it, then understanding it followed by applying it. Once they can evaluate it they’ll be ready to be creative with it (Blooms revised taxonomy). They can’t be creative with it if they’re trapped in rigourous application.
Another reason I gave was lack of homogeneity of artifacts used by management for tracking, should this issue arise then it’s up to negotiation to resolve. The key considerations are around the value of the artifact. Is it needed? Can one transpose onto another? Do we just have to put up with it for the sake of accountability, transparency or whatever value it brings? Such a negotiation requires both parties to be capable of evaluating their working methodology, which can’t be guaranteed. As a teacher I’d see failure to reach a conclusion as an indicator of some missing learning in one or both parties.
In conclusion, everyone involved needs to know how well they know agile development. Furthermore, management need to use discretion to allow autonomy, even with the working methodology, when the team is ready for it.