Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (18)
Destaque
Destaque (16)
Último
Último (20)
Kanban for sw projects v1.5 final
- 1. A Practioner’s View of PULL in Projects Govindarajan S
- 2. Not a Tutorial Experiences from the Ground Chronicles the Evolution
- 3. Our Worlds are Un Predictable !
- 4. From the 1994 levels an 100% Increase in Project Success Rate 34% Source: Standish Report on project success rate
- 5. “The primary reason is the projects have gotten a lot Smaller. Doing projects with Iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”
- 7. Iteration Time box is Restrictive ? Faster Turnaround Customer’s world is fluid
- 8. Regression Test Re-engineering of Platform Rapid Delivery
- 10. Legacy Code No Sound Eng Practices Rapid Response
- 11. Well defined Backlog Short Iterations Milestone Releases Learn Adapt & Respond
- 12. Team Stalls Lack of Stories Rapidly changing backlog
- 13. Routine Levers Didn’t Work No Control on Story Throttle Fluid Requirements landscape Inventories caused wastage
- 14. How Real was the Backlog ?
- 15. Flexible Process
- 16. Response
- 17. Build A Strategic Buffer
- 18. Limit In Process Stories Focus on doing End to End
- 19. WIP In Action
- 20. WIP Caused PULL
- 21. Realization of Constraints • What is the teams capacity ? Mindset on Fixed Backlog Streamlining of Analysis Work Visible Slack in the System
- 22. Questions Still Lingered …
- 23. Sudden Burst in Velocity
- 24. Consistency of Story Sizes
- 25. Response
- 26. Coarse Grained Estimation Small Medium Large
- 27. Throughput How many ? Vs How long ?
- 28. What do we Stand For ? What is the Value Adding Process ?
- 29. Response
- 30. What is in Control ? Requests from Planned for Users Development Elaborate Merge and Development Test Requirements Validate Deploy Set Of Activities that matters !
- 31. Evolve From Requirements To Development Done
- 32. From Requirements To Automation
- 33. Clarity to the Process Requests from Planned for Users Development Create Elaborate Development Test Automation Merge Requirements Suite Deploy Well Defined Value Chain Provides Clarity of Purpose
- 34. Call for Action 8 Cards In Process – How to Restore Limit ? 2 1 3 4 5 7 6
- 35. Call for Action Capacity Available for New Work
- 36. How does Pull Work – Scene 1 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 WIP Limit 10 Stage Limit: 1 Stage Limit: 1 Stage Limit: 2 Stage Limit: 1 Backlog Analysis Ready for In DEV DEV Done In QA QA Done Atmn Merged Deployed Identified DEV Done Backlog In Process Done • DEV completed triggers upstream pull • Signals Bas / Product Owners to line up the next high priority story for play Advantages • Commit late to the stories to play • Automatic signaling for the next activity
- 37. How does Pull Work – Scene WIP Limit 10 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 2 Stage Limit: 1 Stage Limit: 1 Stage Limit: 2 Stage Limit: 1 Backlog Analysis Ready for In DEV DEV Done In QA QA Done Atmn Merged Deployed Identified DEV Done Backlog In Process Done • Critical limit reached for Deployment • Can be taken into deployment at any point of time Advantages • Deployment cadence • On Demand or frequent deployment
- 38. How does Pull Work – Scene WIP Limit 10 3 Stage Limit: 2 Backlog Stage Limit: 2 Analysis Stage Limit: 2 Ready for Stage Limit: 2 In DEV Stage Limit: 2 DEV Done Stage Limit: 1 In QA Stage Limit: 1 QA Done Stage Limit: 2 Atmn Stage Limit: 1 Merged Deployed Identified DEV Done Backlog In Process Done • Limit reached. Bottleneck at Automation • Don’t pull in new Story • Instead automate and push the story out into Ready for Merge.
- 39. Response
- 40. Cycle Time Replaced Velocity
- 41. Metrics Measure Throughput Cycle Time Lead Time Wait Time
- 42. Just in Time assures Relevancy Inventory was reduced Pull Assures Throughput Value chain improvement resulted in Quality
- 43. Iteration ? Iteration was a checkpoint Flexible on Rituals Swarm to Retrospect
- 44. Team Obsessed with WIP Swarming to Remove Bottlenecks Awareness on Taking in Inventory Process change for Inclusive Delivery
- 45. Looking Back Learn Continuously Awareness of Team Throughput Affinity with the Wall to pick cues Take One Step at a Time Explicit Process Specifications Flexibility in the Rituals
- 46. Theory Of Constraints • Focus on throughput, rather than improving individual processes • Enables one to look at the process in terms of the weakest link • Manage the constraint to get a grip on the throughput • Enables you to have a good measure on the Capacity
- 47. “Kanban to promotes flow and reduced cycle-time by limiting WIP and pulling value through in a visible manner.” “Kanban helps our team contribute to the business by promoting flow and reducing cycle-time through a limited WIP and a fully transparent value pulling system.” “Value Pull, Limited WIP, and Visibility can create an ecosystem where teams have the opportunity to improve.” Source: www.limitedwipsociety.org
- 48. Finally…. • Start slowly • Focus on Your Value Chain • Accurately Measure Progress • Retrospect • Use Stand ups to pull and adapt • Inculcate a culture of continuous improvement
- 50. Questions ? govinds@thoughtworks.com
Notas do Editor
- Not a tutorial; the presentation represents the experiences from the ground; and it chronicles the evolution of the process of the team.
- What is a project managers world looks like ? Our worlds are unpredictable. Any of the variables change and they drive us into a mad rush. Commitments are made and in the ever changing environment we struggle to keep them on track. Worse our past historical data is unpredictable and cant make any reliable plans. Organization context budget changes etc change the risk profile of the project and the probability of deliveryResponded with shorter and smaller work chunks and adopted a strategy of divide and conquer.Many of the agile and iterative nature of software development approaches are a response to the above problem.
- Story - Start off by setting the perspective of Increasing project success Rates.Mainly attributed to: iterative projects
- Story Line: Given the dismal record, Agile promised to rescue by putting the control straight with the customers.Given the failure rates of projects, the familiar success to failure percentage Agile was a fresh breeze of airFor clients and developers Agile was a welcome change for the routine processes aka waterfallIn a era of failing project Agile promised to rescue them
- But what you cant afford to wait for an iteration ? When the customers world is very fast and their environment changes so rapidly that you cant even afford to chunk up smaller requirements ?
- Under these circumstances we found ourselves engaged with a customer in the summer of 2010. A startup who had managed to get their idea into production with well paying customers. But the future depended on enhancing the offerings while keeping the platform running. We were doing 4 things at the same time. More importantly our focus was to re-engineer the way software delivery is done, bringing in best practices on all of the above mentioned areas of work.
- The world of wickedness continues when we had this weird contract which was based on performance. A part of our payment was related to the ability or the speed in which we deliver software to productionQuarterly evaluation which will keep us going.
- We hit the ground running and the first thing we found werent all that great:Legacy code with no proper safety net around themTeam hadnt adopted any sound engineering practices which are a pre-requisite for an iterative and incremental development work.Rapid response caused more headaches
- Explain in detail how the story backlog as a strategy was adopted. What is a story backlog ? At the end of the 3 week analysis work we had built a backlog of high priority items to be be delivered.We hit the ground running and evolved a very simple strategy of building up a good backlog across the various streams of work. Keep very small milestone releases to gain quick experience.Idea was to fail and fail fast so that we learn our lessons to adapt and respond.
- We didn’t have to wait for the first milestone release.As early as the third week, the team stalled. Suddenly the backlog we had built vaporized, as a result of very rapdily changing backlog.
- We typical face these kind of problems and pull a few tricks out of our sleeves.None of them worked, so we added a BA to ease out the requirements. Routine levers didn’t work. There was no control on the story throttle. Requirements kept changing and inventories caused excess wastage in terms of effort.Does it even make sense of fixing a backlog ? A real shift of mindset that occurred at this stage
- Pegged us this question on how real was the backlog ?
- What was needed was a flexible process that responded faster to the changes in the environment.A move from a SCRUM flavour to a slightly fluidic model. Can we design a process that can ebb and flow
- Answers to our question resulted in our first response.
- We went and build a strategic buffer. All aimed towards smoothening the flow and reducing the stall the team faced.If there is no work in the inventory we will pull these into our stream, essentially a set of low priority works which will otherwise not be played. But a clear and well defined protocol on how and when will this work be pulled in for development.Its was counter intutive but it helped smoothen the flow in the system.
- How do you now ensure that the team doesn’t over produce these low priority items ?We followed it up with a limit in the Inventory.Quoting from the Lean concepts anything that is under process is inventory. So what you don’t want is an over production of these strategic buffers and an over enthusiastic team that pulls things fast enough.As you will see the aim of WIP is to ensure that you wait till the end for the work to complete before pulling in additional work.WIP resulted in reducing wastage as a result of fast changing priorities clubbed with the low priority issues that we had proritized.
- WIP in conjunction with the limits resulted in producing just enough
- WIP resulted in Pull. The focus turns towards pushing requirements out of the door rather than over producing and causing too much of requirements to be pulled in for development. The focus was on throughput rather than taking in more of these low priority work.
- What resulted was a smoothening of the flow. The concept and fixation towards having a fixed backlog for every iteration slowly began to changeAnalysis work got into a rhythm of pushing the right kind of story at the appropriate timeTeam also understood where was the constraint which is a huge plus – in a team of 2 DEVs and 1 QA
- Things did settle in. The team’s flow was eased out and some high priority stuff was getting done.Talk about the fact that you were still reporting velocity on a weekly basis.
- We were reporting velocity of the stories and found a sudden burst of velocity and the team was having it easy. We found ourselves throwing in more and more stories out of the window.Some of us sitting in didn’t find this right, on some weeks we were doing some excellent numbers and on others extremely low and found it dificult to justify. We could have left it to chance but you always look for hitting a steady state and we could never do that.In a normal scenario we knew our story mix and here there wasn’t any clue.
- New Requirements kept flowing and the sizes varied from just 2 hours to 4 days.We started to look at our story estimates really close and we found out that some of them werent really 1 pointers while they were in hours of work and there wasn’t any consisency of story sizes.
- We were now ready to try our second response to this problem.
- We moved away from a point based estimates to a more coarse grained estimates based on T-shirt sizing We later revised to a better classification mechanism based on the kind of work.
- Clearly points based estimation scale didn’t work and reporting velocity was a distracting factor.What is the right measure of throughput ? Number of stories executed or the average time to execute a request ?
- So what is the point reporting that you did 15 stories ?does it really singnify what kind of work you did ?Pegged this question of what do we stand for ? In other terms are we reporting what we are really doing ?
- Our 3rd response now turned towards looking real closely on our work that we are currently doing and making it resemble close enough to what we report on the velocity front
- Charting out the work we were doing – here is how it looked like. The upstream and downstream processes were not in our control and we believed that our work ended the moment we tested and reported our work.
- So re-visting the story wall here is how it looked like. WIP assured throughput and we were happy testing them.Until a new problem occurred that resulted in stuff breaking at regression testing in production.
- So we evolved to include automation as part of our scope.
- The modified diagram looks like this.Now with the new value chain in place lets look at how WIP works.
- How does WIP help ?Already 7 cards in Progress. What do you do next ? No scope to pull in work.
- Capacity available but devs are not pulling in any work. They are swarming to push the stories out into automation.In this case they have done automating a few and there is a capacity but waiting for the slots to get filled up upstream.
- Pull and signal from the story wall. How is a story wall structured ?
- Our 4th response focussed on reporting of velocity
- We moved away from reporting velocity and started measuring the time it took for us to push the stories out of our value chain.After a few stories and rounds we started to see some narrowing of the mean time of our value chain. We were still reporting velocity more in terms of the number of items we moved out of the production line but the cycle time started to reflect more accurately what we were doing.
- So how do you improve your metrics reporting ?Add cycle time, lead time and waste time.
- What did we observe in the end ?
- Was that an end of iterations ?We still used iterations as a check point but were no longer
- Some key takeaways from my experience
- What concepts of ToC applies here?
- Story Line – Promote flow, focus on value and continously improve. Don’t be dogmatic. Are there processes that will weave very smoothly into our daily routine that will make us work better?