In my last post I ranted a bit about hearing the phrase:
“But Bob, in the real world…”
too many times in my agile travels. That it seems to infer that the agile methods are a bleeding-edge approach with limited contexts and marginal results. But nothing could be further from the truth. The methods have been leveraged for 20 years and are, at this point, solidly in the mainstream of approaches to building software.
In this follow-up post I want to challenge folks with this view. But instead of simply ranting, I want to explore some constructive approaches to overcome this mindset…
Constraints
If you’re saying it because you have constraints in your organization, then identify the constraints and look to overcome them with agile approaches. It doesn’t mean you ignore them or don’t care. Instead, work with your leadership team to figure out a way to “go Agile” and still meet the goals or requirements of the constraint.
For example, if you’re in a regulated environment, then you’ll have procedural requirements for providing evidence of your testing. You’ll still need to do this with agile approaches. But it will probably be a slightly different approach than you’ve traditionally applied. Figure that out.
Blocking / Excuses
Much of the time, I believe folks are simply blocking the change. Why? Quite often because it threatens their status quo or comfort zone. They’ve become comfortable knowing their work processes and methods and agility brings with it the unknown and change.
Leadership plays a significant part here in explaining the WHY behind agility. Often when I encounter blatant resistance, it’s because the leadership team behind the change hasn’t explained their rationale. They’ve simply said – “We’re going Agile”, without any context. So of course folks consider it a threat because of the ambiguity.
Pigeonholing agility
Not that long ago I was with a potential client who kept saying that agility only worked well on web-based software. They happened to work on real software – embedded software on hardware. That it certainly wouldn’t work in their environment…which of course was focused on more “serious” software development.
If this is your view, then please start changing it. The approaches have been around for 20 years and have been used in virtually ALL software development domains…successfully. It’s not a matter of do they apply to your domain. It’s a matter of are you willing to apply them to your domain and to adapt them to your specific challenges?
What problems are you trying to solve?
Part of “going Agile” is an acknowledgement of your current business state. As I said in my initial post, I think many organizations approach a state of denial when it comes to admitting that their current approaches to software development don’t work very well.
Usually they realize they have problems. But when confronted with the fundamental shift that agile implies, they are quite frankly…frightened.
A way forward is often admitting that you have challenges and then articulating them clearly. The next step is to do some analysis to map your challenges to aspects of the agile methods that might improve your ability to stand and deliver your software.
Essentially mapping your current “Real World” forward to a “New World Vision”
As part of this exercise, it’s often prudent to celebrate the things that you have done well AND to be clear about what your agile transformation will not change or improve. This clarity around your current state and your future state after making the agile shift can truly help your teams with making the journey and managing everyone’s expectations.
On the Bus
One of the key things to realize in any change initiative is that change is hard, there will always be resistance, and not everyone will successfully negotiate the change. Jim Gray spoke about this when he introduced the “Bus” analogy in his book Good to Great. As part of any agile transition, some people simply won’t make the transition.
You’ll need to be patient and try to help guide the majority of your teams through the change. But you also need to realize that there will be some fallout and some will leave. And that this isn’t necessarily bad for you or them.
Is it a Methodology…or something else?
Something that always amazes me with the real world comment is that folks are resisting some very simple principles. You see I consider agility to have little to do with the notion of methodology and to be significantly more about mindset and principles. Here are some of the principles:
- Work in small slices / batches
- Get feedback early and often; tight feedback loops
- Be transparent in everything – tell truth
- Consider and trust your teams
- Build quality in from the beginning
- Deliver the highest value as early and as often as possible
- Continuously improve
- Communicate continuously; face-to-face as often as possible
- Partner with your “Customer”
Now here’s a novel point. Which of the above can’t work in your organization? I’d argue that none of them are so “far out there” that you can’t apply them in your context. It’s the mindset change that often proves to be the impediment to “going Agile” and not the individual tactics themselves.
Wrapping Up
What I’d really like to recommend to the naysayers, who push back with the real world objection, is to truly consider why. What are your core concerns and to look deep inside yourself to potentially resolve them.
Then I’d simply like to recommend that you…try it. That you reframe your real world and see if these approaches will help you build better teams that will build better products.
Point being – step into my agile real world for just a bit and see how it feels to you. You just might like it.
Stay agile my friends,
Bob.