I have delivered software for many clients over the years, and there is almost always an explicit goal to help them "go agile". The expectation is that with a little coaching and a few process tweaks, we will get transformational results.
In my experience, this approach always fails.
It doesn't fail in a small way, either. Failed attempts at "agile" have some significantly negative follow-on effects:
- Resistance to future transformation efforts: "We tried that. It doesn't work here." or "It's just another management fad that adds more work to my real job."
- It consumes attention and resources that could have been used to build products using the existing process.
- It pushes the talented people who really "got it" out of the organization. They gained some useful skills and want to use them, but they can't do it here, so...
Why Does It Fail?There are a myriad of reasons, but they boil down to a few core problems:
- The required shift in behaviors is too rapid. If leaders tell people to do things differently, but still expect the same day-to-day behaviors, they create chaos. "Be brave and challenge the status quo!" can't coexist with "...but don't upset people in other departments or you will be punished." Likewise, individuals aren't sure how to actually implement all of these changes, and the coaches don't understand the organization and business well enough to cover every situation.
- "Gatekeeper" sub-organizations aren't usually incentivized to change. Teams simply can't do emergent design and architecture it they have to follow a heavy design-and-approval process up front. They can't use lightweight estimation and velocity measurements if they also have a PMO process that mandates daily project plan updates.
- People resist change. You hired and trained them to do things a certain way, now you want them to radically change that. If they weren't already pushing for change, they're going to resist it, either actively (if you're lucky) or passively.
What Does Work?
This brings its own set of challenges, but in my experience, it's a more tractable problem space to work in. It really gives you three main problems to solve, which mirror the failure modes above:
- You need some real expertise in several disciplines. You can grow it in-house, but you'll probably need to hire it. That's expensive, and requires that the vendor or new hires are empowered and incentivized to make it work.
- You need to wall off the new organization from the old one. This needs a lot of executive support and/or a real physical separation. It will cause some jealousy from people stuck in the old org, and eventually, you'll need to move everything to the new practices.
- You must choose the team members of the new organization with care, and be willing to swap some of them if it doesn't work out. If you can restrict participation to people who are enthusiastic and/or already skilled in what you want, the odds of success go way up.