The HBR article Embracing Agile was helpful as an introduction to the language of Agile and I found it more accessible than the Project Management Book of Knowledge. I find agile methodology somewhat “jargon-y” and will likely refer to this article often to build comfort with the terminology.
Agile is most frequently used in reference to physicality, and the idea of being able to move quickly and decisively. Even mental agility is perceived as being able to draw answers quickly and with confidence. As a method, Agile requires a different kind of confidence - that of knowing that things can be done better, that there is room to grow and learn. The common thread between physical/mental agility and agile methodology is the ability to make changes on the fly in response to internal and external variables.
Teams can misuse (or miss entirely) agile methodology when they refuse to look backwards in order to move forwards, or when they try to shoehorn existing work into future needs. In this way what has been labeled “agile” is actually a waterfall approach with small, immaterial changes between stages.
I had difficulty with the idea of a minimal viable product, not as an academic concept but from a psychological perspective. A traditional, transactional HR approach calls for items to be crossed off the list, not moved to the next stage of incompleteness. During the Summer ‘21 Capstone I learned to embrace the process to create a better product, to sit in the discomfort of uncertainty as an innovation driver.
The main roadblock in an agile environment is knowing “when to say when”. Scope creep, too few iterations, too many iterations, etc. can all derail a project. Organizations that do not empower their product owner to say no on behalf of the team could be railroaded by stakeholders.
Comments