“Talking to yourself is a sign of insanity, you know.”

The last time someone said that to me was sometime in the 20th Century.

I was in school, in Maryland, and I happened to be reciting my lines for a production of The Importance of Being Earnest. Is that relevant to crafting software? As it turns out, yes. But let me first fill you in on my background as an engineer.

“If I am occasionally a little over-dressed, I make up for it by being always immensely over-educated.” - Algernon, The Importance of Being Earnest

I am a Software Crafter. Yet, I have no formal education in computer science. I taught myself software by creating a one-person process to drive my learning using Agile and Scrum.

I do have a degree, but my degree is in theatre. I even studied Shakespeare at the Royal Academy of Dramatic Art in London. It was awesome. That may seem unrelated, but because I spent so much time in both fields, I can see patterns common to theatre and software.

In the software world, development teams use processes to craft apps.

In the theatre world, production companies use processes to craft plays.

Software has a process called scrum.

Theatre has a process called rehearsal.

The thing about the rehearsal process is that its pattern remains essentially the same regardless of whether you are putting on Les Miserables with a team of hundreds, or you’re putting on Samuel Beckett's Act Without Words by yourself. Scaling the process up, you specialize the roles more. Scaling down, you put more responsibility on a single person. Doing Act Without Words just means that you are all the roles. You are the whole cast, the director, the set designer, etc.

So naturally, when I learned about scrum, I saw it as a specialized kind of rehearsal process. That meant I could scale it down to one. That one person (me) just had to do all the roles.

But some things in scrum seem to be designed with a team in mind. Daily standups, for example. The purpose of a team’s daily standup is to have a meeting so that everyone is on the same page, that blockers are identified and dealt with as early as possible, and so the meeting takes less than 15 minutes.

However, that’s not all a standup does. Standups have value even if you’re the only one standing up.

“Now produce your explanation and pray make it improbable.” - Algernon

In scaling down scrum to work for one, I did my best to keep every formality of a team-based scrum. During retrospectives I could cut stuff out if I needed, but standups never met the chopping block. Part of the reason was because my standups were not verbal. They were additions to a markdown file on GitHub.

“I never travel without my diary. One should always have something sensational to read in the train.” - Gwendolen

That GitHub diary became invaluable as a resource towards understanding what was working and what wasn’t in my process. I would start my retrospectives by reviewing the standups for the last sprint and look for patterns that could clue me in to what was going right and what could be holding me back.

“The truth is rarely pure and never simple.” - Algernon

Another reason it didn’t get the axe was because it served as a ritual to get me into the mindset of software development. My day job was as a retail salesperson. No one I talked to was technically minded. To make matters worse, at home I was in a relationship that was becoming more emotionally draining and abusive day by day. The act of simply answering the questions allowed me to mentally switch gears, set aside my suffering, and work.

1. What did you do yesterday to help accomplish the sprint goal?
2. What will you do today to that end?
3. Are there any blockers that might prevent you from accomplishing that goal?

“I think that whenever one has anything unpleasant to say, one should always be quite candid.” - Cecily

Spelling out the blockers each day allowed me to know what could derail my efforts. If there was something in the moment I could do to remove the blocker, I would. Otherwise it got logged for me to review during the end-of-sprint retrospective. The significance of this can’t be overstated.

By being honest about blockers and writing them down, I was left with a record of what takes me away from my goals. For instance, I discovered that the way I prioritized chores was holding me back. That allowed me to find ways to be more efficient. Chores weren’t the only blocker, there were strings of emergencies that would come up to derail my flow. With this record, I could begin to predict when emergencies would occur, when my most productive days were, and guard those days against side-lining.

Without the record created from the standup, my efforts would produce fewer and fewer results until I simply ran out of steam. I would never be the wiser as to why, either. But it would have been the cumulative effect of a thousand unexamined tiny blockers. With standups, I could identify each and work to keep my path forward clear.

“I keep a diary in order to enter the wonderful secrets of my life. If I didn't write them down, I should not probably forget all about them.” - Cecily

Doing daily standups also had the pleasant side effect in of allowing me to forget how much emotional pain I was in and focus on putting one line of code in front of the other. It provided a structure, a habit to focus my mind, which allowed me to succeed in inhospitable conditions. In that sense, I might even say the daily standup was the most important part of my personal scrum. Without it, I might have given up on learning software altogether.

“What seem to us a bitter trials are often blessings in disguise.” - Oscar Wilde

Ultimately, it turns out that talking to yourself can keep you sane—as long as you’re actively deciding what to tell yourself. And though scrum is most often used in larger teams, it can also be scaled down for your personal learning time whether you’re diving into deep learning algorithms or building a tic-tac-toe app for 8th Light’s apprenticeship. For that reason, I very much recommend you try it.

But when you start your personal scrum, or start fitting any agile process to any team’s circumstance, keep every practice, even if it seems silly. You may discover it has another value in your situation.