Agile 2014 is in full swing in Orlando and while I skipped it this year, I’m enjoying reading the tweet stream.
I’ve noticed some themes emerging though, one of which (and the most common) is my favourite quote: “you can’t do Agile, you must be Agile!” Whenever that phrase is muttered, the universe creates a new Agile scaling model.
Another theme I noticed is there seemed to be more comments about reaching outside of ‘Agile’ and into other communities.
I’ve attended and presented at a few change management and organizational development conferences and meet-ups over the last couple of years and I think the Agile community at large could learn the hard lessons people in these communities have already learned.
I see this as a sign that the Agile community is maturing, and realizing this “doing vs being” nonsense is just that. Nonsense.
People have different beliefs and values. If we all shared the same beliefs that ‘being Agile’ was the best way to manage work and people, what would happen? Would it be utopia?
Some people think of Agile as process. And that’s ok, stop chastising them for it!
So how can you succeed if you only do Agile? Is it worth it or even possible?
Absolutely.
Suppose your organization runs projects in a traditional way. That is, they take a pool of resources people, stick them together and run a serial (egads! waterfall!) project. Suppose their standard process is to do a code drop and integrate every 3 months and then deal with the fallout. They even (egads!) log bugs in a defect tracking system AND they measure the performance of testers by how many bugs they log!
Given that scenario, suppose they start ‘doing Agile’ and work in 2 week chunks but they don’t really ‘be Agile’. That is, testers aren’t integrated with the team, testing happens after the fact, user acceptance happens after the fact, but the team DOES automate their build process so they can build and deploy every 2 weeks in an integration environment to do their own developer testing.
Is that better than before? I’d say it is.
Suppose this new process works so well they then experiment with expanding the use of automated builds to a larger program that involves 15 team and it reduces the overall release process from 4 months to 3 months, which generates a savings of a few hundred thousand bucks and also reduces the stress of “crunch time” because a big chunk of what used to be heavy lifting is easier now.
Is that better? I’d say it is.
Suppose an organization gets really good at lifting off and executing Scrum teams that hand off what they’ve done to a downstream support team afterwards.
Is that better? Probably.
Suppose moving to a non-Agile, but iterative working model makes people who work on projects happier because they can sit and collaborate with their team. When the project is done, they go their separate ways, but they at least had a more enjoyable project experience. Suppose instead of getting 15 projects done per year, this organization gets 20 done.
Is that better? I’d say it is.
Oh what’s that you say? Who cares how many projects get done? I hate to break it to you, but most business people I know aren’t stupid. I might think ROI is a bunch of BS because you can’t predict the future, but most companies I’ve worked with know their market and customers very well. They might deliver in bigger batches than I would, but they deliver and learn. Unfortunately, bigger companies I’ve worked with do the schedule and budget chicken dance which is a waste of time, but it’s a reality they need to work within until “making projects go faster” works and they start to look at their overall value streams.
Suppose the organization decides to make some Stone Soup. I remember a tweet from a well-known, and respected, Agile practitioner that read: “sticky notes on a wall don’t make you Agile!”.
It might not make you Agile, whatever that means, but if risks and blockers for projects are resolved faster than they were before because the weekly status meeting now happens in front of a big visible wall, is that better? I’d say it is. Are they “being Agile?” No. They’re simply blaming each other sooner! Over time, that’ll lead to tighter collaboration. Or not.
Suppose an organization adopts some Agile processes and a few people absolutely love it. Then they quit when they see their organization is only planning on doing Agile instead of being Agile. Has Agile improved the life of someone, helping them find a better organization to work in? Yup.
Organizations can improve by only doing Agile. Optimizing processes can lead to enough improvements and some organizations might only be able to improve to a certain degree. Some people will argue that organizations must learn how to adapt or die!! Isn’t that using the same fear tactic that the Agile community preaches against? Some will also say that local optimization (IE: making projects go faster, but not improving the whole system) is bad. Yes, that’s what the theory says, but can anyone correlate that to contributing to the death of a company? Show me a peer-reviewed study that proves this and I’ll change my mind.
When I hear the phrase “you must be Agile and develop an Agile mindset“, I hear “everyone must think and act like me because it’s better“.
But organizations are asking people to help them transform to Agile!! If you’re a self-professed Agile practitioner and don’t see what’s wrong with that statement…well, time to pick a new career. Sorry.
My job as a consultant is to help organizations make sense of the reality they’re faced with, it’s not to beat them over the head with the Agile stick. If they choose process improvements only, great! They’ll get better. Maybe after some time they’ll take the next step and reach into the organizational layer by re-aligning into value streams, dealing with ineffective HR practices, moving to quarterly-budgeting, adopting some lean startup practices.
Then again, maybe they won’t. Either way, it’s their choice, not mine. I can paint them a picture, but they have to chose whether or not to hang it up.