by Andy Hunt, January 5, 2022
Most software development methods are defined by “practices” you have to follow. In many cases, this emphasis on practices goes badly, for two reasons.
First, it’s too easy to fall into the trap of perfecting the practice itself instead of delivering value or gaining skill. Enforcing particular practices can become draconian means unto themselves. They might even require dedicated roles such as “Process Master” or the “Practice Police.” None of that helps you understand why a particular practice is important. These roles do not contribute to delivery, growth or learning; they’re just wasteful overhead.
Second, it’s too easy to blindly follow a practice as a recipe, with no thought or reflection. That sort of non-thinking approach might work well on a factory assembly line, where you want to minimize variation. But our job as software developers is literally to think. We simply can’t afford to run around on autopilot concerning our methods of work. Knowledge work is an emergent cacophony of ever-shifting understanding, learning, and growth. Static methods and one-size-fits-all processes will never be successful in that environment.
And as many teams have painfully discovered, not everything that’s important can even be codified into a simple practice. Rules are great for beginners. But strictly following the rules limits you to beginner level performance (see the Dreyfus Model research cited in Pragmatic Thinking & Learning).
So instead of “practices,” we offer a simpler idea of forming good habits.
Habits focus on the goal. For instance, suppose you have a New Year’s resolution to lose weight (COVID-19 was bad enough, but the COVID 20 may take a while to lose.) You may try several habits to support that goal such as diet and exercise. The actual habits don’t really matter. That is, there are many ways to achieve calorie reduction: eat more vegetables and less meat, eat less overall, only eat during specific hours, and so on. The important part is to understand the nature of the goal. You want to burn more calories than you take in, and appreciate the nuances that some foods might make you hungrier, trigger cravings, and so on.
Habits take time to create. Research indicates that it can take weeks to make a new habit. And you may need to tweak and tune. For instance, you start running for a cardio workout but discover it hurts your knees. You adapt and switch to a low-impact exercise using an elliptical machine. The point of the habit isn’t the particular practice (running vs. elliptical vs. rowing, etc.). It’s the goal, knowing how the habit supports your goal, and what changes and adaptations you might need to make depending on your own circumstances.
At the beginning stages, the GROWS Method® habits focus on goals of safety, reliability, and deliverability. If you can’t deliver value to your sponsors consistently and without harming the team members, there’s no sense in proceeding any further.
Start with good version control habits and a solid continuous build pipeline. Automate continuous integration, test, and deployment. Start building an ecosystem in the organization that supports learning and exploration, which requires psychological support and safety. Learn to use the right tool for the job depending on the Cynefin model—sometimes you do need a process, often you cannot use any process. You need to form habits around critical thinking, so you can make better decisions more reliably.
Part of what makes successful software development hard is that you need habits across several different disciplines. These habits span both technical skills and “soft” skills (which ironically can be hard to master or even recognize). In fact, before even beginning with something such as The GROWS Method®, all participants must Agree To Try (one of our core habits).
These are the sorts of habits we’re talking about.
Next time, we’ll talk about the limits of process, and what you really need to successfully grow your code, your skills, and your organization’s capabilities.
— Andy Hunt