The Agile Architect
The Survivor's Guide to Agile
You just found out your company is going Agile. Our Agile Architect offers his top tips on how you can make this transition successfully.
- By Mark J. Balbes, Ph.D.
- September 4, 2013
Imagine this...
You're sitting in your nice comfortable cubicle that you've occupied for the last three years, working on the code you've been crafting for the past two months, it's every aspect and interface a reflection of your thought processes and coding skills. Your Gantt charts show that you are on plan and heading to an on-time delivery of your piece of a larger project. Smiling and self-satisfied with your own success, you look over to the photo of your wife and children sitting prominently on your desk next to the bookshelf filled with your college text books, technical manuals and, of course, The Hitchhiker's Guide To The Galaxy by Douglas Adams. As you reach for the phone to make your daily 2:35 p.m. phone call to your wife (right after the kids go down for their nap), you make sure to keep your voice down so as not to disturb the serene quiet that envelopes the office, disturbed only by the gentle click, click, click of keyboards.
And then you see the e-mail notification pop on your screen. Startled, you trepidatiously put down the phone and open it.
From: Bob Smith, VP, Change Management
Subject: Agile Transformation
Beginning Monday, we will be transitioning all projects to the Agile Methodology. More information to come...
And that's when you know that your work life as you know it is over. You feel your heart beating faster, your throat constricting as you realize that all of your expertise, all of your careful planning, everything you know how to do is being thrown out the window.
Don't Panic!
I am going to try very hard not to make this an article about all the benefits and practices of the Agile Methodology. There are plenty of articles out there, including mine, that cover this. Instead, I want to talk about what you personally can do to help yourself adapt to an agile environment and make the agile transformation a success.
Step 1: Embrace the Change
This is my advice, really, for any kind of change that is thrown at you, whether it's a new process, methodology, tool or technology. Make the assumption that the change is being made in good faith and that there are benefits to be gained. That's certainly true for agile. Help make the change be successful and push it for all its worth. If the change is good, it will stick. If not, by pushing it forward, you will help to expose the problems and either fix them or help the organization realize that perhaps they are on the wrong path.
O.K. That was a general statement. Agile done right is a good change and you should embrace it. Learn what it means to truly be agile and start thinking about your work in those terms. Your coworkers are probably just as nervous as you.
Step 2: Get Trained
Agile is not immediately intuitive to most people. It takes training and experience to be able to interpret the Agile Manifesto, the 12 Principles and the various practices. Change management is an important part of every successful agile transformation. While your company should be providing the appropriate training and mentoring, take charge of your own education. Read books. Read blogs. Practice techniques like Test Driven Development on your own.
Be aggressive about your own education and help educate your colleagues. I've found that the best way to learn is to be the person that everyone else thinks has the answers. Not only do I have to learn what I don't know, but I have to learn what everyone else needs to know and find an effective way to communicate the answers to them.
Step 3: Improve Your Communications Skills
Agile is all about communication. It's a mechanism to facilitate a whole-team approach to creating software. A large part of your day will be spent working with others, whether pair programming, working with the customer to define stories, or getting out in the world to meet with your users face-to-face. Get used to having impromptu conversations to solve problems or work through issues in the moment. Say goodbye to wasteful meeting where nothing gets decided. Work on having effective conversations at the time they are needed, coming to consensus and moving on.
In an agile environment, email becomes a relic for most of the team. Everything is communicated in the war room either verbally, through the tools, or in big visible charts like the Kanban board.
For those really difficult conversations, I highly recommend you read the book "Crucial Conversations: Tools for Talking When Stakes Are High, " by Patterson, Grenny, McMillan and Switzler.
Step 4: Focus on Rapidly Delivering Working Software
This changes how you think about your work. It's no longer about what you can personally deliver. It's about optimizing the team so that the whole team delivers. Optimizing the team is very different from optimizing an individual or even a sub-team. It means being willing to sacrifice your own effectiveness to increase the overall effectiveness of the team.
Here's an example.
Let's assume you are a software developer. In order to get a release out the door, it may be important to focus on helping to test the application. This furthers the team goal of getting releases out early and often. However, you yourself are a software developer. You are most effective when you are writing software. So why should you "waste" your time testing? There are multiple reasons, the most important of which is that it gets the software into your users' hands faster. Getting the release out faster means you get faster feedback on what the team is producing. It doesn't matter how effective you are at writing software if you are writing the wrong software.
Having the entire team test the product teaches you what kinds of problems in the software to look for, making you a better developer. When you understand someone else's primary responsibilities, it makes it easier to collaborate with them and find ways to help them.
Crossing boundaries between job roles will make you better at your core job. If you are a product owner, sitting with your developers to code through a solution will give you a better understanding of how they think, the problems they encounter and why a particular solution may be harder than you think it should be. If you are a developer, work with the product owner to create stories and minimal marketable features. You'll get a better understanding of why they are written that way and be able to influence how they are written in the future. If you are in QA, sit with the developers while they're coding. You can learn from them and maybe help them to think about QA issues.
Crossing role boundaries is just one example of de-optimizing your personal effectiveness in order to increase the effectiveness of the entire team. There are many more, including spending your time training and mentoring more junior members of your team, spending time in retrospectives and follow-up activities to improve the team, and giving up some personal luxuries (e.g. headphones while coding) in order to work in the war room environment.
Step 5: Let Your Old Techniques Go
This is perhaps the hardest thing to do. You already know techniques to address specific needs and situations. When these situations present themselves, its only natural to turn to the techniques you have used successfully in the past. However, many traditional techniques aren't aligned with core agile values.
One technique I find difficult for people to break is thinking functionally because, for most of us, it's how we've been taught to decompose large requirements into estimable, workable chunks of functionality. However, functional decomposition doesn't lend itself to shipping working software quickly. While you may have parts of the application working, it may not be until all the functionality is completed before you have workflows that allow the end user to accomplish their goals. In agile, we build the system from these user workflows, only we call them Stories.
Step 6: Eschew Meetings
One of the common decision-making techniques in a traditional management structure is to schedule meetings to get people in the same room together. In the agile environment, everyone is together in the war room. Embrace the war room environment. There is no need for meetings when the right people are already sitting with you. Learn how to come together quickly, make decisions and then go back to work. It can be frustratingly distracting at first with what feels like constant interruptions. Soon the team will get a rhythm, you'll get better at shifting focus to the group conversation and then continuing your work. The cost of the distraction is by far compensated for by the disappearance of the parade of pointless and ineffective meetings.
Step 7: Know Yourself and Your Limits
The agile environment is very fast paced and collaborative. We all have our own thresholds for how much is too much. Know when you need to pull away from your pair to do some independent research or spikes. Make sure your company sets up some quiet areas where you can get away to think on your own. Bring up any issues you are having in retrospectives so that you have a voice in improving the team and your implementation of agile practices in ways that make sense to you.
Step 8: Have Fun!
This is an awesome opportunity for you to learn new techniques for improving your craft. Embrace it as the learning opportunity that it is and enjoy the ride!