Change is hard and organizations get intimidated or overwhelmed by the chaos that typically accompanies a major change, like an Agile transformation. Get your organization ready for the transformation so your org can reap the benefits of Agile sooner.
In this webinar, David Hawks walked through the Path to Agility®, 5 common Agile transformation challenges, and actions organizations can take to combat those challenges.
Recording
Q&A Transcription
How would you work with a state agency that is not going out of business and is not focused on performance metrics?
I would go back to the goal of this state agency. It might be that we are trying to serve our customers and so the goal may be to find out how can we serve our customers better as opposed to maximizing profit–or something like that.
What is compelling? Why are people there? Why do they have that job? What can we do to serve that compelling quality and what are the constraints that are getting in the way?
I would still focus on Align and try to figure out something motivational. In the end, if everybody says things are fine the way they are then you are probably not going to find enough of a compelling reason for change and you should just keep doing what you are doing. However, there is typically something we can always get better at–it just might not be the right time or environment.
What about integrating maintenance of software vs new work? In our experience, maintenance emergencies interfere with focus. Do you advocate for a team to hand off maintenance of a product if they are working on new features?
The standard coaching answer is “It depends,” but let’s go through a couple options together.
The first thing I would want to know is the size of your organization and how many different products it creates. Say I had an organization with 6 teams on the same product and that product had enough maintenance/support types of things to keep one team busy. One way of reducing complexity would be to have one team go be the firefighting team, and five teams doing Scrum focused on achieving the backlog. That is a structural way to reduce complexity so all the teams aren’t being interrupted all the time.
The downside that people usually highlight is that the teams developing the features are not eating their own dog food, so they might write bad code. That is probably more of a cultural issue. If the new development teams are ok writing bad code and throwing it over to the support team to fix, there is probably a larger underlying problem that needs attention.
I have also seen teams that are trying to balance a bit of both. The first thing I would do is measure the interruptions. Are they rare? Less than 5% of your time? Ok, maybe that’s fine. But if you said interruptions are 50% of the teams’ time then that’s going to be a significant problem.
Anytime we are reducing complexity we are attacking sources of volatility. So where is the volatility coming from? The other thing we want to do is try and get visibility to the problem so so we can measure the amount of interruption.
I had someone in our Advanced ScrumMaster class the past two days, that said they were getting a lot of interruptions, and it felt significant but they weren’t sure. So they started to track all of them by writing them on post-its and putting them on the wall. In 2-3 weeks, they had a hundred post-its on the wall, which exposes them to the problem. They were then able to show that to management who had been frustrated that the team wasn’t getting as much done as they were supposed to. The team was able to say “Hey, we didn’t get the two things done in our sprint, but we did get a hundred things done that are over here”. That created visibility for management to then consider ways to reduce interruptions.
Any suggestions on how to get management to come up with organizational and impediment management plans?
The first thing you have to figure out is how to create awareness with them–many people think Agile is just a team problem and not an organizational problem. So how can you expose and create awareness that there is an organizational problem? Is that by all the ScrumMasters of teams raising visibility of all the organizational impediments and making those visible on a board somewhere or helping them understand this journey?
We have a short version of the Path to Agility® that can help show them this is a lot bigger than they think it is. Anytime you are trying to influence up there is an element of trying to understand their pain, their view on the issues, and the value they will get out of a change. Try to frame it in a way that’s based on what they are trying to accomplish and the impediments in the way of getting to where they want to be.
I was talking to a coach today and he said to approach it from a place of inquiry versus advocacy. Instead of coming in and saying they’re wrong or they need to implement this new process. Come from a place of curiosity and questions to try and help them understand. See if those leaders can come to the same conclusion on their own.
Register for our next webinar, What’s new with Path to Agility 2.3?
