Scrumban recipe

Editor's Notes

• #2: Hi Good Afternoon everyone I am Vinaya and this is Sutap – we are both agile coaches from a large enterprise. And we are here to share our own flavor of ScrumBan which we have started implementing in Delivery unit recently
• #3: A bit about the journey towards being more agile Taking you back a few years to 2007, we implemented CCPM based on TOC – which helped us understand the need for maintaining a low WIP – less multitasking, to move away from fixed schedule plans, create more focus on critical items. Then in 2012 our Delivery unit was undergoing some transformation – as a part of this we did something called IDDP – Integration Driven Development Practices – which helped us focus on identifying integration issues early on - by at least viewing complex flows integratively and working on them integratively in iTeams, doing some early integration tests etc. And the stage was set for us to look at more industry wide accepted practices like Kanban and Scrum.
• #4: And in 2013 we chose Kanban. Why did we choose Kanban? Primarily for its change management approach. We have a lot of veterans who are good at what they do, who have been delivering in the past. So we wanted to not bring in a big bang overnight change – we wanted something evolutionary. And Kanban allowed us to retain roles, titles, processes and to gradually change and grow into something that worked for us. It allowed each acct to figure out what change and how much they wanted to pull. It allowed people to learn and grow.
• #5: So what is Kanban? We understand that many people in the audience are probably more familiar with Scrum than with Kanban. So - Kanban very briefly It’s a tool to visualize your work better, limit the WIP explicitly in order to implement a pull system and manage the flow better – focus on issue resolution, cycle time etc. And how was our journey ? Well, we started to visualize our work better It took us away from detailed long term plans towards smaller plans and more frequent planning It helped us clearly see and focus on resolving bottlenecks It resulted in better flow – better work completion It helped us have a shared understanding of policies
• #6: So why not simply continue with Kanban – why did we start looking at Scrum? While the evolutionary, do-it-at-your-pace was good for us, we are talking about enterprise scale. We were seeing too many variations in Kanban impl, and these implementations were not improving / evolving beyond a point, stagnating at different levels At an Enterprise scale – we started feeling the need for some alignment When People moved from project to project – they were getting confused by variations, not able to share best practices and knowledge, every acct is unique So we were looking for a framework and the discipline / predictability /prescription that a framework brings with it __________________________________________________________ Also we didn’t experience the predictability of cycle time – we expected the variations to settle down with time but it didn’t happen Also since there is no timeboxing in Kanban, People were having to think in terms of very long durations – and this meant we still had peaks and valleys and work piling up towards the end So in addition to the framework of Scrum, the time boxes were making sense in our context – for predictability and discipline __________________________________________________________ Next - The emphasis on self – org, self management in Scrum was attractive We were anyway experimenting with it in different ways – through Dev Team Units, iteams etc. So decided to learn from the industry We also needed a team-centric solution to help combat integration and collaboration issues. For many years now our GL/PM layer has been the bottleneck – the layer is knowledgeable and also the day-to day decision making layer. So decentralizing decision making, self-organizing teams would go a long way in helping us overcome one of our top constraints So the team focus of Scrum was one more idea we planned to borrow __________________________________________________________ And with Kanban, we were now ready to take the plunge into something more structured like scrum
• #7: Like we saw on the previous slide, we liked the timeboxing and team-focus in Scrum We also liked the PO role – Why? Our implementation focus was always on the construct phase with a lot of problems upstream – in how we gathered and viewed requirements. With the PO role this got special dedicated focus and business value came to the forefront. Also moved the complexity of this phase away from the construct teams. __________________________________________________________ We were already enjoying the benefits of visualization from Kanban and we wanted to continue doing that While the timeboxing in Scrum helped us implicitly control WIP – we wanted to see a flow of stories within each iteration – which meant keeping an eye on WIP within each iteration, managing the flow by focusing on completion and issue resolution. So we continued to use WIP limits and continued to give importance to the flow of stories within an iteration. __________________________________________________________ Mapping the workflow before and after construct period is not mandated in scrum – scrum is silent about it. But this was something we were already doing in Kanban – a Kanban board to some extent represents the workflow and building this workflow together (including for before and after construct periods) was always a very valuable exercise – so we kept that. __________________________________________________________ Capturing the explicit policies for each station in the workflow – or each stage is a part of Kanban and we continued to use the policies to have a shared understanding of when work is ready to be pulled to the next stage __________________________________________________________ So to summarize – from Scrum we primarily adopted timeboxing, the self-organizing team concept, PO role And we retained from Kanban – the visualization, the focus on low WIP, flow of work, workflow mapping and explicit policies __________________________________________________________
• #8: SO what does Scrumban look like in our projects ? We are starting to see some discipline around the iterations We are not there yet for sure but we are getting to a stage where most of the work starts and ends within the iteration boundaries Self organizing teams – we have a long way to go there but we are already seeing a much more participatory style of leadership than we did earlier. People are being consulted and then decisions being taken. Some teams have moved on to a stage where people are presenting decisions and trying to get consensus around it. Product ownership focus – Product owners are understanding the role better – they are trying to talk more business than technical, they are coming better prepared for plannings and are getting a demo for every story. But our PO-to-business chain is a long one and that means that the TAT is not great and also the PO is not really as close to business as we would like him/her to be. Also our Pos are former technical experts so they are still experts in that domain rather than in cross functional
• #9: Visualization – we are continuing to use Kanban boards and the visualization is good There are some types of work we continue to struggle to visualize in kanban and that is a challenge we are yet to overcome Flow – one of the problems we hear of with many scrum implementations is that it is a mini waterfall within the iteration. Now many places we do not see this – we actually see a continuous flow of stories within the iterations and story demos happening throughout But in other places we actually see people degrading to the mini waterfall behavior – which takes us one step back from where we were So we are investing a lot on coaching the teams to not lose this practice of continuous flow. Workflow mapping continues to be good – especially for how the work will flow into the iteration The UAT and Deploy phases are often managed by onsite teams and they are not yet completely onboard for mapping out the workflow in Kanban Capturing explicit policies continues – this is complemented by the “definition of done” discussions – they are practically the same We would like teams to review the policies more frequently and also do some internal checks to ensure they stick to the policies better
• #10: So I guess the core message of our talk is really that the practices, the framework etc help but they are secondary to the principles. So we don’t want to be dogmatic about the practices but we do want to stay focused on the principles. We are beginning to see benefits and challenges and are learning and tweaking our approach along the way.