To some of you, this may not be new. But to many of the people preaching “Agile Software Development”, Agile is not what you think it is. Let me say that again, because it’s important: You’re Doing Agile Wrong.
What Is Agile
Some people think that Agile is a project management framework. They are wrong.
Some people think that Agile is a development methodology. They are wrong.
Some people say that Agile is a “tool”. They are wrong.
To say it simply, Agile is a philosophy.
Or more accurately, Agile is a business philosophy.
The Agile Manifesto
If you actually read at the Agile Manifesto, you’ll notice that actually none of the points made have anything to do with project management, or even software development (you can replace “software” with “product” and get the identical meaning). Really, it’s a way of thinking. Really, it’s a way of communicating.
And that’s what agile is really about.
Communication Is King
Communication is the key. That’s what the Agile Manifesto is really trying to communicate (see what I did there :-P).
Well, what does that mean? Communication between who?
Well, to put it bluntly, everyone.
Do your developers understand the business impact of the feature they are working on?
And far more importantly, do they believe it?
Do the executives understand the costs and challenges of development?
And far more importantly, do they trust that information?
Do the business owners understand the technical architecture?
And far more importantly, do they understand its limitations?
How do you communicate?
An iterative development model is fine. There’s nothing wrong with it. But if you’re only communicating (or allowing communication to happen) in the iterative cycles, you’re doing something incredibly wrong.
Take this scenario: Imagine you’re working with a team that does two week iterations (sprints). The team is 4 days into the iteration. The business comes to you and says “We have a last minute feature that we need to get in this cycle”. What do you do?
Many teams would try to push back. They try to say “Well, we’re already mid-sprint, can we do it next iteration?”. Or “We’ve already committed to a big iteration”. I’ve seen agile coaches recommend doing this. I’ve seen people who are professionals suggesting this.
It’s an incredibly easy trap to fall into.
Instead, what needs to happen is a discussion around why needs to occur.
Remember, if you’re actually communicating, the business knows what you’re doing. And they know the priority of it. So if they come in and say “we have a problem”, everybody better recognize that there’s a problem and stop what they are doing.
But that doesn’t happen. That’s not realistic. Instead, one person may stop and look up to see what’s going on. But we don’t stop teams when one person says something…
Not because that’s inefficient, but because we suck at communicating.
In An Ideal Business
In an ideal business, everyone would know what’s going on everywhere.
That doesn’t mean people don’t need to make decisions. And it doesn’t mean that the CEO knows the internal workings of the smallest system in the company. There are still levels of abstraction, levels of accountability and decision making.
But if information can flow freely, everyone can question a decision. If the CEO makes a certain set of priorities, even engineers can question that. They can understand why. And more importantly, they can align themselves with it.
Doing this requires trust in your fellow coworkers. But then again, who wants to work in a place where they can’t trust their coworkers?
And even if it is an “ideal” that we can never achieve, that’s no reason to not try…
“But Scrum Is Amazing”
eih…
Many companies practice Scrum as an “agile” methodology. It gives the business insight into the development model. Right?
Scrum is simply cleverly designed waterfall. But instead of lasting months, it lasts 2 weeks.
You do a backlog review meeting, where you decide what you can actually build in two weeks. Then you do a commitment meeting where you actually say what you’re going to build. And then you spend two weeks building. And then you have another meeting to show what you’ve built.
Really, it feels like “agile”, but really all it does is make the people who have process fetishes feel good inside.
That’s not to say it can’t work. You can be extremely successful using Scrum. But not because of its process. Because you’re communicating effectively.
Effective Communication
Effective communication is a hard thing to quantify. When you have it, you know you have it. When you don’t, it can be hard to tell what to fix.
I don’t pretend to be an expert on communication. But here are a few things that I’ve seen that can help enable effective communication:
Speaking The Same Language
It’s really easy to think you’re communicating effectively, but have both sides of the conversation take away completely different points.
Instead, realize that sometimes that definition that you think is implied isn’t, and you need to take an extra few seconds to explain what you really mean.
Trust
The single most important factor in effective communication is trust. If you don’t trust the person you’re communicating with, you’re not going to believe what they tell you.
If you can’t trust your team, you can’t be effective. Bottom line.
A Level Playing Field
Communication can only be effective if the people communicating are doing so on a level playing field. If an engineer is talking to a VP, the communication is going to be skewed unless they are talking on the same level. With equal weights as contributors to the conversation.
That doesn’t mean that everyone needs to be involved in every decision made, it just means that when you are communicating, you need to communicate as equals, no matter the role.
A Safe Environment
There needs to be an absolute lack of fear around punishment or reprisal for negative information.
Someone who fears reprisal will withhold information. This is especially significant on under-performing or troubled teams.
Look at teams that are behind schedule (and not by a small amount), and you’ll tend to find that people usually know what the problem is. Yet if they’re not able to communicate that, well, things go south quick.
Chemistry
The most effective teams that I’ve ever seen have a sort of chemistry between each other. They “get” each other. They know when someone has a concern just by looking at them. They can communicate without words.
And that’s a multiplier.
It takes time to build that sort of chemistry.
That’s not to say you can’t be effective without chemistry, but that it can be a significant multiplier to it.
Naturally
Naturally, it’s not constructive to have an entire team involved in every decision. it’s not constructive to have an entire company attend every meeting. There needs to be some line.
Of course I’m not suggesting that there’s no line. But instead, what I’m suggesting, is that the line needs to be flexible. That line needs to bend and shape to the situation at hand.
And that’s ultimately what agile is about. Realizing that as long as we communicate, we can overcome any obstacle. As long as we communicate, we can be effective.