Agile development methodologies have been widely adopted by many industries for over two decades as a more effective and efficient way to manage product development than the often disparaged “waterfall” model. No arguments there, but let’s keep in mind there are always trade offs.
The idea of “Agile” in software development can be deceptive. What I mean is that when someone, or some process, is being “agile”, that is a lot better than being “rigid”, right? Sure, definitely.
But we often miss the fact that it’s not just something or someone else that will make my life better because they are being “agile”. It’s also us going to be up to each one of us individually that will need the agility to pivot and respond much more, and much more often, to increasingly complex changes in the environment, unlike that of the traditional waterfall development experience.
When “Agile” applies to me just as much as anyone else, well that actually sometimes make our lives as developers, analysts, testers, product owners and managers rather complex and sometimes more hectic than a more structured Waterfall model. Why? Because the context switching is more frequent. One can find themselvs switching back and forth between: Define –> Design –> Develop –> Deliver (“Integrate”) –> Deploy, several times during the week across two, three or even four different Stories. (Testing occurs at each phase).
In sum, when the environment and team around me is responding to my needs in its best form of “Agile” then we smile 😃.
But when it’s our turn to be agile for someone else (for the third time today), the 😃 can quickly fade to a 😣 .
My Blog 