How to not f*** up Agile/SAFe

Contents of this list are compiled from real world Agile/SAFe trenches.

The intent with this post is to highlight anti-patterns and enable instant improvements. No offense intended.

(No observations or examples below are unique or related to specific persons’ behaviors)

Don't do this:

1. Anchor on self, make Agile/SAFe all about you and your particular way or perspective, think: ‘if I don’t..., other people won’t...’
2. Assume you know what other people think or feel about Agile/SAFe, without asking them regularly and listening carefully to their answers.
3. Ignore bias, just roll with intuition.
4. Assume that Agile/SAFe knowitalls knows it all.
5. Ignore egocentrism and Group Think, just ask your friends and team for feedback, and figure it out yourself.
6. Ignore indications of Silo Thinking.
7. Trust that Agile/SAFe Silo Thinking isn’t as toxic for productivity as other forms of Silo Thinking.
8. Expect Groups and Teams to spot and mitigate Group Think and Silo Thinking on their own.
9. Rely on one framework, or one expert, to provide all your answers.
10. Embrace Agile/SAFe leadership guidance from people with models and frameworks as their only/primary source of reference.
11. Follow and take implementation advice from ‘laptop experts’, who have primarily read and written about SAFe, maybe done a course, or taken a certification.
12. Echo wisdom of self-acclaimed experts without experience with end2end responsibility for organizing and running an authentic Agile team, Squad, Tribe or Release Train, and with a clean 100% track record and no bruises or battle scars from real action.
13. Focus on keeping up appearances, chant ‘perception is reality’.
14. Extrapolate from the first data that fits your expectations, or supports your viewpoints.
15. Generalize from hypotheses.
16. Promote data and hypotheses without fact checking, ignore lack of references for authors of papers.
17. Tone down and depreciate the need for actual experience for agile evangelists and trainers, emphasize 'energy', 'action' and framework proficiency.
18. Generalize Agile insights from one-off results in individual, non-peer reviewed research papers and anecdotes.
19. Assume that Agile/SAFe theory/methodology works in practice, out of the box.
20. Implement appealing conceptual Agile/SAFe ideas, approaches, frameworks and theories 1:1 in practice.
21. Assume logical designs implements 1:1 in practice.
22. Ignore AS-IS, and jump straight into TO-BE.
23. Avoid systematic approaches, allow unsupervised team-up of people who are uncomfortable with repetition and measurement.
24. Give in to 'Not invented here' impulses.
25. Encourage Trial & Err over continuous improvement, by default.
26. Demand 'You build it, You own it' DevOps, without exploring and mapping the consequences for e.g. x-skilling competency requirements, Segregation of Duty and SLA's.
27. Rely on traditional leadership and management paradigms, leverage hierarchy, roles that ends with ‘...Manager’, and position power to enforce submission and limit divergence and diversity in thinking patterns.
28. Remove any role that ends with '...Manager', without thinking through governance impact.
29. Rely on self-declared agile specialists to orchestrate, plan and lead the most sensitive parts of your transformation.
30. Rely on externals with zero skin in the game and zero long term accountability to motivate and drive teams of employees with skin in the game and accountability.
31. Expect continuity and good culture transfer from people/consultants with a history of ejection from teams or projects, and/or frequent job changes.
32. Assume everybody will be ok with key driver positions being staffed with externals rather than internals.
33. Ignore mental accounting, that people maintain some sort of shadow P&L and balance sheet of the investments they see you make in e.g. external vs. internal capacity.
34. Equal externals with internals in communications and presentations, and expect teams and employees to do that in practice too.
35. Rate people’s capabilities, make capability maps, but don’t update or use them.
36. Think ‘it was probably the circumstances’ or blame it on ‘culture eats strategy’ when transformation efforts fail.
37. Expect small x-functional Agile teams to save your day, any day.
38. Prefer staffing with people recommended by people in your teams.
39. Don’t test people at all, when recruiting.
40. Hire only experienced people, and assume they will know what to do, and how to do it in your organization.
41. Ignore track record when you hire for key driver positions like agile coaches and release train engineers. Just go for charm and personality.
42. Hire people with zero empathy, put them in charge of staffing, let them front the transformation, and rely on them to communicate the why and how of what you, yourself want to do.
43. Assume poor references are behavioral outliers or due to exogenous factors.
44. Give opportunities to people for hiding lack of skills, lack of consistency and lack of ability to concentrate behind continuously evolving practices and delivery momentum.
45. Don’t guide and train people, let them figure everything out themselves.
46. If you train people, train people only for specific roles and only when you think (you know) they need it.
47. Ignore the need for hiring, training and developing/growing professionals internally.
48. Assume that culture will take care of itself.
49. Rely on self-organizing teams as a grandfather principle, but don't apply it consistently.
50. Lock people down in fixed teams with no expiration date.
51. Don’t make career paths.
52. Generalize from the 70/20/10 model, use it as a cost containment tool, to promote on-the-job training and self-directed learning.
53. Assume people engage because their Manager asks them to.
54. Assume that it is your problem if there is ‘something’ missing or logic seems a bit off.
55. Don't ask follow-up questions when your Agile Coaches and evangelists are explaining solutions to you, and you don’t quite get it.
56. Worry about not blending in with Agile experts and Evangelists.
57. Encourage child > parent perspective.
58. Let the individual or the individual team take all the focus they want, at any time.
59. Let HIPPOs, HIghest Paid Person's Opinion override expert and team decisions.
60. Listen to or take guidance from HYPIR, Highest Yelling Person In Room.
61. Let customers make architeture and technology choices without consulting architects or development teams.
62. Fall in love with products or features, and fight for your right to do so.
63. Expect your Product Owner to have capacity to 1) specify and break down features, 2) prioritize pipeline, 3) drill down to functional bits and 4) look 2-3 cadences ahead. Simultaneously.
64. Expect Customers to know intuitively what goes on in your development teams.
65. Assume that your account people and Product Owners are tuned in to business priorities at all times.
66. Assume that Architects always knows what goes on in business.
67. Embrace a ‘challenger’ mindset to increase assertiveness in account and development organizations.
68. Apply the ‘challenger’ mindset also to your internal alignment dialogues in management and between teams.
69. Pull customers through all your ideas, reflections and worries in real time BEFORE you figure it out yourself.
70. Let customers write requirements, feed them directly into PI Planning, and execute on the requirements AS-IS, immediately - as they arrive.
71. Request customers to make judgment calls and choices that they are not trained for, or have no experience with.
72. Downscale or ignore regression testing and test automation when funding is tight.
73. Push responsibility to customers immediately for released features.
74. Make customers solely accountable for all priorities and choices.
75. Encourage pivoting.
76. Embrace pivoting as a team choice.
77. Throw away entire work products when pivoting.
78. Don’t standardize measures of work, like story points, t-shirt sizing, velocity across teams, leave it to the individual teams to figure out themselves.
79. Measure progress rather than outcomes to take focus away from actual results, simply reward based on trust, self-reporting and expectations that people will complete every aspect of what they forecast.
80. Expect end2end perspective from all, assume that everybody applies it.
81. Assume task sequence has no impact on development speed.
82. Ignore external dependencies.
83. Rely on teams to mitigate internal dependencies themselves by coordination and re-arranging their backlogs.
84. Substitute plans with state diagrams, think of the world as architectural abstractions, communicate that way to business.
85. Act and prioritize as if all deliveries will be independent, shippable products.
86. Take prototypes live in prod, mature and scale from there.
87. Apply a Die Hard fail-forward, continuous deployment mindset in heterogenous system environments.
88. Make complexity somebody else's problem, associate it only with shortcuts, trial & err and low quality solutions, distance yourself from it.
89. Equal all Management activities with waste.
90. Ignore any kind of coordination and prioritization activity with purpose to secure organizational defaults, prevent bottlenecks and moderate constraints, including policies, budgets and deadlines.
91. Ignore cost and risk perspectives, assume unlimited funding by default.
92. Think of accountability and responsibility only as general contraints or inhibitors of creativity.
93. Ignore people's need for competency development, and variance in day to day work.
94. Encourage development teams to not get attached to work products.
95. Rely on ROAMing for Risk Management.
96. Promote the idea that pyramid/matrix organization structures are anti patterns to 'true' Agile/SAfe, don't provide practical alternatives, just hint to hyped Agile/SAFe antithesis and abstract illustrations.
97. Equal 'Abstraction' with 'Aggregation' when thinking and talking about reporting and governance.
98. Assume that SAFe scales agile out of the box.
99. Perceive customers as a given.
100. Say ‘RESOURCES’ whenever you talk about PEOPLE.

I am sure I missed a lot of good examples, please feel free to add them in the comments.

#sharingiscaring

#practicalagile

#dontfckitup

#agilesafe