The habits listed here are a Work In Progress. Habits marked with an asterisk (*) are currently in draft form and will be published when ready.
Please give us feedback if you spot any typos, mistakes, missing elements, or suggestions based on your experiences. Thanks for your support and participation!
The GROWS Method® Habits are based on proven, successful, business and development practices from published scientific research and surveys.
The GROWS Method® features Core habits as well as habits specifically geared toward Individuals, Teams, and Leaders, and other specific roles, all of which emphasize Learning as a critical component of success. As an individual, you are responsible for your own personal learning. As a team, you are responsible for each other’s learning and growth. As a leader, you are responsible for organizational learning and growth.
Click on a yellow sticky note to see details for a particular practice or skip ahead to the section on:
Are you ready?: GROWS demands open-minded commitment and a willingness to experiment. If that’s not the case, then the organization is not ready to start yet. See the core concept Agree to Try for more details.
These core habits always apply, and are used throughout the GROWS Method® practices in different ways. These give a good indication of the overall philosophy and direction that the GROWS Method® rely on.
These core habits provide practitioners lenses for understanding and solving novel problems as they arise.
Leaders are the leaders and executives in the organization, which may include the CEO, president, vice-president, etc.: whoever is ultimately and directly responsible for the Business Development involving this product and project work being done.
Capability Planning *
Visualize Progress *
Create Physical Flexibility *
Agent Not Gate Keeper *
Safety *
❑ Checklist *
Create ARobust Mix *
Create Careers *
Rand DRisk *
Business Continuance *
Drive Open Source *
Optimization *
Purpose Driven Organization *
The Team encompasses anyone directly involved in creating software and related deliverables, including developers, DBA’s, analysts, testers, tech writers, and others.
Right size the Work *
Deep Product Discovery *
Schedule Improvement *
Lunch And Learn *
Share The Secrets *
Continuous Feature Demos *
Two Sets of Eyes *
Team Sync *
Twelve Factor App *
❑ Checklist *
Bring Itback *
Project Retrospective *
Kanban Flow *
These practices are geared toward the Individuals working in a team, and their Individual Skill Development, which is different from things done together as a team.
Critical Thinking *
Cognitive Biases *
Learn Your Tools *
❑ Checklist *
Set Cues for Task Resumption *
Reinforce Values *
Get Mentored *
Teach It *
Users are the actual people using the software being created. They want the software to increase their own capabilities for their own purposes, which may include their own business or personal development.
Clear Bug Reporting *
What Dont You Need *
The GROWS Method® workflow is based on a simple OODA loop–a variation of Observe, Orient, Decide, Act.
You might consider this first step in the loop to be your chance to gather feedback. At this step, you gather the latest data, however informally, on how the team performed last time, how is the company doing, how much technical debt is there, and so on.
The first time through the loop for this development cycle, you may need to take a very broad approach and gather data from many levels, including:
Outcome: Available Data
This next step is all about understanding and context building. The goal is gain clarity and get solid, team-wide comprehension. This may include further and ongoing discovery of requirements and connecting outcomes to vision, including the business goals and the overall, architectural vision of the system.
It’s very important to conduct this step as a conversation: a dialog, not a monologue, and not a document. This step is about asking good questions, sharing knowledge, exploration and discovery.
Create shared understanding
Of course, that’s easier said than done and our cognitive biases work against us, making harder to actually see what we need to see. So part of this step involves compensating for biases as well.
Outcome: Informed Understanding
Next, the team decides what to do—and what not to do, and creates a work queue. This could be as simple as a TODO List, or a more formal Backlog as used in some common methodologies. However, in keeping with Lean ideals, you want to minimize work-in-process (WIP).
Keep tasks small and manageable
The goal in this step is to decompose the selected work items (which may include more than just feature development) into very small, manageable tasks, and then prioritize them.
Most tasks should be chosen so as to take between an hour and a half a day. No single task should be expected to take any longer than three (3) days as an absolute maximum.
You can choose to fill up an iteration with tasks to fill the time in a Sprint (as Scrum does), or take a more agile approach and pull tasks from the queue and deliver as you go (as in Lean/Kanban).
Whether you use a “push” or “pull” model, make tasks very small and deliverable. This helps avoid the trap of fortune-telling (i.e., “estimates”) and wasting time on calculating story points or other proxies. Just break the work down and do it in order.
As per the ThreeTrackAttack practice, you may have more tasks to work on other than just delivering features. Any items from the other two tracks need to be put on the queue as well.
Outcome: Priority Queue of Tasks
The steps above should not take a lot of time; just long enough to feel comfortable with a basic, first-level understanding and create a task queue. Now, it’s time to act, to use the Continuous Paradigm to produce Working, Tested, Features that give the users new capabilities.
The idea behind the the Continuous Paradigm is to use Continuous Integration, testing, deployment and monitoring in order to get feedback as fast as possible.
Rate of feedback is your speed limit
That means that some common practices are actually counter-productive. For instance, in a git-driven workflow, it might be common practice to use long-lived feature branches for development, with an eventual merge many days, weeks, or months later. Don’t do it. By deferring a merge, you are creating a huge opportunity for conflicts and headaches. The whole point of Continuous Development is to have everyone work on the main development branch at all times.
To do that effectively requires rock-solid automation and deployment practices, which are a necessary first step in any modern software organization.
And as mentioned in the last step, code is not the only thing you grow. Continuous Development applies to the process itself, to individual and team skills, and ultimately organizational capability.
Outcomes: User Capabilities, Skill Improvement, Process Improvement
And now we’re back to step one again, evaluating feedback and observing. This time through (and subsequent times through the loop), you have more feedback, more data to gather, from the project itself that you didn’t have the first time. This might include areas such as:
It’s critical to note that as you go through the OODA/development loop, it will become apparent that changes need to made—to people, to process, to code, to architecture, to mental models and assumptions.
Make the changes that must be made
Don’t live with Broken Windows, fix what’s broken as soon as you can.
Outcome: Available Data
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.