Adopting to Agile — Through an Infant's Eyes
Observing the actions of his newborn son, a Zone Leader wonders just how closely these actions match that of the adoption of the Agile framework.
Join the DZone community and get the full member experience.Join For Free
My newborn son will turn nine months old in May. Not too long after he was born, he reached the stage of "putting everything into his mouth" as a way to learn about the world. Mapping his actions to a simple flow resembles something like this:
When he has his mind set on putting something into his mouth, the object being evaluated falls into two categorizations: something he recognizes and something that is new. Either way, the primary objective is to put the item into his mouth so that he can learn more about the item.
If it is something he is familiar with and likes, he explores the item using the senses in his mouth. The same holds true for a new item. However, if he doesn't enjoy the new item, his dislike is equated to dropping the item—or removing it from his mouth.
I wondered how this simple flow can be applied to adoption of the Agile framework.
Evaluating Something New
When the Scaled Agile Framework (SAFe) began to gain momentum a few years ago, I found myself at the doorway to learning something new. At that point, I believe my thought process matched that of my new-born son.
Since I was familiar with core Agile concepts, the SAFe concept was not 100% new to me. For those items I had experience with, they fell into two categories: items I found value in and appreciated and items I didn't see the true value in implementing. The former items found their way into my senses of appreciation, while the latter were dropped onto the metaphorical floor.
When I began to understand SAFe foundational components (like Release Trains, Shared Services and an Architecture Runway, as an example) I took a moment to comprehend the value behind each aspect. On one particular project, the implementation of Shared Services was a welcomed concept—since each of the 17, agile teams struggled with getting support from those groups which were ultimately morphed into the Shared Services group. Using my son's metaphor, Shared Services found its way into my senses, it was something I found beneficial and remained at the forefront of my focus.
However, for that same project, the concept of Release Trains was attempted, but results were far from favorable. In this instance, the overhead associated with maintaining a Release Train far outweighed the value that was provided. The same was true for an Architecture Runway. This project was at a point of maturity where the need for Enterprise Architecture (EA) and future design strategies were just not beneficial. In both cases, the taste did not appeal to me (in a metaphorical sense) and both were dropped to the ground.
Agile Is Not A One Stop Shop
I have written in earlier posts that Agile implementation is not a one-stop shop. One, in particular, is the "Agile - For the Sake of Being Agile" post from May 2017.
I firmly believe that enterprises or development teams should understand the core concepts behind Agile and even further-reaching concepts (like SAFe) and figure out what provides value to the Agile teams and which aspects do not. Using my son's flow diagram as an example, those items which appeal to you should be kept to the forefront of your senses. Those which do not should be dropped and placed on the road behind you.
Have a really great day!
Opinions expressed by DZone contributors are their own.