Agile (mal)Practices Considered Harmful

1. Agile (mal)Practices Considered Harmful
Vu Tung Lam (@vutunglam)
Agile Coach
Why Innovation!

2. The journey…
…and reflection
2Slide deck courtesy of Stephen Chin

3. Once upon a time… I was a happy hacker
3https://www.flickr.com/photos/brickpimp/8453569593/

4. Working in teams with friendly coworkers…
4https://www.flickr.com/photos/oblongpictures/5250948891/

5. But a scary boss, who sold products we never built
5https://www.flickr.com/photos/oblongpictures/5250948891/

6. And I was left holding the banana…
6https://www.flickr.com/photos/kerrythomas/14765382780/

7. So we decided to go
Extreme Scrum!
7https://www.flickr.com/photos/kwl/3401221326/

8. We started “pair programming”…
8https://www.flickr.com/photos/benjamingolub/3789762583

9. Implemented unit testing…
9https://www.flickr.com/photos/magicdaddy/4706639094

10. And began working at a sustainable pace.
10https://www.flickr.com/photos/isherwoodchris/7653012036

11. It was a lot of fun, and we were very productive
11

12. Then I set out to join the empire!...
12https://www.flickr.com/photos/activars/6616140577

13. One day the boss called… and wanted my help to
implement Agile
13

14. It was a little daunting at first…
14https://www.flickr.com/photos/legofenris/4641828205/

15. But we had good teams
15
https://www.flickr.com/photos/isherwoodchris/7322132364/

16. So we started a mission to convert the organization
16https://www.flickr.com/photos/prodiffusion/5714174718

17. Rolled out new development practices
17https://www.flickr.com/photos/kalexanderson/5765576376/

18. And let the troops get creative
18https://www.flickr.com/photos/kalexanderson/6113247118/

19. We created
hyper performing
teams
19https://www.flickr.com/photos/23950335@N07/6950128894/

20. There were some dissenters…
20https://www.flickr.com/photos/si-mocs/5593371079

21. But a few heads rolling didn't slow us down…
21https://www.flickr.com/photos/s3a/2064339106/

22. And the Agile rollout was a huge success!
22https://www.flickr.com/photos/valiantize/11282717814/

23. As the organization grew, we prepared a large Agile force
23https://www.flickr.com/photos/jedmed/5359805561

24. And deployed the big ships… continuously
24https://www.flickr.com/photos/jurvetson/25269593

25. But doing Agile at large scale was a lot different
25https://www.flickr.com/photos/jurvetson/542500748/

26. We spent most of our time in meetings…
26https://www.flickr.com/photos/skinnylawyer/6884959175

27. Instituted lots of "processes"
27https://www.flickr.com/photos/legofenris/4776824191

28. Did company-wide invasion release planning
28https://www.flickr.com/photos/pedrovezini/5450412111/

29. And had to resolve internal conflict
29https://www.flickr.com/photos/skinnylawyer/6884960361/

30. Conquering the Universe with Agile is very satisfying!
30https://www.flickr.com/photos/jurvetson/83176915/

31. So, I made my escape from the Empire
31https://www.flickr.com/photos/p_valdivieso/9006007735

32. And became a normal Agile (coach) guy…
32https://www.flickr.com/photos/d35ign/11826583146

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. Some things I learned…
34https://www.flickr.com/photos/23950335@N07/6032572260/

35. Where are you?
35

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
Before
After

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 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. Estimation in Ideal Hours/Days
41

42. How it works
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. Release Planning
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. How it is done
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. An analogy of sport coaching
52

53. do agile vs. be agile
53
Thank you!
do agile to be agile