The Problems they Signal and Mitigations
SECOND EDITION
By George Sammit
Texas, USA
Introduction
Managing agile projects is becoming more prevalent and is escaping the software development realm. When executed properly, agile methods may be considered a risk reduction strategy, e.g. avoiding low end-user utility. They may also provide opportunities, e.g. reduced time-to-market. However, when poorly or improperly executed, the very risks that agility purports to reduce may manifest as problems. Sometimes these problems are subtle – perhaps mere inefficiencies or unreported technical debt – but they tend to snowball over time. Other times, they are forthright. Regardless, they have a negative effect on project performance. Therefore, it is important that project managers (PM) understand how to identify triggers of the fundamental risks associated with agile projects. To achieve that, this work presents a series of red flags – missteps, anti-patterns, warnings – across all phases of the project lifecycle. Grounded in both the author’s personal experience and research, these red flags signify the forthcoming realization of agility problems or “not quite agile” agile projects.
The work is organized as follows. A brief introduction to agility is presented making it suitable for readers with little experience with this concept. Similarly, given the extreme popularity of Scrum (and Scrum hybrids) in the agile community, a Scrum overview is presented. The bulk of content enumerates the red flags, the problems that they may be signaling, and what can be done to control/avoid them – in essence an agile risk register. The problems presented are related to fundamental concepts of agility and agile practices, and not specific project types or domains.
Brief Introduction to Agility
Agility is arguably an adaption incremental commitment spiral model [1] for software development which takes a value-based approach to building a system gradually. It relies on high-accountability and concurrent development. Perhaps most important are the risk-based decision gates that drive progression. Around the turn of the 20th century, the software development world was shifting from a traditional, highly structured, sequential delivery model. Why? Perhaps, this was a direct result of a malleability curse on software. Given that software was not the predominant factor in systems development, combine with its perceived easy and lower cost to change, it became the resolution to system development problems – just fix it via software. It also became more prevalent in day-to-day life of many people. During this evolution, practitioners around the world joined and created the Manifesto for Agile Software Development [2] which remains a guiding principle of agility today. There are four key points to this proclamation which form the basis for the 12 principles of agile development (not shown due to page limitations) [2].
- Human interactions are more fruitful than bureaucratic processes/procedures.
- Working products are more meaningful and illustrative than documents about them.
- Customer feedback is superior to interpretations of specifications.
- Change is inevitable and should be acknowledged and embraced, but planning is important.
One may structure a project around these concepts and achieve high levels of success as has been proven over the years [3]. Agile projects are iterative and incremental refinements of a product. They employ a lean mindset and err on the side of delaying decisions as long as responsibly possible. They rely on high levels of automation to achieve rapid product releases and rely on end-user feedback to help shape the product under development.
Scrum
Scrum is the most popular of the agile methods [3] although it is technically a framework [4]. The theory is simple – iteratively and incrementally move toward a vision, learning, reflecting, and adapting as you go. In addition to the utmost transparency, it relies on:
- A product owner that prioritizes the work and acts as an interface between the various stakeholders and the Scrum team. A product is implied here, and that is what is being built which could be a component of a product or a sub-system of a system. The work required to achieve the vision for the product is kept as a prioritized list called a backlog.
- The Scrum team is a group of individuals (usually around 7 [5]) that have the skills to build the product and are empowered to do so. They work in increments, often 2–4-week increments [5].
- The Scrum team has no leader, they are self-governing. However, it does have a Scrum master who is responsible for ensuring the team is aligned with the framework, adhering to their agreed upon working rules, are focused on project work, and not blocked or distracted by external entities.
- A product increment is a fully functional feature of the product that provides utility to the end-user. It may be very minor utility, but notion of usability must be present.
At the beginning of each increment (sprint), the product owner prioritizes the work from all of the known work (product backlog), including any new work just discovered. The Scrum team negotiates with the product owner as to how much of that work can be accomplished during the sprint. The work is elaborated, and the Scrum team commits to completing it. The product owner commits to not changing scope during the increment. That list of work to be performed during the time-bound increment work cycle (sprint) is moved into an increment backlog. Work begins, and each day the Scrum team replans how they will achieve their goal. The product owner begins elaborating the work for the next increment. At the end of the sprint the product owner and Scrum team inspect the product increment and invite stakeholders to provide feedback. This feedback informs the work that the product owner again prioritizes. This loop repeats.
Project Initiation Red Flags
Starting a project off on the right foot is important regardless of development methodology chosen. However, there are a few traps to avoid that are particularly pertinent to agile projects.
More…
To read entire paper, click here
Editor’s note: Second Editions are previously published papers that have continued relevance in today’s project management world, or which were originally published in conference proceedings or in a language other than English. Original publication acknowledged; authors retain copyright. This paper was originally prepared for the 15th UT Dallas PM Symposium in May 2023, which the author was unable to attend. It is published here with the permission of the author and conference organizers.
How to cite this paper: Sammit, G. (2023). Agile Red Flags: The Problems they Signal and Mitigations; prepared for the 15th University of Texas at Dallas Project Management Symposium in Richardson, TX, USA in May 2023; PM World Journal, Vol. XII, Issue VIII, August. Available online at https://pmworldlibrary.net/wp-content/uploads/2023/08/pmwj132-Aug2023-Sammit-Agile-Red-Flags.pdf
About the Author
George Sammit
San Antonio, Texas, USA
George Sammit has been developing commercial software applications for nearly thirty years and leading such efforts for over twenty. He is a Principal Computer Scientist at the Southwest Research Institute, an independent non-profit research organization which has been advancing science through applied technology for 75 years. There, he serves as an advisor in the Intelligent Systems Division which executes programs and projects that will improve human life. He holds both a B.S. in Computer Science and an M.S. in Program and Project Management from The University of Michigan and is a doctoral candidate at The Southern Methodist University studying Software Engineering. George is an active PMI member holding the PMP credential and an active Scrum Alliance member holding the Certified Scrum Professional credential among others. ■ george.sammit@swri.org ■ https://www.linkedin.com/in/george-sammit/
