Agile transformation, according to Jason Little, is about focusing on organization change and understanding the complexities that come with it. His video lesson “agile transformation” was covered in video lessons on agile coaching and organizational change and he talks about the differences between Agile Transformation and Agile Adoption. InfoQ interviewed Jason Little about approaches for organizational change, culture, feedback and learning, and using the lean startup approach.
InfoQ: Jason thanks that you want to do the interview with InfoQ. For those readers that do not know you, can you shortly introduce yourself?
Jason: I started out in IT doing break/fix, help desk and server support back in 1995 and got into software development in the late 90's.
From there I moved into development, then to project management and management roles before getting into Agile Coaching. I started using Agile practices in 2002, albeit I didn't know there was a label for that style of managing work and people. It seemed to make sense to me at the time so jumping into Agile wasn't really a big stretch for me.
Since 2007 I've been helping organizations adopt Agile practices as a Scrum Master, Internal and External Coach and Product Owner. Over the last couple of years I've been focusing on Organizational Development and Change Management in an Agile context.
InfoQ: I see a lot of talk about organizational change in the agile community. Why is change so important for adopting agile?
Jason: I'm happy to see more people talking about this. To me it's a sign of maturity and I hope the days of "doing vs being Agile" debates are largely behind us. Organizational development and change management people have known for decades what the Agile community is just starting to discover. All organizational changes are triggered by something whether that be a management change or a re-org or some earth-shattering epiphany by an executive. My stance is that Agile is a trigger for organizational change whereas I think too many people focus on Agile being a destination or future-state of an organization. If Agile is considered to be a trigger we can focus on managing the response to change and start using organizational development and change management tools in addition to what's coming from the Agile community.
InfoQ: The principles of agile do not look that difficult, but I often hear that enterprises are struggling with when they are adopting agile? What are the major change issues that they are dealing with?
Jason: In my opinion it's not understanding what change really is. Different people process change at different rates and intensities. I picked that up from Jerry Weinberg at PSL couple years ago. From my experience, there is usually a list of deliverables and a deadline for "installing agile" when Agile is brought into the enterprise. Change doesn't work that way and the most common pattern I see is labeling the same way of working with new Agile labels. For example, I've talked to people in organizations who've adopted Agile, Scrum in particular, and they describe how they do a 2 week requirements gathering sprint, followed by a 2 week development sprint and then a 2-week testing sprint. Sometimes using agile terms makes organizations feel good but they haven’t actually changed anything.
The Agile community has lots of cutesy names for that, none of them are particularly useful in helping organizations change the way they approach managing people and work. Enterprise organizations are completely different animals. Something as trivial as changing a status report can be a large undertaking. Values and principles have very little to do with that. Status reports are a fact of corporate life so trying to convince customers, stakeholders and executives they don't need status reports because "that's not agile" is ridiculous to me. It doesn't mean don't try to change them, it means understand the reality you're faced with and tune your approach accordingly. Some battles aren't worth fighting for.
InfoQ: A lot has been written about changing organizations before the agile movement started. I'm thinking of books from Kotter, Drucker, Senge and Covey, to name some. Is their work still valid and useful when you want to implement agile practices?
Jason: I mentioned earlier that OD and CM folks have known this stuff for decades and they have many more books, methods and tools to pick from. One of my favourite Covey books and method is the 4 Disciplines of Execution. That's what organizational agility is and they don't focus on 'Agile' at all. They focus on helping leaders make sure their employees are playing a game they can win by creating focus. The 4D's also mention the importance of finding the right leading indicators for success (which they say is extremely difficult…I agree.) and allowing the people doing the work to create their own measures of progress that feed into organizational level progress measurements.
The work of Kotter, Drucker and Senge are absolutely useful and I think there are other sources that are equally helpful like the work of Peter Lencioni (5 Dysfunctions of a Team, Getting Naked) and the Heath brothers (Made to Stick and Switch). I also rely on the work of Virginia Satir, Myers Briggs (and other Jung-based models like Discovery Insights) to help connect people in organizations and create an understanding of how people react to change. These change models help me help others understand that people are all affected differently by change and armed with that, people can be more willing to have more effective conversations and interactions. Right now I'm reading "Images of Organization" by Gareth Morgan (circa 1984) and am finding it tremendously valuable as far as understanding organizational design patterns and structures.
InfoQ: It looks sometimes as if the agile community is trying to re-invent change, and ignores what is there already. Do you see the same thing happening, and do we need to something about this?
Jason: I wouldn't say they're ignoring it so much as they don't know it exists or haven't figured out that the change management world has been doing great work for the last number of decades. That said, I think it's important to re-invent approaches to managing change. PDCA has been around for decades and pretty much any feedback loop tool/method whether it be Toyota Katas, Agile Retrospectives and even Lean Startup are re-inventions of that cycle. By that I mean they focus on feedback to drive change over following a linear process.
Each organization is unique and a custom approach to change is absolutely necessary in my opinion. Since 1995 Kotter, McKinsey and other organizations have done research about the success rates of change projects and the 5 studies I've read all show about a 30% success rate. We suck at change because it's really hard and un-predictable. The best we can do is figure out how to react to the reaction people have to change. That doesn't mean don't plan and don't use existing change tools or push when necessary, it simply means involve the people who are being asked to change in the change itself. You can't force people to change based on a project schedule. It takes time for people to integrate the change and piling on too many changes will keep an organization in chaos. Change is more art than science in my opinion and there is some great science out there to help make sense of what's going on.
The team I'm working with now is using Lean Change and adapting the work of Jeff Anderson to our needs. It involves applying concepts of Lean Startup with organizational change as well as change management and Agile practices. Our book is 1/2 of the way finished and it's on Lean Pub as we speak.
InfoQ: If an enterprise is just starting with agile, what kind of change strategy could they use to adopt agile?
Jason: I would strongly urge leaders to get out of their offices and go talk to front-line staff members "undercover boss" style because staff members know what is going on in the organization. Don't disguise yourself though! Forget change tools, surveys, consultants and other types of assessments, go talk to people and find out what the real problems are before coming up with a strategy. Now I'm making an assumption that the decision to "go agile" has already been made. Some would argue that will make managers nervous by bypassing middle management. Good, I say. There are well documented cases that middle management is the primary problem with bringing change in an Agile context.
I think organizations, especially enterprise organizations, decide to 'go agile' and start a change plan without taking input from the people doing the work or considering there are so many consequences outside of IT. Like I said, strategy and planning are important but not at the expense of excluding the people who are doing the work and likely the hardest hit by the change.
That said, I'm a fan of the ADKAR method. It can help organizations collect information from everyone in the organization about the change before implementing it. Done right, you'll be able to see where potential problems might arise.
InfoQ: Similar question, but now for an enterprise that has been using agile for several years but is not getting enough benefits out of it? What could be their change approach for agile?
Jason: That would depend on a great deal of factors but, from my experience, something needs to happen to trigger another change to re-start the adoption. That could be a re-org, establishing a new pilot program and applying the learnings from why it didn't work last time. There are no shortage of options. From my experience in larger organizations, a re-org or re-labeling job titles is supposed to kickstart a new change cycle.
Organizations that take a mechanistic approach to managing work and people would likely go the route of a re-org because the hierarchy and structure is how work gets done. Organizations that take an organic approach to organizational design will watch how the structure emerges and that's a scary concept for many people. Spotify and Valve are great examples of that.
The obvious answer to this question is figure out what didn't work last time and don't do the same thing again. Easy to say, hard to do. I'd argue that if a company isn't getting the benefits of Agile, there isn't a real sense of urgency to do anything differently. If your company is the 800 pound gorilla in the market or has a monopoly, what's the reason for doing anything differently? No urgency . . . real urgency . . . no change.
InfoQ: Culture is often mentioned as a barrier for agile adoption. Do we need to change culture, and what can we do to change it?
Jason: Absolutely not. Changing the culture isn't the point and trying to intentionally change the culture isn't likely to work. The culture debate always drives me nuts. No two organizations can adopt the same optimal culture to "be agile" as the Agile community likes to say. What I mean is, organizational culture is a collection of the behaviours of people and the interactions between them. Organizations, teams, departments, meetings, projects, social groups etc all have unique culture attributes and one culture isn't better than the other.
If you do want to change the culture, focus on creating an environment that encourages different behaviours. Maybe start off by trying to change the culture around meetings. Schedule meetings from 8 minutes past the hour until 5 minutes before the next hour so people can get out of their existing meeting and have time to decompress before jumping into the next one. Of course some will say that too many meetings is a sign of dysfunction, which I agree, with but instead of telling the people that, help them overcome it first by changing the "it's usual to be 10 minutes late" meeting culture. If that lowers stress, that’s a win in my books.
My point is, there are lots of small behaviour changes you can make that will aggregate over time. This is why I focus so much on change, pace of change and improving interactions between people. Change takes time, you can't force it.
InfoQ: Do you consider feedback and learning to be important in agile adoption? What can you do to stimulate this?
Jason: They're critical. Lately I've been experimenting with using Agile Retrospectives as a mechanism to introduce dynamic governance. That's the fancy way of saying I'm taking staff, management and executive level retrospective data and exploring the similarities and differences between what's working well and what's not working well across each of those perspectives.
My hypothesis is that instead of focusing so much on Agile, focus on the feedback coming from the organization and use Lean Change to execute changes. If organizations can learn how to fix problems effectively and efficiently with this method, it's going to be a lot easier to adopt Agile because you've learned how to change. If people are interested in the science behind this, check out cybernetics, double-loop learning and complexity science.
As far as learning, I am a strong supporter of socializing Agile within organizations. That means encouraging people to go to local meet ups and conferences and having after-hours sessions in the office. At the organization I'm at now, we're on our 4th study group and the people participating love them. One of my fellow coaches, Ardita Karaj, started 'Geek Talk' and we get a wide variety of people out to those sessions. Social events like this are important to get people excited about different ways of working. We’ve brought Scott Ambler in to talk about Disciplined Agile Delivery and Ellen Gottesdiener to talk about Agile Requirements. People in organizations love having the opportunity to pick the brains of thought leaders! From my perspective, people who give up an evening, lunch hour or come in a half-hour early to learn something are the innovators and early adopters I want to focus on.
InfoQ: There is a LiveLessons video training from you on agile transformation. What made you decide to do a video training?
Jason: I presented a session at Agile 2011 and Chris Guzikowski from Pearson Education approached me after the session and asked if I wanted to write a book based on the session material. He felt that the pragmatic approach I spoke about was unique and there wasn't much in the way of basic, pragmatic common sense approach to 'Agile adoption' material out there. At the time most of the material was either too dogmatic or too processy or too focused on “doing vs being Agile”.
I wrote a few chapters and then they contacted me later on to see if I wanted to convert it to a video lesson for Safari Books and InformIT. That's much more my style, for an introvert I like talking a lot…especially about a topic I love so much! More details about the video lessons can be found at the website of agile transformation.
InfoQ: In your training you tell a lot about change, and you also mention the lean startup approach. How does that help agile transformation?
Jason: There isn't much mainstream awareness about change. By 'change', I mean how people process change (Satir) and how neuroscience has shown how the brain responds to change. I am a huge fan of David Rock's SCARF model and have been obsessively studying it since Andrew Annett (a coach I'm working with now) introduced me to it about a year ago. Management 3.0 expands on that with the CHAMPFROGS model which borrows elements from SCARF.
I don't like the negative connotation of "resistance to change" because it's from the perspective of the person bringing the change, not the person being asked to change. It's like saying "Bill is resisting change because he won't do what I'm telling him to do". Bill simply might not understand the need for the change or he might think his way of doing work is better. We assume other people are bad because they won’t change yet when it comes to ourselves, we blame the environment.
People all react to change differently and our temperaments, skills and experience all play a factor in how we respond to change. Some people integrate changes faster than others. The laggards often get labelled as "resistors" which is un-fair and not helpful.
Using Lean Startup principles for organizational change has been very helpful for me and the team I'm working with now. It's essentially bringing in ideas from customer development to validate changes before implementing them. What's different is that we give people and teams options that they choose to accept or not. We validate a change makes sense for them and let them decide the cadence of implementation. We tie these changes into overall organizational objectives obviously, but the differentiator is the execution method. Many of the change management models (ADKAR, 7S etc) are great for collecting insights and planning change but not so much for execution.
Fundamentally understanding how people process change and using elements of lean startup, agile, change management and organizational development has helped the coaching team I'm working with now deal with complexity in an enterprise organization. You cannot control how people react to change, you can not plan your way through a massive organizational change like an Agile transformation but you can learn how the organization reacts to change and adjust your path as necessary. Mixing these elements with Lean Change helps with that.
InfoQ: If there is 1 thing that you can give the InfoQ readers, something that they can start doing immediately to help their enterprises to become more agile, what would it be? Why this?
Jason: Tough question! So many things come to mind! If I had to pick one, I'd have to say stop focusing solely on teams, processes and practices and values and principles and start focusing on upgrading the education and skills of middle management. In every organization I've worked in, middle management has hard the hardest time adjusting to Agile with project managers being a close second.
It's not because they're bad people it's because they don't know what to do or how to behave in an Agile organization. I read a recent study that said the average manager is a manager for 10 years before they get trained about how to be a manager! That's crazy but it does explain many of the behaviours I've seen over the years!
Managers need to have deep knowledge about Agile, collaboration and facilitation, communication and more to be effective. Management 3.0 is a great place to start.
I think if organizations could do one thing to become more Agile it would be to invest the time and money to develop managers with the skills and knowledge that Agile coaches have.
About the Interviewee
Jason Little is an Organizational Change Coach at Leanintuit, licensed Management 3.0 trainer, international speaker and author. Jason is passionate about the people-side of change and has been officially helping organizations adopt Agile practices since 2007. In his spare time he runs Lean Startup workshops with the Ivey School of Business and University of Waterloo. Jason founded the Silicon Halton Agile Community and started the local Toronto Stoos Chapter.