Phone Number*

City*

Thriving Through an Agile Evolution

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.

1st 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.

2nd 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

Initiate conversations with management prior to the methodology shift.

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.

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.

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.

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.

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.

Outline/Structure of the Case Study

Under our project, the role of the product owners was to represent the business and customer base, and the primary responsibility was managing requirements and our backlog. The government IT PMs managed the contractors and ensured the success of the project by setting methodologies, managed adherence to federal IT guidelines, and assisted in following the CIO vision on the government side. The IT PMs were concerned mainly with process efficiency and oversight, and the product owners were concerned with story government completion and completing work from the backlog.

Presentation Outline:

Introduction and Personal Context – explaining the concept of the session and how it relates to my personal experience with agile development as a contractor in the public sector.

Problem Definition and Case Study – defining the context and background of the transition problem and setting the parameters for the case study.

The Question of Kanban – explaining the potential issues with Kanban in the contract setting and some of the issues we experienced.

The Scrum Shift – an overview of the expectations and original plans over the short timeframe allotted.

Challenges Faced – discussing the discovery process of the issues that came up and how we prioritized or understood them.

Resolving for the Future – reviewing the processes of improvement and solutions management we investigated and the ultimate solutions.

Generalizing from the Specifics – how to take these specific experiences and apply them in various scenarios and situations, focusing on the cases of transitions and customer oversight.

Hope for Tomorrow – understanding how each pain point led to an improved process and a better way to meet the customer needs in the future.

Learning Outcome

Learn how to quickly adapt to changing priorities of our IT customers.

Learn how to handle culture changes when adapting a new agile methodology within the team.