Five Agile Development Lessons from Will Ferrell

Tuesday, June 2, 2020

#Team Integration    #Automotive Agile

Not knowing your team’s velocity is like skateboarding into electrical wires: It seems fun at first, eventually hurts, and possibly kills the team.


Agile Development is like many buzzwords such as “Big Data,” “Digital Transformation” and "User Experience." Everybody wants it, but no one really understands it.

Why do they want it, then? Like many things in life: Follow the money. Studies have shown there’s a 1,872% return on investment from converting to Agile Development due to increases in productivity and quality while reducing cost.

Of those that have successfully implemented the process change, 84% report an increase in the ability to manage customer priorities, 71% report improved speed to market and 65% report a reduction in risk. The words sound promising, and suggest you are in control.

But here’s the rub: Not many people understand what it really takes to properly implement Agile and they launch into a half-baked version instead. Nowhere is this truer than in automotive, because the Agile Manifesto and Scrum (a method within Agile) do not perfectly translate to things like Functional Safety and Automotive-SPICE. This is where  many corporations proceed in ignorance and fail.

Using pop-culture examples for training exercises is like the spoonful of sugar helping the medicine go down, and who better to lighten things up than Will Ferrell? Please enjoy these nuggets of wisdom. If you haven’t learned how to avoid the typical pitfalls of Agile Development by the end, seek professional help. No, seriously. Get help.

Lesson #1: Shorter Doesn’t Always Mean Better

In a Saturday Night Live skit, Dale McGrew (played by Ferrell) gets the company memo from his boss that they should wear something patriotic to the office to celebrate the U.S. Dale decides to wear a halter top and bikini shorts figuring that shorter is great. He soon finds out that, in fact, shorter doesn’t always mean better.

This also is true for Agile. We consulted at a company that couldn’t complete its sprints in two weeks, so it decided releasing every week would improve things. It absolutely didn’t. In fact, it added additional overhead, making them less efficient. Shortening the Sprint as a knee-jerk reaction to poor planning and execution will almost never solve the issue.  And let me assure you: This may seem like an odd or unusual occurrence, but it is the easiest variable to adjust, so many managers assume releasing more often will make them “more Agile.” Untrue. Sprinting more often does not equal Agile.

Lesson #2: Failure Does Not Scale-Up to Success

Darnell Lewis (played by Kevin Hart) is the quasi-program manager of jail-preparation training for billionaire James King (played by Ferrell) in the comedy "Get Hard."

Darnell tries multiple lessons with his hopelessly naïve pupil to get him battle-ready for the chaotic, gang-ridden world of incarceration, but he keeps failing. Darnell continues the lessons with the mindset of “If first you don’t succeed, try, try, again.” But eventually he realizes that repeated failure does not scale-up to success.

This difficult lesson is one that should be obvious in Agile Development, but the psychological phenomenon known as Optimism Bias leads the Agile Masters to believe they will succeed in six months despite failing every two weeks. If these companies were truly practicing Agile methodologies, their plans would adjust based upon the previous velocities and they would quickly begin to deliver to commitments. But that first assumes the leaders recognize the failures and adjust their planning.

Hence, many companies act exactly like Darnell Lewis: they repeatedly believe they can catchup despite a broken process and multiple failures.

Lesson #3: Create T-shaped Team Members

As captured by the 2015 HBO Special called "Ferrell Takes the Field," Ferrell does an all-new stunt in the history of baseball: Playing ten different positions on ten different Major League Baseball teams all within one day. Will played everything from right fielder to third-base coach, then helicoptered to the next Cactus League (preseason) game. I’m sure if Will was truly honest about his athletic prowess, he would admit he’s not proficient at all baseball positions, but he didn’t make a single error.

Versatility is what you want to build within your Agile team. Yes, you need employees to be functional specialists at times and, therein, “a mile deep,” but you also want them to be “a foot deep across a mile” so they can cover a wide variety of tasks. Why? If some tasks can be fielded by a variety of teammates, it avoids bottlenecks in the development.

For instance, if Tom the Tester is overloaded and Dave the Developer finishes early, Dave might be able to run some of the backlogged tests. Conversely, if Rachel the Requirements Engineer has fallen behind (which frequently happens in automotive requirements), Dave can help with refinement and get User Stories ready for future Sprint(s). Therein, no one is starting without requirements, no one is wasting valuable time by just waiting and resource planning can have redundancies for both efficiency and succession planning.

Making your team T-shaped sounds easy in an article, but it takes concerted efforts of training and pushing people where they normally aren’t 100% comfortable.

Lesson #4: Sprinting Doesn’t Make You Agile

In one of his most famous roles, Ferrell plays Ricky Bobby, a NASCAR egomaniac with nonsensical slogans such as “If you’re not first, you’re last.”

In a classic car-wreck scene, he eventually escapes from the wreckage and begins sprinting from imaginary flames. “Help me, I’m on fire,” he screams while running aimlessly. As you can imagine, sprinting for sprinting’s sake doesn’t do him much good.

The same is true for Agile Development. We cannot begin to enumerate how many companies have told us “Oh, we’re already Agile” when, in fact, they simply release every two weeks and call it a Sprint. Announcing the team will now be sprinting and then hammering on your development team to release code is not Agile; it’s a quick way to create turnover and, in the end, accomplish less. Sprinting with a plan that adjusts based upon capability, availability, velocity, priority and a few other “ty” words will end in another “ty” (“thank you”) from your management and employees.

Lesson #5: Know Your Team’s Velocity

In the movie "Daddy's Home," Ferrell’s character Brad Whitaker is a stepdad who is just getting traction with his adopted family when the biological dad, Dusty Mayron (played by Mark Wahlberg), returns to win over the wife and children. In a hilarious scene, Whitaker comes home to find his competition has built a half-pipe in the backyard, so he decides to one-up this coolness by skateboarding off the roof and into the halfpipe.

As it turns out, Brad doesn’t realize his own velocity, flies up into high-voltage wires overhead and must be resuscitated by Mayron, who gives the horrified children a condescending safety lesson.

Likewise, knowing the velocity of your team is the biggest part of Agile Development because it allows you to create a plan, stick to it, and deliver. That allows the business planners to appropriately estimate the Cost of Goods Sold (COGS), set the price with a delivery date and eventually realize the margins without emergency costs like overtime or special shipping. Yes, there may be other efficiencies realized by Agile, but none of those are as important as understanding your team’s velocity.

Not knowing your team’s velocity is like skateboarding into electrical wires: It seems fun at first, eventually hurts, and possibly kills the team.


So in the end, Will Ferrell actually is quite agile. Okay, okay, maybe not as Ricky Bobby running around the track in his tightie-whities or, even worse, as Frank in Old School running naked down the street. But Ferrell demonstrates how good ideas can go wrong without proper execution. And at that, he is a genius.

That said, maybe he too should seek professional help


Do you need to improve your automotive product development, to increase efficiency, or to comply with ASPICE and Functional Safety? You are at the right place.