“In times of change, learners inherit the earth, while the learned find themselves beautifully equipped to deal with a world that no longer exists.”—Eric Hoffer
The two most important skills a programmer needs are Learning and Communication.
Surprise! Those probably aren’t the first two that sprang to mind. You were probably thinking of math skills, or the ability to abstract, or problem solving, and so on. Those are important, but the most important skills are learning and communication.
We are learning all the time. Not just the new technology which seems to drop daily, but also learning the problem domain, the solution space, the evolving behavior of the software itself, the nature of your teammates and organization, the ever-changing competitive and possibly regulatory landscape, … the list goes on. And these are almost all moving targets, subject to rapid and often dramatic change. We have to be able to keep up.
Programming involves active learning: experimenting with tests, toy programs, and prototypes. Making mistakes, deliberate or otherwise, to learn how the system reacts and validate your understanding—your mental models that represent the system. Learning more about your user’s needs.
And as you might guess, learning goes hand-in-hand with communication. We communication all the time: with the computer and software, with team members, with sponsors and leadership, with the users.
The GROWS Method® emphasizes the importance of learning by including learning and related activities as first-class practices (which we prefer to call habits).
And unlike school or university, this learning is on-going and continuous as things change. Which means that as much we need to learn that’s brand new, we need to unlearn old, outdated concepts and facts just as readily. The flow of learning and unlearning is continuous, ever-changing and dynamic. A static mindset that applies the same old thinking, same old tools, just doesn’t cut it anymore.
“It is not necessary to change. Survival is not mandatory.”-W. Edwards Deming
While learning is continuous in the sense of it being ever-changing, we talk about Continuous Value a little differently. Continuous Value is important because it’s not batch.
In older, traditional organizations, software may have only been delivered annually at best, or even every few years, in a massive new release. That means that the organization only sees new business value in a big batch once a year or every couple of years.
Even worse, the organization realized revenue only after the release. But the organization has to pay for developers and the needed infrastructure throughout the long development cycle. This negative cash flow continues right up until the “gold disc” is burned, duplicated and distribution can finally start. Sometime after that, the organization will eventually realize revenue.
The CHAOS studies from the Standish Group showed consistent data over many years, leading to a simple but iron-clad conclusion: more frequent releases produce greater return on investment (ROI), less risk, and greater ability to generate business value.
But to accomplish that, you need robust feedback mechanisms and a culture of exploration, discovery and learning. And that environment may be a lot harder to create than you think.
That’s where the GROWS Method® can help. The GROWS Method® emphasizes the idea of business value as a continuous stream of small events instead of a single large, high-risk, rare event.
First, your users.
A successful organization depends on the value it provides. Your goal is to enable your users with a new “superpower:” something that helps them do their jobs and meet their goals better, faster, more creatively or more efficiently.
Second, the team gets value. With robust feedback mechanisms, teams understand the difference between the users’ needs and their own understanding. As the batch size gets smaller (implying delivery happens more often), the ability to change the prior release and engineer a better starting point for the next set of work increases. Interacting with users and collaborating with team members requires vision and psychological safety. This means less time dealing with failure demand (fixing defects and reworking delivered features) and more time delivering feature demand—new features and value.
Ultimately, this all adds up to making the organization itself more valuable, with real, long-term, resilient, measurable value. Not with short-term accounting tricks that may look good on paper but cheat or damage users, teams, society, the planet, or other stakeholders. This is the real stuff.
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.