‘Agility’ implies flexibility. To a novice, the flexibility of agile methods may be interpreted as the absence of any encumbering process that would force rigidity or a certain set of rules. Some government agencies, upon adopting agile, assume this practice will afford a limitless degree of flexibility in decision making. But this perspective damages the efficacy of a true agile practice.
As a simple example, consider a product owner in government that holds a meeting with the CIO and stakeholders, learns of new priorities, and immediately desires to change the direction of the Scrum team (mid-sprint). While we must concede that emergency circumstances sometimes arise and team members may need to unexpectedly shift gears, this is not typically how a sprint should run.
Understanding the framework
Agile promotes flexibility by allowing for shifting priorities at key points during the process, but maintains within itself some well-defined and established practices that should not be flexible. Agile is not an “anything goes” framework.
The tenets of agile promote continuous learning through iteration, which can inherently allow a degree of flexibility with an emphasis on what adds the most value. This flexibility is established through well-defined agile ceremonies and tools. The sprint cycle, for example, is a fixed period of time (usually two weeks) and goals are determined by priority at the beginning of a sprint. This is driven through the effective use of the backlog, grooming, sprint planning, daily scrums, sprint demos, and sprint retrospectives — all of which act as building blocks of a framework that should be understood and respected.
Respecting the framework
The observation of all agile ceremonies should not be optional, and any decision to deviate from them should be made with extreme caution. Each ceremony provides an integral part of a holistic and thoughtful agile implementation. Foregoing any ceremony could hurt the efficacy of what agile offers — the benefits of transparency, collaboration, prioritization, and empowerment.
If your agency is just beginning to practice agile, be careful not to mistake open-ended flexibility with a true agile practice. Remember the term “framework” is defined as a set of best practices that are intended to be applied in differing ways. You may have to experiment to discover the best application of the agile framework for your team, but that doesn’t mean the framework itself goes out the window.
Two of the most well-known applications of the agile framework are the Scrum and Kanban methodologies. While the ceremonies remain largely the same, the principal difference between Scrum and Kanban is focused on the method of prioritization within a sprint. Kanban tends to be better for more fluid prioritization while Scrum tends to prioritize a set of tasks that align with larger, known sprint goals. The “first come, first serve” Kanban model is often effective for a cross-functional team performing a set of diverse and rapid improvements prioritized within the backlog. This may happen immediately before the launch of a product that is in beta testing or a product that is in maintenance. The Scrum format provides the structure to effectively manage high priority features within active development phases.
Simply understanding the difference between the two, and knowing which is best for your team, can make a huge difference for effective agile team operations. You don’t want to be working against yourself by adopting a methodology that doesn’t match your agency’s project and team needs.
Adjusting the framework (if you must)
In the spirit of “People Over Process,” a true agile team should be open to an evolving practice, not blindly adhering to a methodology that simply doesn’t work for the situation. This is especially true in government, where procurement and other challenges may sometimes cause direct conflict with an agile process.
Some of the most popular agile adjustments have been widely communicated as “ScrumButs” — which is short for “I practice Scrum, but ….” and is followed by an amendment to conventional agile. I have often found ScrumButs useful for communicating adjustments for specific project or contract needs. However, I’ve also seen ScrumButs used to introduce conventional waterfall practices under the guise of agile. ScrumButs should be used sparingly and implemented with caution.
While agile may not be as flexible as some may initially suppose, it is still an incredibly empowering tool that has some flexibility baked in. All participants should be well versed in agile principles before making any adjustments to a standard agile practice. And — most importantly — follow the process that allows you to serve citizens and customers most effectively, even if this means not using agile at all.
Adam Bergstein writes on behalf of Agile Government Leadership, a community-powered effort to provide resources and build a network around agile practices in government.
This is good stuff. Well written.