At Lean Kanban Central Europe Alexander Gerber and Martin Engel talked about their experiences with more than two years of applying Kanban at SAP. They showed how they supported the development department of a large software company with the implementation of lean and agile processes. This is one of the case studies on lean and kanban from Central Europe on which InfoQ reported earlier this year.
InfoQ did an interview with Alexander and Martin about how Kanban was introduced and received within SAP, their training approach and the experiences from teams with the Kanban practices.
InfoQ: In an earlier presentation from LKCE 2011 about software Kanban you talked about how you started the Kanban initiative at SAP. You quoted David Anderson: "The essence of starting with Kanban is to change as little as possible". Many larger organizations are used to doing big change programs. How was the Kanban approach received within SAP?
Alexander & Martin: While we do not have a big change program for introducing Kanban at SAP, we did have our "Big Bang" well before that: Our introduction of Lean Thinking and Agile development methods, including Scrum, already started in 2008. This was an important basis for our Kanban introduction --- which we started some 3 years later, around 2011.
In line with the principles "start with what you do now, change as little as possible initially, and commit to evolutionary, incremental changes" we did no full-scale roll-out, proposing Kanban to all teams in our development organization, but rather offered Kanban as an alternative approach for certain types of teams --- teams concentrating on maintenance or operations, for example. For most of the teams in our organization, concentrating on development, we continue to propose Scrum as the standard process framework.
Generally speaking, our Kanban offering has been received warmly by the target audience. We have trained some 50 teams already, and we see a continuing influx of new requests asking for Kanban training. By the way, our "Lean and Agile Core Team" has not been the only path of Kanban into SAP: in our big ecosystem there are quite a number of teams who have found their way to Kanban by themselves and learned about Kanban from other sources, e.g. conferences. One success factor, though, has been the regular experience exchange on Kanban that we are organizing for all at SAP who are taking an interest in Kanban.
InfoQ: You used Kanban to start improving from where you are. Teams in larger organizations can differ in the practices that they use, and often there are differences in experience levels, culture, etc. How did your Kanban program deal with this?
Alexander & Martin: That touches on an important aspect of our training approach: On the one hand, we are providing information on Kanban as it has been standardized by David Anderson; so here we are training "Kanban by the books", using the same principles and practices for everybody. On the other hand, the three-tier architecture of our Kanban training offering, and in particular our “Kanban Workshops”, leave enough space for the special needs and interests of each team we are working with. So we are not imposing the same “one-size-fits-all” solution to all teams. We explain that in some more detail below when discussing details of our Kanban training offering.
As a result, we are strongly proposing some essentials to the teams, like conducting Retrospectives regularly, meeting (more or less) daily for short syncs, having a facilitator on board, and so on. But we are also quite liberal regarding the details how these things are implemented. For example, most teams will start their Kanban transition with the role of a Scrum Master, which then gradually evolves into the role of a Kanban facilitator; how that evolution is done in detail is up to the team, and frequently even the original role designations (like Scrum Master) remain the same. Similarly, board representation of the workflow, process policies and so on typically are very team-specific.
In this way, we are trying to reflect the levels of experience, and the different cultures and practices that have developed in our big development organization.
InfoQ: The goal of the change team was to realize a "stable and lasting implementation of lean and agile methods". Have you met your goal? What did you do to meet it?
Alexander & Martin: One way of thinking about this question could be: "What would the developers in our teams say?" Thinking back some five years, when we started introducing Lean Thinking and Scrum, there were quite a number of concerns brought forward by the team members, and it took some effort on the side of our Lean and Agile Core Team (and other teams) to answer questions, and to deal with these concerns. What we had to struggle for a lot in earlier times can now largely be taken for granted: In many parts of our development organization, people share a common language, and they have a set of common values, as far as Lean and Agile are concerned. For example, nowadays most people will agree that it is highly desirable for a team to have prioritized and estimated product backlog as the basis of their work. This is something that won't be lost short-term or even mid-term, so this can be seen as an indicator for sustained change indeed. After more than five years into the Lean transformation at SAP, Lean/Agile ideas and methodologies, including Kanban, appear to be firmly anchored within the development teams, and more importantly, in the minds of the people: They have become "part of our DNA". There is even an increasing pull for Kanban from non-development teams, such as teams dealing with product support, for example.
How did we achieve that? One factor certainly was that we "practiced what we preached". So we did not only advocate Scrum and Continuous Improvement, but we employed these in our own team, too. And we did the same with respect to Kanban, of course.
Another important success factor was that we worked with both the management and the team members at the same time. This combination of top-down and bottom-up approaches surely helped us on the way, on the one side with collecting experiences and establishing feedback loops into what we taught in trainings, and on the other side with getting the strong management support that you also need in an organization as big as ours.
InfoQ: Can you explain how you used retrospectives to improve your Kanban board?
Alexander & Martin: We normally used an approach based on the suggestions from Derby/Larsen in their book on „Agile Retrospectives“. Normally we would do a retrospective every 2 weeks, but we were not totally strict about this, so sometimes it was cancelled or spent outdoors enjoying an ice cream. Our goal in the retrospectives was always to identify small areas of improvement and to define clear action items and decisions. Sometimes we especially prepared our retrospective meetings (e.g. by providing specific data from our Kanban run chart), sometimes we just collected in a “mad, sad, glad” fashion what was on everybody’s mind. We’d then cluster and prioritize items. Sometimes, countermeasures were easily found, sometimes we also used techniques like “Five Why”. But we also used retrospective meetings every now and then as open discussion rounds (not more than 60 minutes), where everybody could raise concerns, without coming to follow-up tasks. For the “team mood”, these rather unstructured meetings also proved very beneficial.
InfoQ: How did you approach Kanban training? Why did you do it in that way?
Alexander & Martin: We launched the Kanban training as an offer to teams that looked for an alternative to pure Scrum (for instance, teams with a high maintenance load, administrative or other non-development teams). So we did not – as we did for Scrum trainings – launch a structured rollout with detailed training plan and everything. We relied on word-of-mouth spread for one thing, for another the Kanban training is accessible via our standard trainings channels. So this is how colleagues learn about our Kanban trainings.
The training itself is threefold: as a starting point, we offer a 2-hours info session (as we call it) where we deal with the basic Kanban topics like Kanban history (where does it come from, who was the “inventor”), the basic practices as well as the principles for introducing Kanban. We use an interactive training format, which is based on what Sharon Bowman writes in her book on “Training from the back of the room”. The goal of the info session is to give teams a basis for their decision of whether they want to start applying Kanban or not. If they want to go for it, we offer a full-day workshop, where we spend most of the time working on the specific artifacts for this particular team (how does their workflow look like, how can it be modeled with a Kanban board, how would an initial version of their tickets look like, which metrics to use, etc.). For this workshop, the goal is to support them towards a point where they are able to start applying Kanban right away after the workshop.
As a final thing, we offer some mentoring after the workshop, to help them overcome the first hurdles. This could mean joining their meetings, moderating retrospectives, acting as contacts for the teams’ facilitators and so forth. All in all, this “triage” seems to be useful, since it gives teams a low-investment approach to finding out whether Kanban would help them in their specific context or not.
InfoQ: At the end of your session you presented several proven practices. Which are these practices, and how did they help you?
Alexander & Martin: As already mentioned, retrospectives were one of the most important and helpful practices. In addition, we used a team charter for making our team’s rules, norms and agreements transparent and always visible (the charter was printed and put up to one wall of our team room). This helped in sticking to our agreements and decisions, although this somehow always seems to be a challenge (really doing what you decided…). Every now and then, we’d also spend some time in an offsite location for more in-depth workshops, for instance when we had to decide on the goals and strategy for the next half year. Once we combined this with what we called a “large scale retrospective”: this means we did not only look back to what has happened during the last two weeks, but what where the most important events, issues and highlights in the past year.
Another thing which we tried only recently (and repeated twice) was a practice recommended by management consultant Fredmund Malik which he calls “Systematic waste reduction” (“Systematische Müllabfuhr”, in German). The idea here is that for an organism to survive, getting rid of “waste” is extremely important. This also applies to teams and other organizational units. So we would look into all activities which we were pursuing and ask ourselves: which of these would we not starting doing again right now? So it’s not about discovering past mistakes, but critically judge what you currently do using your current knowledge. We did this once in the beginning of 2013 in a 3-hours meeting, as part of the planning process. This proved to be really challenging! It’s extremely hard to deliberately stop doing things, for many reasons. But then again, it’s the basis for every serious prioritization.
In addition to all this, we also applied some of the usual Kanban practices like tracking WIP with a Cumulative Flow Chart or lead time for our work-items with a run chart, to name just a few.