I’ve been a “desk jockey” Software Engineer for 20+ years now, and all that sitting, hunched shoulders, bad posture come at a price that I undo at the gym, in yoga class and enjoying some good livin’ with other weirdos.
I have taken a lot of lessons from GORUCK and fed them back into my job as a manager for my engineering team. But the street goes both ways, and some lessons from my day job can come back too.
Agile SCRUM
A few years ago I became a certified SCRUM Master. Scrum is an agile process (its origins are contended) in which to deliver tasks more quickly and in order of priority. It works via a prioritized backlog of pending tasks that are tackled in short bursts of time, called sprints. This system has been heavily adopted by software engineering firms for its ability to handle changing requirements quickly.
In addition, at the end of each sprint comes a retrospective. This is equivalent to an AAR, in that you look back on the sprint and analyze how it went.
In SCRUM a retrospective consists of the team answering 3 questions.
- What went well?
- What went badly?
- What can we start doing next time to improve things?
Finally comes a “release” after 1 or more sprints.
Tying this to GORUCK team leadership
How does this relate to being team lead at a GORUCK event? The various aspects of a SCRUM process lend themselves well to a specific “mission”. To map the vernacular we have
| Backlog | -> Priorities of work |
| Sprint + Retrospective | -> Iterative improvements during mission |
| Release | -> Mission |
Lets take a specific example of the log carry. Cadre give you 30 seconds to be moving, you haven’t figured out the right approach yet. So, just get that in the air and start moving. BUT it sucks.
Therefore our “backlog” or “priorities of work” might be
- Get the log in the air
- Start moving
- Implement process for lowering the log and swapping out people as they become tired
- Refine process to perform swaps actively while moving
- etc..
Our Sprint/Retrospective might be 5-20 minute increments where you as team lead constantly analyze the current state, asking the 3 questions above
- What is working?
- What isn’t working?
- What one thing can I do to improve things?
The aim of this cycle is to iteratively and constantly improve the process and therefore the efficiency and efficacy of the team. Bring in a couple of alumni GRT into that “AAR” process and it is likely that you’d be efficiently moving that log in NO time. Obviously this process can architect itself to any mission.
A major benefit of this approach is non-disruptive improvements over time. An alternative is to stop everything and start from scratch but usually all that does is piss cadre off…
Now I rarely volunteer for team lead, because I tend to want to let newcomers figure that shit out. Plus I prefer to carry the heavy stuff when I can, and team leads typically don’t get that chance. Therefore I don’t get many chances to really put this into play but would be interested in thoughts or feedback.
Other Scenarios
The same decision making loops can apply to other events as well, although it lends itself a little better I think to team scenarios. For example, I have successfully used this process in certain Death Race scenarios.
Over Long Distances 
Great insight — not sure if I am more psyched now for my next Goruck or our Monday morning sprint standup.
LikeLike
as a software engineer myself, and working daily in an agile environment…i can honestly say that some of the lessons ive learned at GORUCK events have changed the way i manage and develop software…great article.
LikeLike