The Agile Architect
The Stress of Agile
Agile software development can be stressful. Recognize it, admit to it, deal with it, fix it.
Winston Churchill once said, "No one pretends that agile software development is perfect or all-wise. Indeed it has been said that Agile is the worst form of software development except for all those other forms that have been tried from time to time." Or something to that effect. The constant strive for improvement, the relentless drive for feedback, the subsequent changes in direction and the incessant social interactions practiced by successful agile teams can create stress just as easily as a death-march project. Here's how.
It's early morning as you step into the office. It's been a tough time on the project with some tricky technical issues impeding progress. You want some quiet time to be able to sit and think. But you enter the team area and quiet disappears. Your teammates are in a heated discussion about the state of the Middle East. You want to escape but there's nowhere to go. You don't have personal space other than what you've made for yourself in the team area. No cubicle or office or desk exists in the agile environment your company has created. You would escape to a conference room but you know they are already filled with teams having their early morning meetings and teleconferences with remote customers. So you stick it out in the team space. Besides, it's only 15 minutes until standup.
Standup can't come soon enough for you. Your teammates cease discussion on their unsolvable Middle East problems and gather around the Kanban board. When it's time to assign developer pairs to stories, you get assigned to work on the iPhone app. You want to say something. After all, you are an expert at the back-end Ruby stack. It seems a waste to spend time learning Swift and iOS when there are others with so much more knowledge. But your team decided during chartering that everyone would work across all stacks. No knowledge silos. Whole team approach. You look wistfully at the team across the hall from you. You see them as a much more pragmatic team, not so idealistic as yours. They divide their work by tech stack. If you were on that team, you could work in Ruby all the time. Of course, they have their own issues. Most of their work is on the iOS side, which leaves their Ruby developers with little to do.
So you gird yourself for a day of struggle, learning how to do things in Swift that you already know how to do in Ruby. It doesn't help that your pair is a Swift and iOS expert and a keyboard hog. You are going to spend the morning just trying to keep up and snatch some keyboard time without looking totally incompetent.
At the end of the standup, your agile coach reminds the team that you agreed to an improvement experiment to count the number of impromptu discussions the team has throughout the day and whether they are related to the project or not. Great. One more thing to have to remember to do.
Your pairing session is worse than you thought. You can't get keyboard time. Your pair keeps arguing that the team is trying to meet a deadline so you need to let him get the story done. "Stop slowing us down!" he repeats like a mantra.
Even worse, when you switch pairs, you're the one chosen to stay with the story. Now you have to explain what you've been doing when you have no clue what's going on. And intermittently, that damned chatter about the Middle East problem starts up again behind you.
By lunch, you are ready to go home. Stressed out, frustrated, exhausted, you can't see how you can possibly last much longer on this team.
Agile can be stressful. Yes, really. Any time you embrace change, change happens. And change can be stressful, especially when it happens all the time. I've had teams express frustration that they don't know how to do their work because the processes keep getting "improved." By recognizing this reality, you can start to address it.
Admit to It
Knowing it and verbalizing it are two different things. By publicly acknowledging this fact with your team and your stakeholders, you create a forum to understand the stresses on your team and begin to understand them. Retrospectives aren't the only time for team improvement discussions.
Deal with It
If you are feeling stress, there's a good chance your teammates are, too. Deal with it right away. Find a way to identify the stresses you are facing. Are they personal to you or shared with your team? Are they intrinsic to the project or a symptom of something else? Even if you don't know how you'll alleviate the stress, talking about it openly can be cathartic and calming.
Keeping a running list of the kinds of stress you or the team are facing can help you identify categories of the sources of your stress. Perhaps you're worried about something that happens once and it's over. Maybe that's just life. But if the same kinds of things keep happening, perhaps it's a symptom of a larger issue that needs to be uncovered.
Celebrate small successes often. Take the time to step back and enjoy what you've accomplished.
Balance agile idealism with pragmatism. You don't always have to be one or the other.
If change is happening too fast, ask whether a slower pace would actually be more beneficial.
Retrospectives aren't the only time to address team concerns. Do other team building activities.
Perhaps most important, know the members of your team, what stresses them out and what recharges them.
The End of the Story
So what about our hapless, stressed-out programmer in our story? We might hope that our programmer and pair would initiate a meaningful dialogue. That they would discuss together the team agreements about pairing, the reasons why they pair, the desire to remove knowledge silos and all become t-shaped people. That they would discuss how effectively pairing might slow them down in the short term but increase the speed of the team overall in the long term. That they would calmly and objectively turn to the team for advice on how to proceed. That the team might revisit the team agreements and again gain consensus. But, of course, that's all a bunch of BS in a situation where you are stressed and not able to think calmly or objectively.
Here's what I would hope I would do in that situation.
I would walk away.
Not rudely. Not abruptly. But I would tell my pair that I'm feeling stressed out and need a break. I would take a walk, clear my head and try to get to a place mentally where I'm not feeling so stressed. In this way, I can think clearly about the situation and what my next steps should be. And then, maybe I could do all those things I mentioned.
No one lives a completely stress-free life. Even the act of writing an article about stress can be stressful. (Was this useful? Did I waste your time? Do you hate me now?) The important thing is to recognize that agile thinking can lead directly to stressful situations for many people. As much as we talk about the glory of agile, we must recognize this and address it as a first-class concern. You aren't stressed out because you're doing Agile wrong. You are stressed out because you're being Agile right!
Dr. Mark Balbes serves as Vice President, Architecture at WWT Asynchrony Labs, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.