When Scrum is not enough! A Case Study by Ruchika Goyal


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Building a travel web site for a dutch client. Already had a site but they wantesd a completely new and redesigned site Required a lot of data to be filtered and displayed real time It was a huge development effort
  • We had a very big team. 6 devs working on the client side 9 workin full time on the Indian side Working in a distributed way
  • Using Scrum as a tool to implement Agile way of working Quite experienced in scrum Had quite a lot of challanges in implementing distributed scrum teams but experimented quite a lot. All Demos were successful and we were meeting spring goals Client was happy Till now we were in the development phase of the project and there was always plenty of work to do It was running like a well oil machinery
  • Gradually the well oiled machinery was starting to give us problems As the following problems started to surface.
  • We continued to stick with scrum but it was beginning to get frustrating. On retrospect, our requirements were changing. From developing new features, we were moving towards providing efficient bug resolving .We had 2 options Either continue to use the samtuiree machine and break it eventtualryly Or try something which could help us do it better.
  • Our Project Manager had heard about Kanban and we also had some very vague idea of it. So we explored a little bit more and this is what we came to know Kanban is an Agile tool, which is a pull system just like scrum It allows the continuous flow of work from one end of the board to the other It optimize the process to make lead time as small and predictable as possible. The biggest difference between scrum and Kanban was the lack of iterations Explain Kanban flow: How it is a pull system Explain a bit of history Seemed like a very good option for maintainance projects or HR/Operations or Sales teams
  • Kanban predicates having WIP and physical board. It took us some time to understand the importance of WIP. Explain what is WIP The flow was working and we were moving work from development to testing. Now the last Done column required to deploy on the test server. But it was down. So we were not able to deploy and we didn't realize till after a long time. So to make it possible to highlight the bottlenecks it is important to have WIP limit. And how much is that you can see by experimenting. If too low , then there is a loss in productivity. Too high and it will take longer to identify bottlenecks Scrum took care of WIP indirectly Adding WIP also helped us to priortize our work flow.
  • Kanban says to have a have physical board as well
  • Since we were agile and scrum was sort of in our blood , we decided that we will now proceed in small steps and do inspect and adapt.
  • Kanban as such does not constraint you to have retrospectives but it is also very adaptable. So any system can only be improved if you have a continuous feedback cycle. Too short feedback cycle – u'r process may not get time to mature Too Long feedback – U'r process may not improve fast enough Find a balance: We did 2 week regular retrospect 4 week process retrospect How it helped: We were able to ensure the same flow of communication as it was before PR : we added a lot more columns to make the flow smoother and adjusted the WIP limit
  • In Scrum, we break a huge story in to smaller sub stories so that based on the velocity of the team, we could pick up the stories There was a business analysis team who was looking as some mmf which our site must have before it can be finally out there They created a US and it a huge one. Most of the stories that we had so far were pretty small. This new mmf required us to
  • When Scrum is not enough! A Case Study by Ruchika Goyal

    1. 1. When Scrum is not enough ! Ruchika Goyal
    2. 2. What
    3. 3. Team Structure
    4. 4. What process
    5. 5. <ul><li>Empty product backlog </li></ul><ul><li>No stories to plan </li></ul><ul><li>Introduction of stories/issues in mid sprint </li></ul><ul><li>No clear sprint goals </li></ul><ul><li>Nothing concrete to demo </li></ul>What Changed
    6. 6. Why Scrum failed us here <ul><li>Scrum predicates: </li></ul><ul><li>Time boxed iterations </li></ul><ul><li>Ditching sprint if new work is added in the middle </li></ul><ul><li>Sprint review </li></ul><ul><li>Commitment </li></ul>
    7. 7. Kanban
    8. 8. Work in Progress
    9. 9. Initial Kanban Board
    10. 10. One step at a time
    11. 11. Retrospective
    12. 12. Planning
    13. 13. Definition of Done
    14. 14. Final Kanban Board
    15. 15. My thoughts