The Agile Architect

Agile Advice: Don't Be Elite, Be Obsolete!

Our Agile Architect explains why you should work hard to make yourself obsolete in your job.

• By Mark J. Balbes, Ph.D.
• November 20, 2013

Before we get started on this month's column, I wanted to let you know that there's a big secret at the end. Don't peak!

One of the phrases I like to tell people is that I'm always working to put myself out of a job. In other words, whatever tasks I, as an individual, need to perform on a project, I'm always looking for ways to either create a mechanism for the team to take ownership of it or for it to be automated so no one needs to do it. My personal experience is that the more I do this, the more variety I have in my career and the happier I am. I don't like to keep doing the same things over and over, at least not the same way. (Hence, last month's column.)

I've met many people in my career who have the opposite philosophy. They find a niche, an activity or set of activities, and they then proceed to "own" them. I find two reasons for this. Either the person finds comfort and enjoyment with the stability of the familiar, or the person is trying to make himself or herself indispensable within the organization in order to attain job security. For the former, I'm glad you've found satisfaction in the workplace. For the latter, I strongly urge you to rethink your strategy.

I've found from my own experience that the more I learn about a large variety of subjects, the more valuable I become to my employer as someone who can tackle a broad range of problems. Of course, I also want to be an expert in certain key areas but I have confidence that whatever problem I'm tackling, I can ramp up pretty quickly to near-expert level. That's not arrogance. That's lots and lots of practice.

Agile talks about embracing change -- the idea being that if you structure your development processes such that change is a natural, expected and regular occurrence, then when there are changes in your project, you'll be able to handle them with no real impact on how you do your daily work. Of course, it can affect your project schedule and all kinds of other factors. By practicing managing change on a daily basis, the team becomes good at it so when real change comes, it's just another day at work.

The same is true about learning to make yourself obsolete. If you practice it daily, always asking yourself why you are doing a task -- why YOU are doing the task -- and whether it can be subsumed into a repeatable process (whether manual or automated), you get good at learning how to take repeated tasks and make them go away.

Let's take a simple example. Suppose you are the build manager for your project. Your job is to manage the merges, promote code from dev to QA to production branches, building the system on each one as appropriate. Most days, you spend your time at the computer issuing Subversion commands, resolving merge conflicts, opening the code in the IDE to build the product, and smoke testing the results. (For the more agile of you reading this, yes, there are still people who do this.)

So how do you make yourself obsolete?

The easy part is to fix the technical aspect. There are plenty of automated build tools out there (Jenkins, Cruise Control, Team System, etc.) for whatever technology you are using. These are usually part of a continuous integration solution that will automatically monitor your source code repository, check out any changes, build the software including running any automated tests, and then send out a notification on success or failure. There! Done! Take the one-time hit of setting up the build server and you never have to manually build the software again.

The harder part of this problem is fixing the process around managing branches. Build servers aren't going to magically merge branches for you and fix conflicts. So if you are going to make yourself obsolete, you have to change the process. This means not only changing how you work but changing how others work as well. The process change is simple. For the dev branch, make the developers who are creating the branches responsible for merging them back when they are done with them. For QA and Production, you'll have to convince the team to take ownership of it and come up with a method to distribute the work. In a Kanban process, you'd simply create new queues for promotion of software to QA and to Production.

Some of you are thinking right now, "But all the author is telling us to do is push our work onto other people!" That's not a true statement but it is important to address. To make yourself obsolete, it's not a matter of pushing your work to others. It's a matter of coming up with a repeatable process of which the entire team can take ownership and which simplifies and quickens the task. Which individual does the work is less important. It could still be you sometimes but now you have more time for other things. In addition, by having the team own the new process, you have removed yourself as a single point of failure.

Here's an exercise. Write down all the things you do during the day. Look at each one and ask yourself:

• Am I a single point of failure?
• How can I change our process so that I share this responsibility with the team?
• How can I eliminate the need to do this?
• How can the team automate this?