John Holmes: Part of it would be the similarities. In many cases we have small agile groups that are champions at a grass roots level. You might have one or two teams that do it very well. The organization starts to take notice. We start to go to agile at scale or larger scale level having multiple teams but they don't get the same support. They don't get the same training, they don't have the same champions, they don't have the same type of coaching that goes along with that. They fail to realize that in many cases these teams were doing, as I like to say, agile things, as they were maturing, before they started to show some of the great productivity that led to other teams being forced is some cases to adopt it.
Cameron: You talked about the ability to get coaching and whatnot. A lot of times companies will look for some certifications or seminars or something to get a better knowledge or understanding of Scrum. If a smaller company has limited resources, where should a company look to gain a greater knowledge and understanding of Scrum?
John Holmes: In my case, I started off, after doing Scrum and agile for three years, I finally went and got my certification. Then I was empowered by my organization, also the university that I worked for, to be part of the agile community, so I was the spokesperson who went out to gain the knowledge and then transfer that knowledge back to other teams.
We had internal coaching seminars; we had internal training seminars. Everything we did we could do in-house because the fact that in many cases the barrier to sending everybody to a training session, the cost of that was too great for a small organization. Even for a large organization, a lot of these certification courses are $1,400-$1,500 plus travel so what we did was basically create our own internal coaching and training resources so that we had a small finite group of people that could be called on at any time to go and help these teams.
Cameron: Sometimes with agile, people don't really like documentation as much because it slows the process down, but other people are huge advocates of documentation so that they learn from their steps and of course that leads you to the idea of learning from books and having a mentor, you think that will also help smaller companies with limited resources?
John Holmes: Yeah, I believe so. There seems to be this false notion that the documentation in agile is not as important. I found that to be the opposite. The fact that many times we do more documentation through the sharing of information of what works well for teams on the East coast and send that back to our teams on the West coast to keep very good logs of our retrospectives so that we can look at different types of trends and decide on the type of training or outside expertise such as what David provides, to come in and say, hey, sometimes we need a fresh set of eyes.
David told me years ago sometimes it’s hard to be a prophet in your own land, so we invoke and use outside resources to get a different view on it sometimes. Sometimes you have to take a step back.
Cameron: In your opinion, and David I'd like to hear from you too on this. Is it hard to start introducing agile or to stick with Agile practices once you've had them implemented?
David Nielson: I think those are fairly interconnected notions. In other words, from an implementation perspective, if you start out properly with the right framework and laying the right groundwork, the ideal situation is that if you are fully committed to any change, in this case agile and Scrum, your implementation methodology and approach should have as one of its core objectives, sustainability.
The return on investment for implementing any organizational change comes from the ability of the organization not only to implement it on time and within budget but to create it in a way that is sustainable. The challenge that we have in a lot of organizations is that the culture, while it's subtle, it's a very powerful force. Usually in many instances, it's a force against change, so whether you're looking at agile and Scrum, or Lean Six Sigma, or the integration of merged companies, culture eats change for breakfast.
The challenge that we have is how do we first of all, establish clear business case for what the change is? In this case, what're the really solid business cases, and John alluded to this, for why we want agile and Scrum to be a part of how we do business.
Secondly, we need to assess the organization to find out what are the barriers up front that we can identify and then manage, and all of that relates to then building the right culture so that if you are implementing agile and Scrum, you are implementing it into a culture that will sustain the change that you’ve invested in.
At the end of the day, this becomes a very financial equation, that is, that you are investing a lot to change the way people do things. The return on investment is that, a year later, two years later, those changes are still in place. People they may be evolving, but people are using skill sets they've learned and the organization is realizing the benefits.
Cameron: And David, this leads me to a follow-up question. You have more than three decades of managing organizational changes and leadership development and training. In those three decades, technology has come a really long way. There's no right or wrong answer to this question, but do you think that technology has helped or hindered the ability for organizational changes to not only be implemented but for them to stay in process.