Last week I had the opportunity to deliver a webinar titled “Leading Agile Change: Proven Change Management Approaches for Agile Transformation” to nearly 200 people from the Agile and Change Management communities. The webinar (available here) serves two basic purposes: helping corporations undergoing Agile transformations recognize the value of organizational change management and helping make change management processes more Agile. As you can imagine, this topic drew lots of interest and a lot of great thought-provoking questions were raised, but due to time limitations, we were not able to give every question equal treatment. So I figured I would choose some of the very thoughtful questions that we weren’t able to answer during the webinar and share my answers to them here.
Here they are, in no particular order:
Where would the Change Management backlog exist?
This is a great question. In the webinar we talked about a few patterns for delivering Agile Transformations that have many tried and true Change Management practices embedded in them. One of these patterns recommends a backlog of transformation activities that the organization would work on iteratively and incrementally to build towards the future state. Ideally you would use the same toolset you are using for your Agile teams. So if you’re using VersionOne, Jira, Rally, etc. you might consider creating a separate project in that tool for the Agile Transformation and manage your transformation backlog there. The nice part of doing it that way is that it also makes the transformation team’s progress visible and transparent to the whole organization.
Some organizations who are very new to Agile may not have chosen an Agile Lifecycle Management (ALM) tool yet. In that case, you could use a lightweight or free tool in the interim until the tooling decisions have been made. One example of a free and lightweight tool you could use to manage your transformation backlog is SeeNowDo. You could do it “the old-fashioned way”: set up your transformation backlog on a physical Kanban board with painters tape and post-it notes somewhere in a visible place in your office like a conference room or hallway.
What guidance do you have around business leading the Agile transformation, when the business does not own/manage IT resources?
In my experience, Agile transformations that are treated like a joint partnership or as a collaboration between the engineering/IT group and the business are most likely to succeed long-term. I have seen some organizations where the business was driving the initiative to bring Agility into the organization, and this can have success when IT is in alignment on the goals of the initiative and has a seat at the table, and I have seen it the other way around where it starts as an IT initiative but very quickly the business is brought on board and aligned to the goals of the Transformation. In other words, regardless of who manages what resources or who leads the initiative, the success of the Agile transformation depends on close collaboration between business and IT.
When it becomes a one-sided initiative with no alignment from either side of the organization, the results are usually not as profound or transformative. A recent article in Forbes by Steven Denning talks about the importance of making the whole organization Agile.
What tips do you have for leadership when dealing with the “Keeping the lights on” activities which seem to pull people back into the standard way of doing things, while the org is undergoing an Agile Adoption?
At SolutionsIQ we often use a pattern we call “Agile on Agile” to execute Agile transformations. “Agile on Agile” means using Agile concepts, like visible backlogs (sometimes on a physical wall, more often in a virtual app) with prioritized work items that we consultants and coaches pull into sprints, to promote an Agile mindset. We radiate our findings to the leaders and influencers who can help us enact change, and we empower our mentees and trainees to do what they need to do and act how they need to act. In other words, to drive home the concept of transparency or empowerment, we are ourselves transparent in our processes and we empower the individuals we work with.
This also means intervening when management or leadership have expectations more aligned to how work was done before Agile. Limiting work in progress (WIP) is an excellent example: many Agile teams use Kanban to track their progress on stories (some teams, like our own marketing team here at SolutionsIQ, use a hybrid called Scrumban, which combines Scrum and Kanban). Limiting your WIP, a core principle of Kanban, is possibly the hardest for new teams to grok, and it can sometimes give management and leadership the impression that the team “isn’t doing enough” because there’s only one or two work items in progress. But by limiting their WIP, the team can complete more work tasks, which means increased productivity. Traditionally managers and leaders rewarded multitasking (aka context switching) because it looks like more work is getting done. But it’s simply not true.
The thing I would suggest to leaders and managers, therefore, is: change your perspective. The way you’re thinking today is negatively affecting your ability to deliver. Be open to new ways of thinking and being. If your gut says to do something and that something has often gotten you in trouble, the simple thing to do is ignore your gut, ignore your instinct. Often today’s leaders and managers run on instinct but, without an Agile mindset, that instinct is only going to lead to more trouble. So quit it.
These questions are just icing on the cake of awesomeness that was our “Leading Agile Change” webinar! If you missed it, you’re in luck: you can watch it from start to finish right now in our Resource Library.