Agile is a flexible project management system originally developed by and for the software industry. It’s an outgrowth of Lean manufacturing, and it accepts that things will always be fluid in certain projects. As a prototyper and game designer, I’ve found it incredibly valuable as a set of principles. You know what else is always fluid and subject to change? Your life. The philosophies behind Agile can greatly increase your productivity and decrease your stress in life. I’m going to skip detailing the twelve principles since they’re largely just detail for the core values.
The Agile Manifesto lays out the principles of Agile. The four core values are as follows:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Let’s look at these in order, shall we?
Individuals and interactions over processes and tools. Unless you’re going to do something a lot, there’s rarely a need to develop a painstaking process to do it “right.” Especially when what you’re doing is always going to be subject to change. Instead, focus on the people working with you on the project, whether that means a robot prototype, video game, or going on vacation with your significant other.
Working software over comprehensive documentation. It’s all about the priorities. Would you rather deliver a working product today with acceptable documentation, or have to keep telling your client you’re still working on the internal documentation they’ll never see or care about before you can start work on the actual product?
Likewise, if Stacie and I are going to do something, we do it. Aside from some basic, bare-bones planning, we don’t waste a lot of time figuring out how to do it. At best we make a few priority lists so we don’t forget anything – when we went to Wisconsin for a week last summer, we each had lists of what we needed to bring with and what we absolutely wanted to do while we were there. And that was it.
Customer collaboration over contract negotiation. I have yet to build a website for someone that didn’t end up having modifications requested by the customer because something changed on their end or technology changed that would let them do things more effectively. So instead of just making a contract and slavishly sticking to it, I assume there will be some tweaking involved and go with it. That way I deliver a better product and my client is happier. That’s a win-win.
The same thing applies in life – if plans with friends change on the fly, just go with it.
Responding to change over following a plan. An adage that probably goes back to when “top end military hardware” was a sharp stick is “no plan survives contact with the enemy.” Tell me the last time a non-trivial project of yours went exactly according to plan. When that happened, what did you do? Did you collapse on the floor and sob uncontrollably? Or did you do the right thing, examine what just happened, and adapt on the fly?
Agile also adopts the four pillars of the Lean mindset. Respect for people and culture, Flow, Innovation, and Relentless Improvement. I’m not going to go very deep examining the principles covered under each, but some of them are important.
Respect for people and culture. Most of these basically boil down to treating people well so they’ll be more productive. This should be a no-brainer.
It also looks at the simple fact that changing organizational culture is an effect rather than a cause. You need to make the changes you want to see before they become part of your organizational culture, not just try to change the culture and hope for the best. I’ll be the first to admit that I did this backwards about twenty years ago.
I got sick of being a loser in a dead-end job and decided I wasn’t going to be anymore, but I didn’t really do anything to change the situation consciously. It wasn’t until I sat down and looked at what I had to do and implemented those specific changes that I saw real improvement.
Going back to school helped a lot with this too, not just because I came out the other side with two tech degrees, but also because of habits and perspectives I picked up from some of my fellow students. Most important among these were realizing that all the losers hung out together beating their chests about how lazy and generally crappy and pettily competitive (usually to everyone’s detriment) they were – although they’d never say it that way. Likewise, the top performers had their own little subculture and openly shunned the losers while helping each other do better. My background in electronics helped me get in with the top performers pretty quickly – not only was I there to learn rather than engage in endless pissing contests, but I had valuable skills I could help others with. Likewise, the people I hung out with were more than happy to help me with the areas where I fell short. As a result, we all did pretty well overall.
Flow. This pillar is largely about optimizing how you do things, “meta-processes” for lack of a better term, to make yourself and your organization more efficient. Things like finding a sweet spot between overworking and being lazy, avoiding stopping and starting because you lose time and momentum when you do, making quick decisions based on feedback, and building upon quality.
That last one is where I see a lot of people screwing up. As the instructor in the class I’m currently taking put it, “crappy code is not scalable.” Again, back in school I’d see a lot of guys doing the bare minimum on the basics and having it bite them later. Yes, you did very well by studying for the test and nothing but the test. But what happened next semester when you had to build upon your (to be polite) sub-par grasp of the basics? And what’s going to happen to you out in the real world? I know people who go on and on about how they’re working on X, Y, and Z advanced projects in their free time, yet get nowhere because they couldn’t be bothered to learn the basics. I’m talking about software libraries you’d expect a senior developer to be working on, yet they don’t even know the basics of OOP. And they flounder and struggle constantly because of it.
Innovation. To do well, you need to innovate. You can get by on the bare minimum of doing things the way you always have, but that’s all you’re doing. Not all innovation is good, though – if your idea doesn’t do anything useful it might as well not exist. Sure, you’re “innovating” by using sliced cheese as an insole, but good luck getting it to do anything but stink and soak your shoes and socks in oil squeezed from the cheese. So when you realize an idea is garbage – and most of them are – you drop it immediately without mercy or guilt. Do not fall victim to the sunk cost fallacy. Anything you’ve put into it and can’t repurpose is lost, not a reason to keep going.
This pillar also stresses the need for time and space for creativity. Spend some time just goofing off. It not only recharges your brain, but you’d be amazed at the ideas you come up with out of the blue. People have commented to my wife on multiple occasions that I always have a notebook with me, even at parties or the Renaissance Festival. I have that notebook specifically because I get ideas when I’m doing whatever and I want to make sure I remember them. One of our friends has given me so many ideas after a few drinks he might as well be my gorram muse at this point.
Relentless Improvement. Emphasis on the relentless. This pillar is all about improvement, how, and why. Why? Because everything is always changing, and someone is out there looking to do better than you – if you want to stay relevant, you need to be better than your competition. So you improve the whole system, not just parts. Figure out what could work better and how to make it work better, and do it.
I am always thinking and learning. Even when I’m injured I’m taking classes online, reading, and working on any improvement I can in my current state. With a foot injury I can’t do much physical self-improvement, but my doctors assure me “we’ll have you hiking again.” As soon as they clear me for it, I’ll be back out on the hiking trails at the park reserve again. With multiple incisions that still haven’t healed yet I can’t go anywhere near the pool, but you bet I’ll be neck-deep about fifteen minutes after getting home from the doctor’s appointment where he says I can swim again.
How This Applies To My Current Situation
I’m currently on leave from work because of an amputation a few weeks ago. It’s been covered in detail elsewhere on this blog. Here’s important part. When he told me I was going to lose my toe, I was annoyed. I may have dropped a few F-bombs in the office upon hearing this news. I was given two options: lose my toe and part of the foot, or be admitted for major IV antibiotics that may or may not fix it. The semi-unspoken third option was “do nothing, go home, and lose the rest of my foot down the road or possibly my leg.” I say “semi-unspoken” because he told me if I hadn’t been doing everything I had been for the last month trying to fix it I would have had a bone infection throughout my foot – and since the amputation was done to remove infected bone, it was obvious what would have happened.
So we got me admitted to the hospital and I chose to go with the first (and safest) option. Did I want to lose my toe and part of my foot? No. Was this on my Grand Master Plan for Life? Nope. Between being admitted and my doctor getting an OR booked, I had about two and a half hours. I examined the situation and my options, and when asked what I wanted to do, I told him “do it. It’s the safest option.” Spent a few days in the hospital recovering to the point I could go home, and now I’m on short-term disability.
On disability, obviously I’m not going to my day job. My doctor would chop off the rest of my foot if I did, and not even out of spite. Going back before it fully heals could lead to disastrous “setbacks” like the other bones in my foot getting infected and having to be cut out of me. So I examined my lifestyle for the next several weeks after my stay. I would be stuck in bed, at my desk, or sitting on the deck. No hiking, no swimming, no rearranging the garage. That leaves a lot of things I could do while I’m letting the skin and muscle of my foot weld itself back together.
I could have just sat or lay around feeling sorry for myself and watching TV.
Instead, I looked at my backlog for Devil Monkey and Tech Services. Turned out I had a pile of stuff I could do from bed, my desk, or the deck. So I grabbed some pencils and paper and started drawing concept art for game assets. Then I jumped on my desktop and turned that concept art into 3D models. You’ve seen some examples recently. I’ve also been taking classes (one of which sparked this post) and doing research. I added some content to a website I’m running for a client. I’ve put a bunch of work into the upcoming Devil Monkey Games site rebuild and relaunch.
As a result, not only will the month or so I’m missing from work not become an unproductive dead spot in my life, but it’s helping keep me in a decent place in my head. Instead of lying around whining about the incredible unfairness of it all and using that as an excuse to be useless, I’ve accomplished quite a bit. Coming out the other side I’ll have an expanded portfolio of 3D art and video game code, and website improvements. I’ll also have several more classes I’ve used to gain or improve my skills.
And you know what does wonders for not feeling useless? Having tangible accomplishments to point at.