Tasks and Tips for Developing an Agile Transformation Backlog-EN

In my recent webinar presentation, The Good, the Bad & the Ugly: A 16-Month Agile Transformation Case Study, I referred to an Agile Transformation Backlog. This is actually an amalgamation that I’ve personally used over the last 8 years based on the combined concepts of the Agile Product Backlog Kanban Board and the Six Sigma approach of continuous process improvement (Define, Measure, Analyze, Improve, Control).

If you are reading this article, perhaps your organization is in the midst of or wanting to pursue an agile transformation. Whether your transformation is based on Scrum, Kanban, SAFe, or whatever combination thereof, hopefully you’ve done your due diligence and have the justification and data to support the transformation. This is not a step to be ignored. All the tips in the world won’t ensure success if you haven’t developed a business case based on realistic expectations of the cost and benefits of Agile.

That said, the next step in a transformation should be determining the gaps between the AS IS Current State and the TO BE Future State. This list of gaps, differences, and changes to your business-as-usual model will generate a long list of actions and to-do items. What is the best way to manage, prioritize, and show visible progress? An Agile Transformation Backlog.

The Transformation Board

In my webinar, there were several slides that showed TO DO, DOING, and DONE items. Instead of the product backlog being a list of features, epics, stories, or bugs, the actions and to-dos that came from the gap analysis are listed as simply “work items”. In the case study, I was brought in as a consultant and held a few workshops to do the gap analysis. Our agile transformation backlog included work items like the following:

• SAFe orientation for management
• Realign teams
• Create Communities of Practice and Guilds
• Boot camp training for business and technical team members
• Role specific training (i.e. Coders, Testers, Business Analyst)
• Define business value and value streams
• Define, generate, and leverage metrics and KPIs
• Define a consistent sizing format
• Establish Shared Services
• Create co-located work environments
• Adjust titles, roles, and job descriptions
• Backfill positions based on new roles (i.e. Release Train Engineer, Product Owner)
• Set up ongoing coaching and mentoring for new Scrum Masters
• Create a cross-functional training framework
• Set up an agile-focused DevOps environment
• Create a test automation strategy
• Sunset old ceremonies
• Set up new ceremonies (i.e. Program Increment Planning, Scrum of Scrum)

This list will vary organization by organization. Work items will be at all levels – team, program, and portfolio. Many of the items I listed above are Epics and will need to be broken down into smaller increments.

Managing the Agile Transformation Backlog also allows the team overseeing the transformation to practice agile principles. I often use some of the sprint ceremonies to effectively communicate. We held daily stand ups with the core transformation team, and at the end of the week a show-and-tell call was scheduled for anyone that wanted to dial in and hear about the progress and the objectives for the upcoming weeks. Note: many work items will not require a sprint cadence, so you don’t have to wait for a sprint to end for delivery.

Like all backlogs, the biggest value is visually showing the work and the transparency. Anyone can add to the backlog. This allows you to capture any concerns, roadblocks, or hurdles that the core transformation team may not have thought about. It was actually a team member that first suggested a transformation retrospective, so we created a work item, and now it’s a staple on the backlog. At the end of a sprint cycle we let those affected by the transformation talk about what’s working and what’s not working. The Transformation Board is meant to belong to everyone, not just the team coordinating the transformation.

An Agile Transformation should not feel like a top-down implementation. Quite often the catalyst for change around agile comes from the bottom-up. The Transformation Board is a great tool to let the teams drive the backlog priorities.

Adjustments to be Made

When you are working on a transformation work item, one key adjustment to make from the typical “Design, Code, Test, and Deploy” model is to replace it with steps that are traditionally associated with continuous improvement. The tasks associated with the transformation work items will align with Six Sigma. For each work item, you want to:

1. Define the work item with the outcome and value in mind.
2. Identify the measurement of success. (This is the “So That” element in user stories.)
3. Analyze and establish your AS IS metrics so you have something to compare to when determining if the change was successful.
4. Implement the improvements.
5. Give them ample time (i.e. two or three sprints) to see if they add value and serve their purpose.
6. Control though checkpoints and shared accountability. Sometimes without accountability it’s easy to revert to bad habits and behaviors.

Also, here are a few tips and characteristics of a product backlog that you can use for your transformation backlog framework:

1. A product backlog is a list of the new items or changes to items.
2. The product backlog is the source for things that the transformation stakeholders will work on.
3. Items in the backlog are placeholders until they get prioritized to the top of the list. Some items may never make it to the top of the list.
4. Anyone can add items to the backlog.
5. From time to time, stakeholders can agree to remove items from the backlog.
6. The transformation stakeholders can decide on the format of the items in the backlog.
7. When an item is about to be worked on, sufficient details should be provided to help ensure the right outcome and solution (i.e. acceptance criteria, scenarios and/or examples).
8. Items worked on should be broken down into increments.
9. The Product Owner (with the advice and input of the team/stakeholders) should regularly prioritize and sequence the backlog.
10. Each work item should have an Owner/Lead.
11. The outcome of the work done on a work item should be demonstrated to the stakeholders so they can agree if it addresses the purpose of that item.
12. The team owns the backlog, and as a team they should agree on one person to be designated as the transformation Product Owner. This person will be the most accountable for the outcome as the decision-maker or the proxy for the person financing the transformation.

The product backlog can be represented in physical form using index cards or sticky notes, or it may be represented in electronic form such as a text file, spreadsheet, or one of the many backlog management tools that exist. Electronic boards are a good option for a team that has remote members. But when possible, I still prefer physical boards because they offer the advantage of making the product backlog continuously visible and tangible during discussions.

A transformation backlog can be an effective way for a team to communicate what they are working on and what they plan to work on next. The most valuable aspect of the transformation backlog is that it allows all teams to see the ongoing progress. Also, stakeholders and team members can look at the backlog and see their ideas and suggestions are being considered.

Remember, it’s a continuous cycle, and some changes won’t be perfect, but Agile is about “learning fast”. Some work items are learning experiences that will inevitably generate more work items. Your goal is not to have an empty backlog so that you can declare the transformation done. The Agile environment is a continuous learning environment and the agile industry as a whole is always maturing and evolving. Your backlog may get smaller and the daily, and even 2-week, cadence may not be necessary, but plan to expect 16 – 24 months for a total Agile mindset transformation. Of course, there are much shorter transformations, but from experience I can say the bigger the investment, the bigger the pay off.

Thank you,

Jacqueline