Chris Hadfield: An Astronaut’s Guide to … Agile Development (?)
When he’s not imbuing the TED technorati with the benefits of baby-safe soap in space or creating the most Canadian music video ever, Canadian Astronaut Chris Hadfield has influenced the software world by unintentionally inspiring developers on how to become better at that buzzword of relentless coding productivity: agile.
The rigors of being an astronaut are not immediately relevant to a developer working within an agile team; there are no rockets or decompression dangers, and the closest to a launch pad that your average coder gets to is the one on the desktop of their MacBook. That said the advice that the former Commander of the International Space Station dispenses in his memoir An Astronaut’s Guide to Life on Earth have relevance when working in any team software team, particularly an agile one.
So here’s what Chris Hadfield taught me about how to become a better agile developer:
1. Maintain Your Attitude
NASA on The Commons (No Licence Restrictions)
The concept of attitude in refers to terms of the current situation that the spacecraft is in relation to its fixed points of reference. If you lose track of that, you lose your ability to understand your current predicament. When working as an individual within a project team it is essential to maintain awareness of where you are and what you are trying to do in order to maintain productivity.
You cannot control every aspect of your working environment or the other people that you are sharing that space with, but you are in charge of your own approach to working within it.
2. Aim to be a zero (not a hero)
The commonly cited and oft-quoted take-away from Chris Hadfield’s lessons on being an effective team player, is the notion that you can be one of three types of team member:
-
a plus one is the person who clears their task assignments down by Wednesday afternoon, spends the rest of the week devising with new acceptance tests, fully comments their code, and shares best practices to help out colleagues.
-
a zero is someone who is competent and meets their goals without issue, right on time. Has a new issues, but fixes them so they don’t affect the glide path. They meet their obligations, nothing more, nothing less. Aim to be this person.
-
and a minus one is someone who is an actual detriment to the team; a liability. They take on 50 tasks with a “no problem, easy” attitude at the scrum, and beg for forgiveness at the sprint review.
As an agile programmer, you are assigned a list of tasks during your regular team scrum meeting, and in order to be a zero you need to tick off every one of those tasks in the manner agreed with the scrum master and the team at large. Nothing more. If you fail to achieve that however, you are immediately a minus one, so the quickest way to fail is to take on more than you can realistically achieve – exactly what someone trying to become a plus one will often do.
The upshot: do not bite off more of the backlog on an iteration than you can chew to try and impress, because nobody will thank you for it when you fail. The progress of the whole team is delayed when timing plans are too ambitious
3. Do sweat the small stuff
NASA Goddard Space Flight Center (Licence)
If you think something is not right, speak up, look into it, ask. Failing to do so on a space shuttle would mean an unresolved question, that could be either minor or catastrophic depending on the scenario. An agile team is made up of people from different disciplines, with different skills to offer and perspectives. Do not assume that others will spot the issue that you have just noticed, because they probably haven’t.
4. Be negative (inwardly)
Negative thinking has a bet reputation these days. Ordinarily it is common for negative thoughts to slip into your mind when project scopes expand and things become more complex than you expected. These thoughts can be detrimental to your ability to remain productive if you let them, so treating negativity as a tool to improve is a vital capability for a developer working in a high pressure environment, and can be applied both at the planning, backlog generation, backlog grooming and delivery phases of the agile workflow.
If an issue breaks your code or stalls an iterative release and that you could have predicted if you had though through the worst case, you have missed an opportunity to resolve it before it happened.
5. Worry about how you are seen by others
NASA Goddard Space Flight Center (Licence)
Most developers start out coding solo, so pair-programming can be jarring when you’re not used to having someone scrutinize every keystroke, but once you get used to it having an extra pair of eyes can be a powerful tool for self-improvement.
Request frank feedback from your teammates; what do they think of your technical expertise? If you use an issue tracking tool like JIRA or Bugzilla, are your comments actually helpful? How could they be better? What do your colleagues think you could be better at?
Taking criticism, especially as a proud code-parent, is not easy. Your biggest blind spot is usually the one that you are sitting in the middle of.
6. “Overpreparation” is not a thing
If it is important to do something right, you cannot over prepare. For astronauts this means going over every minor task again and again, for hundreds of hours, until the number of errors is zero or close to it. As a developer, you can do this by getting into good habits, and making use of slack time whilst you have it.
Make a personal backlog to help you make the best use of times when you are not heavily loaded with tasks. If you see a backlog item coming your way that is in an area that is unfamiliar to you, prepare before it’s on your current task list. If you struggle with a new version control system that the team has adopted, set up your own environment and practice before it causes you a logjam in your daily work.
7. Criticize the issue, not the individual
In the glossy books and slickly designed DevOps-evangelizing slide decks, agile is a utopian environment where everyone works toward a common goal, in a cyclic and intensely iterative flow of productivity and harmony. In fact it could be, if it wasn’t for the fact that there are people involved…
Constructive criticism is important, but nobody likes to be told that they’re doing something wrong.
Instead of: you suck at coding, your code sucks
Try: this piece of code could be better because…
or
Rather than: You shouldn’t have committed code to the same branch like that, you’ve broken the project.
Go for: If we both sync up before we commit to the same branch, we can prevent issues like this happening again.
The focus is on resolving the problem, and improving process in the future, rather than making anyone in the team feel like they’ve screwed up – for all the time that they feel sorry for themselves, you’ve lost productivity, and it will discourage people from coming forward next time. Again this applies especially to when you are senior on the team, which leads on to…
8. Lead by example
It is an awful cliché; the easiest point to state but the hardest to achieve on the list.
But as a technical lead, doing things as you would like them to be done is the best way to influence your team. If you do things right and they work, people will want to emulate you. If you want to introduce a new practice, adopt it first, so that the “You don’t do it, why should I?” argument can be easily removed. Conversely if you cut corners your teammates will too, because why wouldn’t they?
