The Agile Architect
Breaking Through Development Project Barriers
We often find ourselves surrounded by barriers, both real and imagined, that prevent us from doing our job. Our Agile Architect explains why it's important to break down these barriers and how agile practices can help.
- By Mark J. Balbes, Ph.D.
I was having dinner with a colleague the other night and he was telling me how difficult it was to get any work done on his software development project. He was consulting on an agile transformation for a client, working side-by-side with a development team to help them adopt agile practices. However, every time the team tried to change how they worked, something got in their way that prevented it.
His latest complaint was that they wanted to write set-up and tear-down scripts for their QA database so that they could run automated user acceptance tests against it. One member of the team informed him that they couldn't do that because it was a security hazard. The team had accepted this as fact in the past but, on further questioning, he found out that no one had ever actually asked the question of the group in charge of security. It was a self-imposed barrier that turned out to be completely untrue.
In my work, I see this all the time. Barriers, real or imagined, are constructed and prevent progress toward solving problems. Let's take a look at some. Maybe you will recognize them in your own organization, your colleagues or yourself.
Let's start with something really simple and obvious. Physical barriers can easily create an impediment to rapid, effective communication and collaboration. Having distributed teams, whether in different areas of a building or different regions of the world, makes it hard for people to talk to each other as needed. While it may be nice to have private space in an office or personal cubicle, it makes it that much harder for people to talk to you and for you to talk to them.
This is the reason Agile projects typically happen in a war room environment. The team brings together all members, regardless of role or department, so that there are no physical barriers to the team working collaboratively to accomplish the task at hand.
Perhaps the next most obvious barriers to recognize are the organizational barriers. I've worked for and with many companies and see the same barriers imposed repeatedly. People are overly segregated into departments and sub-departments with their own objectives, often to the point where you can't effectively get the right people together to accomplish a common goal. Money is divided arbitrarily into different pots so that an important activity can't be funded, even though money is available to do less important work. Worse, the organization may have people whose job it is to maintain these barriers, making it extremely difficult to break through them.
As companies become more agile, they tend to become flatter organizationally. The barriers between departments lower or are removed all together. Since everyone is focused on a common set of objectives (e.g. delivering working software), organizational priorities become clearer.
Within organizational barriers often lies the subtext of cultural barriers. These can be very hard to see from inside an organization and even harder to correct. If someone has ever told you "That's not the way we do things here," you may be hitting a cultural barrier. Other examples include over-reliance on e-mail communication, which puts up a barrier to face-to-face interaction and a shared acceptance of bad meeting habits. Too many meetings, unending meetings, meetings that never start or end on time, or meetings with no specific agenda are all barriers to working effectively. In some companies, asking a question is seen as weakness, preventing people from making progress when they get stuck. On the opposite extreme, some company cultures value collaboration so much that they can never get anything done because no one can make a decision.
Cultural barriers reinforce organizational ones and can be a further impediment to change and improvement. Agile fosters a culture that breaks down barriers and continuously looks to improve how work gets done. By reinforcing a culture of change, organizational and cultural barriers are constantly under scrutiny.
Technical barriers can also get in the way. Usually, this involves some form of not having the right tools for the job at hand or not being allowed to use the right tools. (Which hearkens back to organizational and cultural barriers.) Many organizations take a "big bang"approach to solving problems, wanting to solve everything with one all encompassing solution. This typically leads to expensive, risky solutions that are never implemented.
Agile builds a culture of technical excellence and constant improvement and refinement, reinforced by practices like retrospectives, pairing and technical spikes that allow an organization to proactively address these technical barriers. While technical barriers may not go away overnight, over time they are broken down and overcome by self-directed teams.
Have you ever had a conversation with someone where you knew you were in agreement but it still felt like you were arguing? Or have you avoided a conversation because you knew it was going to be difficult? Ever sent an e-mail that you thought was straightforward but the effect was like setting off a powder keg? Many of these barriers involve or are some form of a communication barrier.
The Agile Manifesto addresses communication explicitly by valuing individuals and interactions over processes and tools, and customer collaboration over contract negotiation. In addition, one of the principles behind the manifesto says, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
If you are having communication issues, I strongly recommend reading "Crucial Conversations: Tools for Talking When Stakes Are High," by K. Patterson et al. from McGraw-Hill.
The hardest barriers to recognize are ones you put on yourself. Statements like "That's not my job," "I'm not allowed to do that," "I don't know how to do that," or "I don't have time to do that," are all red flags. Now, I'm not saying that this might not be true, but it's too easy to avoid tackling hard problems using these statements.
If something is getting in your way and preventing you or your team from accomplishing your goals, you should be asking the opposite questions:
- "How do I make this my job?"
- "Do I need permission to do this and if so, how do I get it (or beg forgiveness later)?"
- "How do I learn to do this?"
- "How do I make time to do this?"
On an agile team, no one works in a vacuum. Personal barriers are naturally surmounted by working with the other members of the team who don't share those same barriers. More importantly, the collaborative environment fostered by agile practices allows us to learn about our own personal barriers as reflected by others and overcome them.
Try this exercise with your team:
- List the top five issues of your team.
- For each, list the barriers that are getting in your way. Think about the different types of barriers.
- For each barrier, ask how you can break through those barriers. Don't allow yourselves to give up. Be creative and look at the barriers from different directions.
Questions to ask:
- How do I go through the barrier?
- How do I make the barrier smaller?
- How do I redefine the problem to make the barrier irrelevant?
You can't always break down the barriers around you. But you can learn to recognize them and ask questions. The "5 Whys"technique can help get to the root cause, allowing you to solve the underlying problem(s) that created the barrier in the first place.
My advice to you is to not give up on breaking down barriers, whether self-imposed or imposed by others. Be dogged in your determination and don't allow others to impose their imagined barriers on you. The only way to make true progress on a project is to continually work through barriers rather than go around them or ignore them. If you don't deconstruct a barrier, it will always be in your way. If you take the time to destroy it, you never have to worry about it again.
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.