If you’ve ever participated in an agile project, you’re likely well versed in the concept of the “happy path.” In case you haven’t been exposed to the term before, the happy path is meant to describe the ideal process, without any exceptions or alternate paths. This often serves as the default process and exceptions and alternatives branch off of it. These processes (happy and “unhappy”) are described in use cases, wherein exceptions and alternatives are segregated and described separately. The initial product delivery is often primarily focused on delivering the happy path process.
The “happy path” may also be considered something of a “state of mind” for Agile projects in which positivity and optimism infect other aspects of projects like too firmly committed projected deadlines and (under) estimated hours to complete a task. According to Richard Dalton, at www.devjoy.com, “Happy path thinking results in inadequate exception handling, logging, and even testing. It can result in entire usage scenarios being missed. The result is often brittle code that is unfit for [the] purpose and difficult, if not impossible, to maintain and enhance.”
It seems as if the concept of “Agile” has gotten all tangled up in the concept of “happy path,” and it seems as if this has become a problem. A vast number of processes can have a complex happy path that may have “alternatives” built into them. Any step in the process that incorporates options can create a branch in the process that is just as valid as the other branch. This can’t be considered an exception or alternate if it’s a valid, equally probable option. If a process has more than one option like this in the happy path, you’ve got a multi-variate process that doesn’t fall into the nice, neat cookie-cutter of the happy path. This will make some project teams freak out, or at the very least, grumble.
The whole concept of Agile is meant to be flexible and able to address changes in deadlines, make adjustments to requirements that hone processes, and work iteratively as based upon realistic estimates and client response to sprint demos. Per Adrian Pavia at www.govloop.com, “The essence of agile is that business and IT groups work more closely together, delivering solutions in smaller bites, to ensure they are working on the right path. The smaller bites…are designed to show results and deliver value early through pilots or a proof of concept.” As input is gained, changes can and should be made to requirements and project plans. That means that blind “happy path thinking” isn’t going to help anyone get their jobs done better or deliver a product the client is actually happy to receive.
Half of the challenge of Agile projects is making clients comfortable with the process, ensuring that all team members are on board with the methodology, and actually BEING agile in response to changes and project adjustments. Bear the grumbling, but prevent the freakouts by managing team and client expectations at project initiation and throughout the lifecycle. Changes will most likely happen. And that is okay. Don’t panic.
I’m not saying there can’t be happy paths or even happy path thinking, but you can’t let either of those falsely promising terms become a millstone around the project’s neck. It’s wise to be proactive, anticipating potential issues so that they can be addressed before they become problems. Keep in mind that you don’t know what you don’t know and discovery is a very real aspect of the Agile process. With the right approach, however, it shouldn’t be a tragedy to discover changes.
If you are finding yourself unhappily traveling down the happy path, call us at ArchiTECH Solutions. We have experience carving out the THE path, and we can help your with your Agile projects, managing expectations, and delivering a solution that works. Contact us by email at email@example.com or call 703-972-9155.