Experience the Power of Pull Systems
Has adding WIP limits increased conflicts in your team? Are your developers and testers always in conflict with each other despite having a kanban board? Does your team think limiting WIP is not practical?. If you answered yes to any of these questions, this session is for you.
This is a story of a team that implemented WIP limits, only to find that conflicts can arise when there is no true pull mechanism. Pull system does not just mean that people assign work to themselves in the sprint planning. It means a lot more than that.
In this experience report, I present the ups and downs faced by the team when they experimented with WIP limits and their way forward.
Outline/Structure of the Experience Report
- Introduction - 2 mins
- Motivation behind WIP limit introduction - 5 min
- Effects of introduced WIP limits - 3 min
- How did the team overcome the bad effects? - 7 min
- Summary + Q&A - 3 mins
- Practical view of what can happen when we limit work in progress overnight
- Anecdotes of how a team overcame the bad effects
- Understand the meaning of 'Pull' and 'Push' Sytems
- Differentiate pull systems from push systems
- How to Design a 'Pull' System?
- Why is it good to have 'Pull' Sytems for SDLC?
- Proper usage of WIP limits
Anyone who is curious to learn
schedule Submitted 6 months ago
People who liked this proposal, also liked:
Tom Gilb - Agile EngineeringTom GilbAgile GranddaddyGilb International
schedule 3 months agoSold Out!
1. Real Software Engineering, not just about coding, Not ‘CodeFlow’ like some agile methods.
2. Systems (level) Thinking: even for ‘Programs’ you need to integrate people, data, legal, hardware, cloudware and more.
3. Stakeholder Engineering: not merely ‘customer and user’: Stakeholder Stories, Stakeholder Xperience (SX not UX)
4. Simultaneous Multi-Values and Multi-Cost Requirements; as Agile Efficiency Measure, "Agility for Efficiency”.
5. Multi-Value Flow Optimization, Multi-Constraint Consideration.
6. Dynamic Design to Efficiency (Value/Cost): The Architect in the Agile Loop (IBM Cleanroom, Evo)
7. 100X Defect-Prevention from Requirements; using Spec QC + Planguage; at Intel, in practice. (Terzakis)
8. Dynamic Stepwise Priority Computation, based on Efficiency and Constraints. Using Impact Estimation Tables.
9. AI, Web 3.0, Solid, Symantic Triples, Ontology& Digitization. = Very High-Tech Agile Future: Bye Bye Yellow Stickies.
10. Scale-Free Agile methods, as proven big time, at Intel, and other places.
11. Agile Engineering on a small scale (16 Norway Developers, 4 x 4 Teams, at Confirmit, capture international market with dramatic product quality increases)
12. "Principles of Agile Engineering” : Logical Common Sense.
13. μActs: + -> Tailored Practices -> Tailored Methods: BYOM Bring Your Own Method. ‘Essence' and D.A.
Terry Haayema - Agile transformation or just another restructure?Terry HaayemaPrincipal Agile ConsultantPM Partners
schedule 6 months agoSold Out!
Is your agile transformation just another restructure? Is everyone being shuffled around into Tribes? Villages? Crews? Are people reporting horizontally into Chapters? Is there talk of how we need to go faster? Were decisions made behind closed doors? Was the focus on structure as if that will change everything? Consultants engaged who created lots of PowerPoint presentations with lovely motherhood statements about how our people are our greatest asset and the new structure will break down silos and allow us to go faster?
Then it’s announced, teams are shuffled around into squads, tribes, chapters, etc.. As the transformation builds up speed, everyone gets some training and there is a massive amount of change management comms, presentations, and events.
Big up front plans,… Big bang change,… Heavy Change Management,… Does that sound like waterfall?
In this talk we’ll discuss a better way by actually being agile about the way we approach agile!