Kanban @ PARSHIP – the story of how we introduced a change method to our teams 1 Start where you are It all started with what become notorious as the "mandatory sprint" at PARSHIP’s product development department. The cross-functional teams at PARSHIP1 had used scrum for three and a half years and were really good at adopting its mechanics. But then a few things changed: three 3-week sprints in a row were busted because of ever-changing requirements. Instead of waiting until the beginning of the next sprint, Product Owners (PO) were forced by business needs (read: CxOs and market requirements) to replace and change User Stories (US) already committed by the team frequently. Of course scrum has means of handling things like this. Do a "spike", swap US for others with the same estimated size, shorten the sprint length. One example of the problems we had with scrum and the changing business behavior: team A needed to stop working on a user story and instead start working on a different story that team B had already estimated to be approx. the same size. But as all teams had their own differing baseline the team A had to do their own estimation. So the estimation team B created was a waste of time as their estimation was no longer necessary or useful. We can discuss standardization and the sense or nonsense of doing this for knowledge workers. But this would be another story and I prefer to continue with this case study. As the commitments of the past three sprints for these four teams were changed, swapped, not met and frustration was running high we created a lot of formal scrum-process-overhead and would continue to do so even if we shortened sprint duration. Now "business people" (read CxOs) came and said: hey guys, we have this fabulous idea. When having completed this, everything will turn out right and we will start the "afterburner" for our business. So this is how our mandatory sprint started. It was called "mandatory" already at that time because everything inside this sprint had to be done - it was mandatory. The team committed to the stories but refused to commit to the usual sprint-time. So even the word "sprint" didn't fit anymore as it wasn't a timebox either. At the end it felt like working on a "death march project". So what happened? Due to high morale and the professionalism of the development-team, we finished the "mandatory sprint" after six weeks non-stop working, including some weekends and holidays. 1 At that time the PARSHIP product development team looked like this: We had four cross-functional teams consisting of 4-6 people with the following skill sets: java-dev, frontend-dev (html, css, and js) and qa. Each team worked as a rather autonomous domain team. Therefore each team was responsible for its own way of estimating and each team had their own baseline. Furthermore we had two scrum-masters who by that time were already "Delivery Managers", as they did so much more than simply making sure the team sticked to the scrum-rules and taking care of impediments. Each Delivery Manager took care of two teams and each team had at least one PO for getting input. We have a separate operations-team taking care of the PARSHIP live-operations. Therefore we still have a formal handover process for the upcoming release. Kanban @ PARSHIP, Marco Melas, v.05 1 / 10 The features were a success but more features and new stuff was in the pipeline. With this background information you as a reader certainly have different ideas what could have gone better, where we possibly made mistakes etc. Most of our ideas involved convincing “upstream parties” of change. On the other hand we could simply accept things as they were and change ourselves. We can look for a way how "we" can cope with the new reality. After all the “perception of reality” may be different for different people but reality still stays the same. Our reality was that business needs changed frequently and that this didn't fit with our current development-process. It made everyone involved unhappy. Given this situation (we) the whole team decided that it was about time to change how we handle our development process. This is our starting point. (“Start where you are.”) A couple of months earlier we introduced the kanban-method (I’ll simply write “Kanban” from here on) to the operations-team and feedback to this change-method was really good. This IT-Ops-team at PARSHIP is responsible for internal administration and live-operations. One of my bigger learning before introducing new stuff was: fear of change can kill any initiative no matter how sensible or good it may be. At least due to good preparation and stakeholder-management we were able to make Kanban a success within the operations-team. But this was a small team, consisting of five people. Smaller groups are easier to understand and it is much simpler (but never easy!) to "dig into" personal fears. So how can we adapt this for 25 people? 2 Preparations and Introduction We Delivery Managers sat down and created a one-day workshop based on the principles of David J. Anderson book “Kanban: Successful Evolutionary Change for Your Technology Business”. We wanted to address the following: The expectation from business on how we handle development has changed. It doesn't fit anymore to our expectation. We can't continue as we always did, so what can we change in order that business needs and development capability stay in synch? Before I move on to explaining how we built our workshop let me describe how we addressed this fear of change. 2.1 Management buy-in As soon as we had our first rough version of the workshop and the big goal as described above I presented it to the management team: "Listen guys, I know that you know that this mandatory sprint thing didn't work out that well. We developed an idea how to make things better. I would like to share this with you and get feedback." And we got feedback. People understood that we were addressing a pain they felt but were not able to articulate. They were happy about our approach and backed us up all the way. We integrated their feedback into our workshop. And then we went for round number two. 2.2 Product Owner buy-in Because the introduction of Kanban has some impact on how POs needed to handle prioritization we decided to do a second round with the improved workshop with them. Besides, the POs were in the middle of heat: they gather business requirements and analyze benefit and risk. They are responsible for deciding the roadmap. (Coaching for “minimal viable product” (MVP), “minimal marketable feature” (MMF), “cost of delay” (CoD) etc. was not our intention, as we wanted to take one step after the other and saw the highest Kanban @ PARSHIP, Marco Melas, v.05 2 / 10 risk in continuing with plain scrum). The intention was to show the POs their new responsibility and possibilities and a check if our workshop-modifications worked out well enough. We received valuable feedback from their perspective, too and integrated this into our workshop afterwards. With the POs the emphasis lay on keeping existing roles and titles and responsibilities. (“Respect the current process, roles, responsibilities & titles.”) Steps 1. and 2. were a two hour session and not the full-blown workshop. You will understand why, when I explain the workshop. In the meantime the Delivery Managers talked to the "opinion leaders" inside the teams. We explained that we are working on something that will help us getting better but it will not be the solution to all our current problems. Further we explained that we understand the pain of the past sprints and wanted to help to prevent frustrating experiences like that in the future by introducing Kanban. They understood and were happy to support our effort in the upcoming Kanban workshop. 2.3 Team buy-in The moment of truth had come. We invited the whole team for a day-long workshop in order to address the pain-points of the past sprints. As good scrum-people do, the teams already had their retrospective and had identified their pain-points. Since it was already clear, that we will have this workshop, we asked the teams not to come up with just team-internal-solutions during their retrospective but instead bring their ideas to the workshop where the whole team was present. 3 The workshop As the word "Kanban" was in everybody’s mind (the preps for the workshop weren't “secret” and I encouraged the DMs to talk e.g. during lunch about some aspects already) we started the workshop with some theory: what is Kanban, where does it come from and why are we talking about it. So this part we internally called "expectation management". With this entire Scrum vs. Kanban things you hear and read about we explained that there is no real "vs." as you are comparing apples to oranges. Secondly we collected a list of things that didn't run as smooth/good/clear/painless as desired. This was the aforementioned link to the retrospectives. We made clear that Kanban cannot solve every problem we have on that list. Legacy code will not disappear if we "do Kanban". Pushy POs will not become super friendly with Kanban, etc. BUT Kanban will give the team a whole new level of transparency and with this a whole new level of control.