While I've been coding off and on since grade school, my first career was as a teacher. I specialized in working with at-promise youth and students with low literacy. My last teaching position was as a middle school reading specialist. I had ~100 students a day, all considered "below standard" in their reading skills. I also had no set curriculum.
Teaching, at least how I have seen it practiced, is an inherently agile workflow.
Designing and implementing my own curriculum was a huge undertaking. It morphed yearly, quarterly, monthly, weekly, even hour-by-hour based upon need. Even teachers with a curriculum dedicate hours adapting it to their students' needs.
When I first decided to pivot into a tech career, I had never heard of "agile software development". The more I learn about and see agile in action, the more I realize that teaching, at least how I have seen it practiced, is an inherently agile workflow. Many parts of teaching include the foresight and planning in Waterfall style development. But in an even bigger way, teachers need to be quick on their feet and adapt on the fly. And that is what agile is about, adapting to changing needs.
I started to compare my work as a teacher to what I was learning about agile. I read through the Agile Manifesto, replacing "customer" with student. I have to say, the metaphor fits. The items below are adapted straight from the Agile Manifesto.
# Early and continuous delivery of a useful product # Welcome changing requirements, even late in development # Frequently delivered product (weeks rather than months)
Students can't wait until 30 minutes into a lesson to get information they can act on. They need relevant, actionable learning quick and often. Not only that, teachers need feedback. Is the "product" (the teaching) was having the intended outcome. Is it usable in the intended fashion? Does the teacher need to pivot the lesson?
As a teacher, it is so important to get incremental feedback. Waiting until the end of a week or month-long unit to check in with the "customer" is a recipe for disaster.
Customers are more satisfied with a product when they receive a useful product as soon as possible. In agile this is called a "minimum viable product". The top priority features get completed first as part of the MVP. Then, the team can see how their customer interacts with the product and gather feedback.
This not only increases customer satisfaction, but also the engineers' efficiency. This early information lets the team know if their plans need adjusting right out of the gate. It helps keep everyone on the same page.
# Close, daily cooperation between business people and developers # Projects are built around motivated individuals, who should be trusted # Face-to-face conversation is the best form of communication # Self-organizing teams # Collocation and pair programming
This set of principles are basic guidelines for effective collaboration in any setting.
As a reading specialist, I worked with at least eight different teams of professionals. These included grade level teams, subject area teams, district teams, and more. Luckily, each team worked smoothly overall. We were well-trusted by those around us to make the right decisions for student learning. The frequent face-to-face meetings I was a part of helped me get input and ideas from teammates. We were able to take information we had from our "clients" and adjust the sails of our plans.
Likewise, in an agile environment, the onus is on teams completing work instead of external micromanagement.
An interesting part of agile is "pair programming". In pair programming, one programmer is a "driver" and the other is the "navigator". The navigator thinks out loud, walking through the overall directions. The driver is the one doing the typing itself. These roles are to switch every few minutes. In the long-run, this helps spread knowledge across a team so all become experts. This reminds me of observation rotations. Teachers would sometimes go watch other teachers during their own planning times to gain insight and ideas.
# Sustainability/the ability to maintain a constant pace # Excellence through reflection # Simplicity — the art of maximizing the amount of work not done
As a reading specialist, I was "a part" of many teams, but I was also apart from them. I had an outsider view into their inner workings. One team I worked with was especially great at working efficiently.
Their reflection fueled their simplicity, which led to a sustainable practice.
They completed team meetings in an hour flat or less each week. Their students were engaged, knew expectations for their assignments, and completed quality work.
You know what their secret was? They spent a good chunk of their meeting time in reflection. They also kept a running notebook reflecting on what had gone well (or not). It was a simple composition notebook where they recorded outcomes and reflections. This notebook served as a wonderful reference when they were planning. They knew if they'd tried something similar before and what had went well (or not). Their reflection fueled their simplicity, which led to a sustainable practice.
Likewise, agile software development encourages keeping a constant pace. This means there aren't quick accelerations followed by burnout. Simplicity makes an even pace achievable. At first glance, agile development seems to have less up front planning than waterfall. This may be true, but a solid plan is essential in agile development too to keep a steady pace. That planning should be effective and adaptable and, of course, fueled by reflection. Reflective and adaptive planning are crucial in today's rapidly changing world.
# Welcoming changing requirements, even late in the game
One trait that makes or breaks a teacher's success is flexibility. The plans for a day (or week) may change for any number of reasons. Teaching is a series of moving targets. And while flexibility is key, teachers also maintain their vision.
Flexibility for the sake of growth is the name of the game in the 21st century.
The Agile Software Manifesto claims that being adaptive gives customers a competitive advantage. To be successful, it is necessary to be able and willing to pivot while maintaining vision. Failing to do so may put another competitor ahead in a day and age where the playing field moves constantly. Flexibility for the sake of growth is the name of the game in the 21st century.
Breaking into the software engineering and web development world can feel intimidating. There are so many new terms and acronyms that everyone else seems to already know. At times, I felt I would never catch up with it all.
I've spent some time speaking with mentors of mine in software engineering. I keep hearing that knowing a programming language doesn't **really* make you a good programmer*.
What it comes down to is problem solving, grit, planning, ability to learn, and flexibility. Every teacher I've ever worked with has those in spades. My fellow teaching ex-pats, you're going to do great things!
Want to learn more about program management? Check out these resources to get started:
- The Agile Manifesto - Might as well start by going straight to the source! They break down the four key values and twelve key principles of Agile.
- Atlassian's guide on Scrum - Atlassian has SO much material on Agile work environments! I especially love this page. Scrum, kanban, and agile all get thrown around a lot. This article hits the nail on the head if you're struggling to see how they relate. (And for the record, I'm team scrumban)
- Atlassian's guide on agile vs. waterfall -- No surprise, this article is biased in favor of an agile workflow. But, it does a succinct job pointing out key differences between the two styles.
- Pathlight's Program Manager page -- Pathlight is great for exploring different roles in the tech industry. Their program management page breaks down what the day-to-day flow is like and has helpful resources. Pathlight's Slack community, Breaking Into Tech, is excellent for connecting with other tech professionals!