• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
When Scrum is not enough! A Case Study by Ruchika Goyal
 

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

on

  • 1,741 views

 

Statistics

Views

Total Views
1,741
Views on SlideShare
1,741
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 When Scrum is not enough! A Case Study by Ruchika Goyal Presentation Transcript

  • When Scrum is not enough ! Ruchika Goyal
  • What
  • Team Structure
  • What process
    • Empty product backlog
    • No stories to plan
    • Introduction of stories/issues in mid sprint
    • No clear sprint goals
    • Nothing concrete to demo
    What Changed
  • Why Scrum failed us here
    • Scrum predicates:
    • Time boxed iterations
    • Ditching sprint if new work is added in the middle
    • Sprint review
    • Commitment
  • Kanban
  • Work in Progress
  • Initial Kanban Board
  • One step at a time
  • Retrospective
  • Planning
  • Definition of Done
  • Final Kanban Board
  • My thoughts
  •