How I used Scrum to Teach Myself Software Engineering

Teaching yourself is hard.

When I was studying Chinese Philosophy in a Taoist Temple, the master spoke only Mandarin Chinese. Most of what I learned was through an interpreter. So I thought it would be a benefit to learn Chinese and speak with the master directly. I bought books, I listened to recordings in the car. I tried my best to practice.

But there were issues.

I wasn’t able to learn consistently. I had to fit learning Chinese in with my day job at a tea house, with doing chores, and with friends who thought it was some sort of voodoo magic, or who would rather practice their English on me than allow me to practice my Chinese on them.

Then there was the scope of the project. It’s one thing to ask where the bathroom is in Chinese, but it’s another to discuss the philosophical concept of Emptiness and how it applies to modern city life. And then there is written versus spoken Chinese. Written Chinese has about 50000 characters, 2000 of which are in common use. To discuss philosophy, however, I’d need more than 2000. On the other hand, spoken Chinese is tonal. If you make a sound as if asking a question instead of the same sound as if making a statement, you have said a different word. Also the consonants in Chinese are difficult for English speakers to tell apart, let alone pronounce. And I haven’t even started on Classical Chinese. All of the master’s discussions were over ancient Chinese texts written anywhere from 1000 to 5000 years ago. Classical Chinese is as different from Modern Chinese as American English is from Anglo-Frisian. The character meanings and syntax have morphed over the millennia.

I would have these same problems years later when I took up learning Software Engineering.

I spent ten years trying to teach myself Chinese, but I did not learn it as well as I would have liked. I did memorize a few poems. I can pick my way through a passage of classical or modern text, and I can ask where the bathroom is. But I never got good enough to converse directly with the master.

So what went wrong?

1. Life is chaotic. That shouldn’t be a surprise. It was hard to stay disciplined about my study when my boss was being mean to me and I was struggling to make ends meet.
2. The project was huge with too many parts that were each huge in and of themselves.

If only I was born Chinese. To wealthy parents. Who were super-subversive and wanted to practice (not just praise) the Ancient Culture.

But in fact, I didn’t need parents of privilege and vision to learn Chinese, nor did need it for learning Software Engineering. I just needed to define an engineering challenge:

How do I learn Software If I have zero dollars and 10 to 20 hours a week?

I don’t have time to go back to college.
I can’t afford a bootcamp.
But I could scrum myself.

I learned about scrum by practicing a few basics which are also super-valuable:

1. I had the audacity to show up at tech meetups when I knew nothing.
2. I had the further audacity to ask experts questions. I’d start with:
   How would I get started if I wanted to learn ____?
   What’s the most important thing to know about ____?
3. I actually tried the things they said.

Also I used every resource I could:

• Books. (I worked at a bookstore at the time.)
• Meetups. (like Fullstack LA)
• Google.
• Free Code Camp.
• Friends. (old ones, or newly-found at meetups)
• My dad’s wallet. (For conference fees and certifications. I could have applied for scholarships, but I had my dad’s wallet and I wanted the scholarships to go to someone who didn’t have that advantage. (I love you, dad.))
• Personal background. (You might think that no experience means no experience, but it’s just not so. My personal backrground is not unrelated. I used my Boy Scout training, my Theatre training, and my Taoist training in pursuit of understanding software.)

From the frothy mire of all that I learned a word: (Scrum).
I took a weekend certification course: (expensive).
And I used my background to interpret and adapt that information into a practice relevant to me.

I also worked in public. Boldly. Because Theatre. Also because if I flaked, people would know and I’d be embarrassed. Also to encourage others who might be feeling the same way. Also to show potential employers my character. I had no relevant job history. I needed to show them something. This is the repo if you’re interested. The good (most embarrassing) parts are in the Retrospectives.

Scrum is a way of getting things done with the principles from the Agile Manifesto. It allows for self-discipline in a chaotic environment. It thrives in fields where there is more to do than time to do it in. It responds to changing circumstances, staying relevant and avoiding waste.

But scrum is meant for teams. Teams who work full time. And are paid for it. How can I practice scrum by myself? And on what project? I have to have a product to scrum. I have to have a product owner. I have to have a scrum master and I have to have a dev team.

As it turns out, I have all of those.

I am the dev team. A team of one.
I am the scrum master. I facilite the rules of scrum.
I am the product owner. I decide what is the most important thing to do.
I am the product.

I am using scrum to develop myself into a scrumming Software Engineer who can take on any role in a scrum team. Or all of them. I can also use scrum to do the same with XP, Lean, Kanban, Surfing, Ballet, any project, any subject, any skill. If it can be made into a list, then I can scrum it.

By using scrum this way, I circumvented the problems I had learning Chinese.

Discipline:
The use of sprints, one-week time-boxes where something must be completed, allowed me to set goals and get feedback quickly. Sprints allowed me to understand what I’m capable of. And if I fail to hit the goal, I know it, it doesn’t hurt as much as failing a ten-year goal, and from the failure I know better what is realistic.

Control:
The use of a backlog, an unordered list of options I might commit to for a sprint, allowed me to see the vast ocean of software skills to learn, and select the most relevant to my situation. Going to meetups and talking with engineers and employers-of-engineers gave me insight into what was valuable. It also gave me a chance to demonstrate what I know, and discover what I needed to know next. Any skill I heard about went on the backlog. The skills that were the most important were selected for the next sprint.

Improvement:
At the end of each sprint I would write a retrospective, a formal opportunity to evaluate what went well so I could do more of that, and to evaluate what was wasteful so I could find the root cause and change. Retrospectives were perhaps the most valuable part of a scrum because it allowed me to reflect and improve upon what I was doing. It was also the most psychological part of a scrum. I ended up frequently talking about my emotional state and how to keep it from being a blocker. I was going through some pretty rough times at work and at home. So when doing a retrospective, it was important to stay focused and avoid ranting or navel-gazing. I didn’t dwell on feelings, but I made sure to acknowledge them. They were data points, clues towards optimizing my process.

Results of using Scrum:

• Accelerated development
• Control over complexity
• Focus on relevance
• Self-Knowledge
• Managed risk
• Less wasted time
• Less wasted resources
• Small failures that fuel big successes

Based on my experience, using scrum to teach yourself software engineering will be useful for someone who has:

• No experience
• Limited time
• No money
• Insatiable curiosity
• Vast stockpiles of passion

It was July when I learned about Scrum.
It was April when I started my Apprenticeship at 8th Light.