Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile (mal)Practices Considered Harmful

323 views

Published on

Agile (mal)Practices Considered Harmful

Published in: Technology
  • Be the first to comment

Agile (mal)Practices Considered Harmful

  1. 1. Agile (mal)Practices Considered Harmful Vu Tung Lam (@vutunglam) Agile Coach Why Innovation!
  2. 2. The journey… …and reflection 2Slide deck courtesy of Stephen Chin
  3. 3. Once upon a time… I was a happy hacker 3https://www.flickr.com/photos/brickpimp/8453569593/
  4. 4. Working in teams with friendly coworkers… 4https://www.flickr.com/photos/oblongpictures/5250948891/
  5. 5. But a scary boss, who sold products we never built 5https://www.flickr.com/photos/oblongpictures/5250948891/
  6. 6. And I was left holding the banana… 6https://www.flickr.com/photos/kerrythomas/14765382780/
  7. 7. So we decided to go Extreme Scrum! 7https://www.flickr.com/photos/kwl/3401221326/
  8. 8. We started “pair programming”… 8https://www.flickr.com/photos/benjamingolub/3789762583
  9. 9. Implemented unit testing… 9https://www.flickr.com/photos/magicdaddy/4706639094
  10. 10. And began working at a sustainable pace. 10https://www.flickr.com/photos/isherwoodchris/7653012036
  11. 11. It was a lot of fun, and we were very productive 11
  12. 12. Then I set out to join the empire!... 12https://www.flickr.com/photos/activars/6616140577
  13. 13. One day the boss called… and wanted my help to implement Agile 13
  14. 14. It was a little daunting at first… 14https://www.flickr.com/photos/legofenris/4641828205/
  15. 15. But we had good teams 15 https://www.flickr.com/photos/isherwoodchris/7322132364/
  16. 16. So we started a mission to convert the organization 16https://www.flickr.com/photos/prodiffusion/5714174718
  17. 17. Rolled out new development practices 17https://www.flickr.com/photos/kalexanderson/5765576376/
  18. 18. And let the troops get creative 18https://www.flickr.com/photos/kalexanderson/6113247118/
  19. 19. We created hyper performing teams 19https://www.flickr.com/photos/23950335@N07/6950128894/
  20. 20. There were some dissenters… 20https://www.flickr.com/photos/si-mocs/5593371079
  21. 21. But a few heads rolling didn't slow us down… 21https://www.flickr.com/photos/s3a/2064339106/
  22. 22. And the Agile rollout was a huge success! 22https://www.flickr.com/photos/valiantize/11282717814/
  23. 23. As the organization grew, we prepared a large Agile force 23https://www.flickr.com/photos/jedmed/5359805561
  24. 24. And deployed the big ships… continuously 24https://www.flickr.com/photos/jurvetson/25269593
  25. 25. But doing Agile at large scale was a lot different 25https://www.flickr.com/photos/jurvetson/542500748/
  26. 26. We spent most of our time in meetings… 26https://www.flickr.com/photos/skinnylawyer/6884959175
  27. 27. Instituted lots of "processes" 27https://www.flickr.com/photos/legofenris/4776824191
  28. 28. Did company-wide invasion release planning 28https://www.flickr.com/photos/pedrovezini/5450412111/
  29. 29. And had to resolve internal conflict 29https://www.flickr.com/photos/skinnylawyer/6884960361/
  30. 30. Conquering the Universe with Agile is very satisfying! 30https://www.flickr.com/photos/jurvetson/83176915/
  31. 31. So, I made my escape from the Empire 31https://www.flickr.com/photos/p_valdivieso/9006007735
  32. 32. And became a normal Agile (coach) guy… 32https://www.flickr.com/photos/d35ign/11826583146
  33. 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. 34. Some things I learned… 34https://www.flickr.com/photos/23950335@N07/6032572260/
  35. 35. Where are you? 35
  36. 36. Story Points-based Estimation 36 • Relative estimation technique: by comparison or by grouping of items of equivalent difficulty, instead of estimation in absolute units of time
  37. 37. 37 Before After
  38. 38. • It offers some useful information • Not more accurate • Inflatable • Language barrier • … could have been more cost effective 38 Cost effective tool… but
  39. 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. 40. Scaffolding 40 • “Scaffolding, also called scaffold or 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. 41. Estimation in Ideal Hours/Days 41
  42. 42. How it works 42
  43. 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. 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. 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. 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. 47. Release Planning 47
  48. 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. 49. How it is done 49
  50. 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. 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. 52. An analogy of sport coaching 52
  53. 53. do agile vs. be agile 53 Thank you! do agile to be agile

×