Quick! Are people “agile”? In my opinion, I give that a resounding “NO!”. Yet, I see companies, organizations and people using agile as a term in reference to their current operational state. I have decided that “agile” is the new “disorganized” when it comes to organizations. Rather than proclaim that they are in a state of chaos, it is much cooler to say “We’re being agile!”. Ok….yeah, sure…..
Agile is most commonly used in reference to a software development process that designed to connect the software developer more closely to the customer by frequently comparing the design communicated by the customer with what the programmer actually developed. The goal is to reduce the the chances that after months of creating detailed requirements, development plans and testing plans and THEN code and deliver the entire product you’ll hear “Oh no! THAT isn’t what I wanted!”. That method is called the “waterfall” method of software development where all the design and specification is done upfront, the design is handed over to development, then testing, then “Lookout below…..!”
Instead, in an “agile” process, the developer checks in frequently with the customer and says “Is this what you wanted?”, or “Is THIS what you wanted”, or “Maybe this is what you were talking about?” with the end result of a solution that is more closely tailored to the customer’s expectation. Theoretically, agile is faster and creates a more close-knit environment between the organization and customer. But, the one reason that is most cited for using agile, which is to be more responsive to a changing market, is seen as successful in only 4%* of organizations that adopt agile processes. THAT to me is very interesting.
If agile doesn’t make you more, um, agile….why not? I think that is because even though agile practices allow software development processes to quickly “pivot” (another cool term that is thrown about) people don’t pivot. People like predictable change. People like to be informed and make decisions with some reflection. People aren’t necessarily resistant to change although 46% of organizations say that resistance is why agile hasn’t succeeded in their organization *. People embrace change but embrace it slowly. I think this is why agile “works” with software development. The process is iterative over time. There are frequent check-ins to make sure all is well. But if your agile process is to develop people, or change a process used by people, well then, that requires a much longer process and more iterations.
Simply implementing a change in your process, a “pivot”, is easy as long as it doesn’t require changing people. But in most cases changing processes DOES involve changing people so don’t expect to be able to make a switch in your “prototype” person overnight. We ALL wish we could change people like we can rework a software application but sadly, it is hard to update a person’s software. Most people have firmware that is baked in so you have to accommodate older firmware as you change the software. đ  So, if you are a “people organization” where developing people or changing a person is your “product”, go slow. Even a reboot may not clear their memory like you want.
And, while I am at it with technology industry buzzwords being applied to people organizations, could you drop “fail fast” from your vernacular? A product can fail fast, but failing fast with people is called “bankruptcy”. If your plan is to try something spectacular and risky with people, find a willing subset of your customers who you can rely on for honesty and loyalty. You still want them around if your new program or process fails fast. You don’t want a warehouse full of “New Coke” and not a customer left……
Oh, what about that “wagile” remark?  Well, I was at a conference in San Francisco in July and there was a keynote about micro services which naturally landed in the “Continuous Integration-Continuous Delivery” (CICD) realm and of course, CICD is one component of agile development. The keynote presenter admitted that some of the promises of agile have not been realized* and most development shops were more “wagile” than “agile”. “Wagile” being a combination of the waterfall method and agile processes. It’s true. It’s hard to constantly work through multiple iterations. Most developer types settle on a sizable chunk of development design, and then start checking in with the customer. Wagile.
Yep, when it comes to people, wagile is the way. Quite a bit of discussion and design upfront, a pilot program to see how it is received, and if all is well, increasingly rapid iterations after your people know where you are headed. Not “failing fast”, just learning as we go…. That’s the ticket: Wagile.
* To read more about the state of agile see: The State of Agile