Download to read offline
Uploaded by⇥ Tung Lam Vu ⇤
Agile (mal)Practices Considered Harmful
Vu Tung Lam discusses some common Agile practices and provides reflections on how they can be improved. He notes that practices like story point estimation and ideal hour estimation are not always useful and can get in the way of meaningful technical discussions. Tracking tasks without estimates and focusing on delivering customer value are presented as better alternatives. Large-scale predictive planning is also discussed critically, with an emphasis on facilitating changes and fast delivery over accuracy. The presentation advocates shifting to a mindset of "being Agile" rather than just "doing Agile".
More Related Content
Similar to Agile (mal)Practices Considered Harmful
![[AOTB] Agile Methods Are Dangerous](https://cdn.slidesharecdn.com/ss_thumbnails/aotbagilemethodsaredangerous-180712123626-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile (mal)Practices Considered Harmful
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. …an Agile coach 33 Ò Vu Tung Lam Ò Agile Coach & Trainer, Why Innovation! ÒExpert in Agile Training & Coaching, Agile Transformation & Scaling, Leadership, IT Organization & Management. Ò Have successfully guided companies of varied size (from a single team to multiple teams geographically distributed) through their transformation to higher Agile fluency. Ò Experiences scaling Agile transformation to multiple teams, multiple departments beyond IT. Ò Practical approach for Agile implementation with a combination Scrum, XP, Kanban, Lean, DevOps, LeSS and SAFe. Ò Decade of experience managing, building engineering team and implementing best technical practices such as pair-programming, unit testing, test driven, automation, CI/CD.
- 34.
- 35.
- 36.
- 37.
- 38. • It offers some useful information • Not more accurate •Inflatable • Language barrier • … could have been more cost effective 38 Cost effective tool… but
- 39. Perhaps just count the items… • What if a story is too big? – Does this story fit in to a sprint? –If not split it up into two… • If they still don’t fit, split them further… • Focus attention to delivery customer value instead of delieverying tasks 39
- 40. Scaffolding 40 • “Scaffolding, also called scaffoldor staging, is a temporary structure used to support a work crew and materials to aid in the construction, maintenance and repair of buildings, bridges and all other man made structures.“ • Story points are useful to teach team a different mentality when it comes to estimation • To be removed once the team has mastered the idea and become mature
- 41.
- 42.
- 43. Is it necessary? • Very waterfall-ish • More time consuming than necessary •Mainly used to construct burndown chart – “Let’s have a pretty chart” syndrome • Estimation becomes the goal of the technical planning exercise – Instead of having a meaningful discussion about technical solution 43
- 44. Team A • Estimate stories in points • Estimate tasks in hours •Sprint burndown chart created and updated on daily basis • Faster ceremonies, nice graphs • More surprises Team B • Split stories until they fit in sprint • Focus on the technical discussion, capture outputs in tasks • But make sure tasks are <2 days • Longer but deeper discussion • More creativity 44 A tale of two teams…
- 45. The essence • Focus on the conversation, don’t let estimation gets in the way • The technical solution matters more •It doesn’t matter how long it takes – As long as each task can be reasonably achieved by team in less then 1-2 days • Burndown chart? – Remove it – Or just count the number of tasks – Or just track points/stories burndown instead 45 Happier Team
- 46. Pick your tools appropriately TasksFeatures 1.Don’t estimatefeatures.Just count them. 2. Estimate features in t-shirt size 1. Skip tasks 2. Don’t estimatetasks.Just count them. 3. Estimate tasks in days 1d 2d0.5d 4. Estimate tasks in hours 12h 8h4h S M L Hours? Days? Weeks? S M L 3. Estimate features in story points 1sp 2sp 5sp 4. Estimate features in ideal man-days 1d 3d 6d Henrik Kniberg
- 47.
- 48. Predicting the future… • When can we ship this feature? • What can we ship in the next release cycle? •What our road map is going to look like? • How do we coordinate inter-teams efforts? 48
- 49.
- 50. Observations • Useful for communication, building consensus… • Useful for inter-teams dependencies •Adding a lot of assumptions as requirements • Usually lead to the discussion of scope, commitment and deadlines • Fairly inaccurate 50
- 51. From • How to estimate accurately • How to anticipate changes •Delivering software • Meet deadlines • Resolving dependencies To • How to make estimation insignificant • How to facilitate changes • Delivering customer value • Meet business objectives • Ability to delivery fast, frequently with high value 51 A shift of mindset…
- 52.
- 53.