StartseiteHome » Blog » Succeeding with Agile

Succeeding with Agile

Project management interview with Bob Schatz, CEO Agile Infusion

Bob Schatz is a 30-year veteran in the field of enterprise software and systems development. He has held several leadership positions working for large organizations like GE/Lockheed-Martin and Liquent. Currently, Bob is the Owner of Agile Infusion, a training/consulting practice that helps large enterprises successfully adopt agile development practices. As a sponsor of the Project Zone Congress Can Do presents the interview with Bob Schatz, which the host of the event has conducted.

Project Zone Congress (PZC): You championed the adoption of Scrum and traditional project management software. Tell us about the Scrum adoption in terms of: Why and how have you realized that you need a new approach? What were the typical pains you encountered? What surprises you experienced along the way of the adoption?
Bob Schatz: Yes. Well, this story was really interesting and I think it is one of the reasons that people really started taking the agile practices seriously in enterprises software, particularly because we were faced with that situation. I went in the software company in 2001 as the VP of development. I started to realize very early, and I really had a conversation with the CEO when I was interviewing for the position and he told me that one of their weaknesses was actually managing projects. I thought that was really funny because it is a company that, as you said, sells project management software. It is a very large scale system that is typically used by construction and engineering firms around the world, and it was starting to be adopted more and more by IT organizations and knowledge-work type of environments to do projects; but internally inside the company their biggest weakness was actually managing those projects.
The other interesting thing about the way that all started was: I was not a big fan of project management software. So when I started there I thought it was interesting because they could not manage projects, but I had 20-years of experience of managing projects and I was pretty good at it, and this company had software to manage it and I did not like the software; so I thought that would be a good start to solve the problem.

PZC: That is something you shared with your CEO, did you not?
Bob Schatz: Yes, I did. When I went in there I spent about a year and had over 130 people working for me. I started to understand over the first year as I tried to implement practices that I had known to use, that we were still having a lot of problems. After about a year, the thing that really got us to stop and really take a different approach was the fact that people were working tremendous amounts of overtime – unpaid, and were starting to get physically ill. People were getting sick from doing work and they were having problems with family and all kinds of social issues –all because of the stress of the job. And even when we were working really hard and people were putting everything they had into it, the results that we put out were terrible. We had a product and people really did not want the features we were putting in, there were a lot of defects that we were putting out there and customers were paying a lot of money for this.
At that point, after about a year, I decided “Stop working overtime to produce something that nobody wants and you’re not proud of. That is not worth your time so we are going to stop that” and then I said “we have to find a different process because what we are doing – we have proven does not work. We are putting all this effort into something that nobody wants. That is not a good idea”.
So I did not know what we were going to do, but I went back home and I started thinking. I had been involved in a startup, and it was very successful and we used the techniques that these agile practices were trying to talk about at that time. So I started thinking through it. I read some things about Scrum and I really felt like it was something that was very similar to a startup. It was very user-focused and very focused on developing the right thing and doing it quickly and I thought it really matched something that we could do, and so we decided to try it out.
The experience that we went through was very difficult. Originally we thought ‘if we do this, everything is going to be fine’, but we found out very early that it was very painful; it was starting to show us things that I think a lot of us did not want to see. There were product problems, there were process issues, there were people issues; we did not have all the right people in the right places and that started to show us. So in the beginning it was very frustrating and very difficult to do. We all got together and decided ‘Let ́s just try to get through it and see if we can fix some of these issues’. We started working towards that and getting better and better and better, and after about six to eight months we just got into the habit of fixing problems a lot. I guess the result at the end of it was that we started getting our customers engaged. They were much happier. They started seeing that product quality came up so we started to implement this idea of a definition of “done”, which was kind of new at the time. No one had really thought about that.
We got our teams working together, we got our Scrum masters trained, and we actually started coaching them to be better leaders. So the organization itself started getting a lot better. People were not working overtime and they have put out more functionality than they ever did before. So, from the people perspective it became a really big benefit, they got their lives back and in doing that we were able to produce more functionality.
The customers were engaged, so we were actually doing the things that they wanted and we started getting a really good sense of quality. Everybody took responsibility for the quality of everything, from the product, and our process, and how we all learned ourselves.

PZC: So you say it took around six to eight months to actually see the results?
Bob Schatz: I think what was going on is we actually saw results early on, it is just a matter of what you call results. To us, I think after six to eight months we were starting to feel comfortable with it where we knew, ‘Ok, we are going to keep doing this.’ It is sort of like we kind of settled down after that. The early sprints, while they were not tremendously successful, did prove that we could start to actually develop things in short periods of time – which nobody was used to. I think when I told them we were going to be doing features every four weeks, people were initially sort of shocked by that. We had to learn how to do that. We started to settle down where we knew it was possible, we had proven over a series of sprints that ‘we can do this’.

PZC: Tell me about the top management commitment. You came with a totally new approach; obviously your company experienced a lot of pain… Seems you’ve been in a relatively easy position to convince them that the change was necessary. But how was top management in regards to the supporting the change?
Bob Schatz: Well there were two things. There was the driving of the change from my level. I was the VP so I had this whole organization and from my perspective what I had to do was: I did not want to force it on people. I wanted people to understand that we were in a very bad spot, that things were not going well. I said “Well, we have used this process, you’re all used to it, it is not working anymore and it is just going to get worse so we are going to have to try something different”, and then I actually put them into a vision exercise where I had them create a vision for themselves in terms of where they wanted to go. Then I started saying “All right. Is Scrum one of the things that can really help us?” so it was really a very value driven team. It was: Set a vision. Set a set of values. Now let’s start working towards those values. And help them understand that the pain of change – while it will be painful – is less than the pain of the continuing to do things the old way. Once we understood that, I think people were moving.

Now, there is also the level of change from above me. I was the Vice President of Development but I also had to deal with the CEO and the COO who were both the founders of the company and very tied into project management, both of them, and never understanding why the software group could not manage projects using our own tool. In the first couple sprints, the first two months that I did this, I did not let them know we were doing anything called Scrum. I did not want the CEO to think that we were not using project management techniques to develop a project management system. What I did is I had them come to sprint reviews –the first two sprint reviews. We had the executives come too. I did not tell them it was a sprint review, I did not start explaining the process, I just said “oh, we are going to be demonstrating some of the things we have worked on over the past four weeks”. They came to the sprint review and started talking to the teams and seeing what they were doing and they were shocked. By the third sprint the CEO told me “I don’t know what you are doing here, but it is amazing. I have never seen anything like this. The only thing I am worried about is, are we doing project management?” and I said “Yes we are. It doesn’t look like what you typically think project management is, but we are managing the project, more than we ever have before, and you can obviously see the results”. I said “It is this thing called Scrum”. And then he got intrigued and must have read a little bit about it. I think he started to understand that it was just a different way of managing a project; there is still project management.
So from a leadership perspective, I tell all my clients and anybody that is trying this that you really need to have leadership support, because eventually team members will run into problems and some of them are way above what they can handle, and it is management’s job to really make sure that they have an environment to work in that can produce valuable customs, and that is what they had to focus on. So it really does require that level of support. I never tell people to sell the process; you want to sell the results. You want to keep it quiet, produce some results, then have people ask you, ‘How did you get those results?’ and then talk about the process.

PZC: You had 120 engineers under your responsibility. Did you start with a full blown introduction, where the whole team goes Scrum, or are you started a small team first, ‘let’s see how it goes’? Especially, Scrum at that time was fairly new…
Bob Schatz: Originally, when we started talking about it the first thought was to just run a pilot team and see how it worked. So we started talking about that and we had about a week-long discussion off and on about what we were going to do. I started to understand that we could do that, but the thing was we were in so much pain from the old way, that I said, “You know what? Let’s just do this all out. Because if we do a pilot we will try to learn for a few months and we will have a small team doing it, and everybody else is going to be in pain. So it doesn’t really make sense. We already know that what we are doing is bad, so how can something else be worse? You can’t get any worse – we are at the worst place we could possibly be. There is only going up from here. Even if it has just a minimal effect, it is better than what we are doing”. So I made the decision, “Let’s go full out and do this with everybody. Let’s just form teams, get everybody together, get this thing moving and see what happens”, because doing it piecemeal in that situation was not good. Now, with my clients, unless they are in that same spot where it is very painful what they are doing; and that is very rare that they realize that –I mean, it may be the case, but they don’t realize it. I usually tell them to start pilot projects first to understand what the theme looks like. But I have had companies I have worked with that are at that level of pain, and I just told them, “Just go full out. Don’t even look back, just move forward”.

PZC: Certainly introducing agile requires action, requires determination, a superb change process. Can you just elaborate on what – in your view should be a typical road map in agile induction to overcome resistance to make sure that the agile in fact can be introduced throughout the organization?

Bob Schatz: I think the biggest thing that you start off with is: You have to understand that there is a reason to do it. I think it is very important to start with an understanding of why you need the change and what the consequences of not changing are. Once you establish that, then it is a matter of change and start in a single project and run it like a pilot; you can start with a project area or product area or you can go full out. I think the initial discussion is: How do you want to roll this out? Then, some of the initial setup of just getting things in place, getting people focused on how to work as a team and understanding that it is about team, it is not about individuals, and that the focus has to be on the customer and value to the customer. So I think there is a little bit of education that has to happen there. Then you have got to get moving. I mean, the biggest thing is just start moving. After you get those things established do not think about it, just start moving, because you’re not going to learn until you start doing.

When you start doing these things, everything starts popping out, so you have to be ready to adjust. In a sense, we have to use the same agile practice to implement it as we do to run a project. So, you have to set it up and start doing something, learning from that, taking bits of feedback, adjusting, and just keep doing that over and over again. That is really what helps. But you want to have that support structure in place. A lot of times, in the big organizations I will actually form the executive team as the Scrum team and their project is implementing Scrum in their organization. So they have to learn how to use it well and realize that it is not just for development people, it is really something that affects the entire company. That is important.