July 21, 2018
If you were in a Kindergarten class in the U.S., you probably remember something at the front of your classroom- a brightly colored list of classroom rules. These rules were often read out loud by the class on a daily basis (at least at the beginning of the year.) The purpose of this rule list is to lay down expectations for all the students to abide by.
This is a common practice because kids who are transitioning into a new environment (the classroom) need clear guidelines on how to behave, interact, and work.
Having recently worked through the agile transformation of a development team, I find the concept of clear and universal guidelines is just as important for grown ups as for kids. In fact, many of the same rules from Kindergarten remain relevant for agile developers!
With that said, I’d like to explain how following some basic ground rules from Kindergarten can make you an outstanding developer in an agile environment. I’ll title this list “What Kindergarten Taught Me About Agile Development”
A big part of the move from waterfall to agile is viewing development and testing as one, continuous unit. Instead of handing off code to the next team, we work together to make an excellent finished product. Instead of a “my team vs your team” mentality, we’re encouraged to work together to plan and solution.
In everything from sizing and breaking up stories to completing work, it is essential that team members across disciplines work well with each other. This means seeing tasks not just from my own point of view as a developer, but in terms of how they affect the team as a whole.
Considering that periods of work in an agile environment are called “sprints,” this one might seem a little counter-intuitive. But why does Agile require so much pacing and segmenting of work? Why are there sprints in the first place? The problem with software development is that it’s easy to let deadlines and requirements snowball to the point that individual developers, or an entire team, end up burning out in an effort to reach a goal.
If you’ve ever gone for a walk with a little kid, you’ve seen that good pacing is the last thing that comes naturally to them. In order to ensure safety and the unity of a class as they move, most kindergartens enforce this rule- and similarly, our development teams must practice discipline in going through agile ceremonies, keeping true to sprint scope, and accurately refining work into a sustainable flow.
Part of being on a team with different people is encountering different personalities. Some people are naturally very vocal in team meetings, while others tend to be more reserved. In order to form a cohesive team, though, all team members must put effort into communication - both listening and speaking up.
As easy as it is in a stand up to say you have no roadblocks, any issues that are hindering work from being done need to be addressed. Learn to clearly and concisely communicate where you are with your team- this is a skill that goes under-appreciated, and just like any other skill, takes practice.
Similarly, team members need to follow simple guidelines like putting up phones and laptops and giving full attention during team meetings. Remember: every conversation has its place, and that place is not always now!
In order to keep from sidetracking entire meetings (and turning a 15-minute standup into a 50-minute one), it’s important to speak out appropriately, quickly, and in turn.
In an Agile environment, clean code is everyone’s responsibility. The goal is not simply to “get it past testing”- it’s to make excellent software. A good way to remember it is one simple word: ownership.
Just as a kindergartener needs to learn to wipe up spilled glue and put away their lunchbox, developers need to acquire a personal desire to follow standards, write clean, modular code, and be mindful of technical debt. Some of this is universal to growth as a developer, but a place where it comes to the forefront in Agile is around the topic of technical debt.
Developers can’t be so focused on pumping out as much work as they can in a sprint that they lose track of longer-term issues that might happen as a result of cutting corners to meet deadlines.
Ok, maybe this was more of a kindergarten goal than it was a rule, but it reminds me of a key tenant in Agile workflows.
They take a letter of the day, work on that letter, get it to a point where the kids know it well, and move on. No, the kids don’t all get together in a “letter refinement session” and assign points to different letters (“Q has got to be at least a 13, it’s going to need a bunch of API work…”). Still, tackling one chunk of a larger goal at a time is a great picture of Agile.
Yes, these rules are very basic- but I find that by living them out in my work environment, I become a better developer, and make my team better as a result!