The practices listed here are a Work In Progress. Practices 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™ Practices are based on proven, successful, business and development practices from published scientific research and surveys.
The GROWS Method™ features practices specifically geared toward Individuals, Teams, and Executives, as well as other specific roles, grouped by skill stage. Each practice is listed here by skill stage; you start at the beginning and work your way up. Learning and Core Practices form the backdrop throughout.
Click on the yellow sticky note to see details for that particular practice.
Once you’re ready to begin, the emphasis at this beginner stage is on practices geared to producing software the Right Way, using modern software engineering principles to reduce risk and technical debt.
Due Diligence *
Must Be Present *
Critique Don't React *
With a solid technical underpinning, everyone can proceed to work together producing the Right Thing to the Right Rhythm using simple, concrete checklists.
Capability Planning *
Create Physical Flexibility *
❑ Checklist *
Agent Not GateKeeper *
Deep Product Discovery *
Schedule Skills Improvement *
Share The Secrets *
Feature Demos *
Two Sets of Eyes *
Twelve Factor App *
❑ Checklist *
Practice Critical Thinking *
Compensate for Cognitive Biases *
Learn Your Tools *
❑ Checklist *
With enough experience at the simpler Checklist level, you can move on the more advanced Recipe level, where more judgment and critical thinking is required.
Create A Robust Team Mix *
Create Careers *
R&D vs. Copy-n-paste *
Business Continuance *
Bring It Back *
Project Retrospective *
Set Cues for Task Resumption *
At this advanced level, everything works smoothly, with a custom fit and local adaptations to your organization, users, and way of working.
Drive Open Source *
Kanban Flow *
Reinforce Values *
Get Mentored *
What Don't You Need? *
Finally, at the “expert” level, you can look to teach and scale beyond your immediate environment, and replicate your success.
Teal Organization *
Teach It *
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 ideas are always applicable, and are used throughout GROWS practices in different ways. You’ll notice there is no Adoption Experiment or Feedback specified, as these are guiding ideas, not practices themselves. But these give a good indication of the overall philosophy and direction that the GROWS practices rely on.
These core concepts aren’t necessarily meant for beginners, but are instead provided for more advanced practitioners to help understand and solve new and novel problems as they arise.
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