Have you ever encountered a situation where clients change priorities on you? What about when those priorities are deep into the methodologies of your team? This session addresses challenges some mature agile teams may face when the agile processes evolve over time - fluctuating priorities, organizational changes, or incorporating new methodologies. Learn how to adapt strategies for quickly shifting priorities and adjusting to a new agile culture.

I work on a team as a contractor in the public sector within a portfolio of six agile teams and over sixty agile professionals. Over the last year, we have experienced significant changes, primarily changing between five different government IT Project Managers (PM) and two different product owners. Many of these changes were due to regulatory requirements, internal restructuring, or simply career moves, but the impact on our team came down to a simple truth: They all wanted to do agile differently. This session explores how to thrive while evolving your agile processes to meet changing priorities

INITIAL STATE – Focus on the Backlog and O&M

Our first IT PM had a more point-by-point focus on the backlog, with a priority more on performing O&M tasks than new functionality.

1^st EVOLUTION – Team-Managed Backlog

The next PM had a more strategic style of communication management. The backlog became more team-managed, which had its advantages and disadvantages; we had an improved buy-in for new research and story development, but it was a lot easier to lose tracks of the priorities without the same level of feedback. We also had to change our strategy to address a more structured release schedule, which was not ideally suited to the same Kanban approach, although this changed schedule more closely aligned with the customer’s deployment needs.

2^nd EVOLUTION – Shifting from Kanban to Scrum

Our most radical shift was from Kanban to Scrum. In retrospect, this was a choice that made sense, but at the time there were a lot of challenges we needed to overcome. The PM wanted more visibility into the day-to-day work being done by the team, and the Scrum approach was a better way to meet the customer’s needs. This was ultimately a better choice for our team, but we only had a month to make the transition:

• The story board changed to define user stories and tasks differently, changing our planning procedures and the development process. This also affected the individual story workflow, which required internal training meetings for all developers, testers, and PMs.
• Agile ceremonies were changed several times as we worked with the customer to determine the best ways to include their feedback and improve our own processes.
• Release deployment changed to a time boxed, two-week sprint schedule, requiring changes to how we had been handling deployments and production support, which previously could be done on a more ad hoc basis.

The Scrum approach requested by the customer had an overall net positive effect for our development efforts and the oversight requirements by the IT PM, allowing for more effective communication to and from the customer, lower developer burnout, improved time management, and better use of planning overall.

Adaptation Strategies for Quickly Changing Priorities

1. Initiate conversations with management prior to the methodology shift.
2. Increase visibility for customer down to the story lifecycle.
3. Determine ideal mechanisms for generating feedback and iterating process improvement.
4. Focus ceremonies and meetings to reduce overhead and promote higher customer value.

Key Evolutionary Metamorphosis

1. Due to the methodology changes, our product releases became more frequent than expected, so we developed automated deployment strategies, including standardizing release schedule and documentation.
   
   
2. Our new stories began to include higher overhead than initially anticipated, so we refocused planning efforts and moved towards a more careful circle on task estimates.
   
   
3. The prioritization on legacy maintenance led to over-reliance on specific individuals and their targeted experience, causing frequent problems with knowledge management when the release timing was critical. We increased knowledge sharing sessions, spread out assignments, and created fully featured transition plans.
   
   
4. When we first started the transition, our instincts to satisfy customer requirements and release quality products often led to over-planning and more meetings than were helpful. We created customer justifications and rationale for reduced meeting count and focused attendance. Meeting agendas were always prepared in advance even for sprint grooming and planning sessions.
   
   
5. The release schedule and expectations to our desired velocity tended to focus on reactive measures instead proactive ones, deprioritizing automation strategies over adding more stories to the potential releases. We refocused the customer perspective to incorporate Test-Driven Development (TDD) and pipeline focus, allowing higher prioritizing of UI and other test automation.

Ultimately, we determined that the keys for success are empowering the client, but keeping the choice to a well-managed scrum list of stories.

Culture Changes Needed for Adaptation

1. Greater pre-planning and tactical preparation for agile ceremonies and sprint planning.
2. Highlight focus on automation and pipeline integration.
3. Consider the critical elements of the end user’s experience.