Feedback to my customer

Reading Time: 5 minutes

I am the only Agile coach that leave a review after me when i leave as consultant. Here is one example from one company i was with for eight months when i left for new challenges.

In general, i had expected this company to have come much further with the agile transformation. But “my law” tells us it takes as long as a company is old to adopt to the agile mindset. Give or take a few years. This company has a huge setup and been travelling a couple of years now, but nowhere I can find any signs on retrospective on the effort. I am sure it is done but kept hidden as much of the other documentation created. 

The good part of this effort is that we have created a lot of great structure capital like SWAP. And people want to use it because it is simple.

Tack för att du Tvivlar

SaFE is said to be the silver bullet here, but nowhere I can find a WHY behind this new approach. On the intranet I can find one line saying, “Through this new way of working we want to empower the teams to take mandate and be truly autonomous”. I cannot see what SaFE brings to the table when it comes to team autonomy? Autonomy is created when competence, trust and safety are in place and this is not a delivery aspect, it is a human aspect not for engineers to spend time on.

Being a pragmatic senior qualified and experienced agile coach, I can see a general pattern in the market I call is better SaFE than sorry. As a manager you don’t want to be the laggard, nor the scapegoat so you go with the flow, without questioning the value created vs the effort needed and by this adopt to what Prof. Mats Alvesson call functional stupidity. Looking at the VS having done SaFE for a while now I do not see any metrics indicating more agility than the SWAP teams. These are the metrics I have been looking for but not found:

  • Increased customer satisfaction
  • Faster delivery of customer value
  • Happier employees by increasing mandate

When speaking with the CIO he picked the metaphor of a formula 1 racing car when explaining what our mission was. The driver was the team and agility were to support this driver with new tires and fuel. If I turn back to this metaphor, I will say we have different circuits to race on here. Some are dirt, some are snow but very seldom dry tarmac. This means we must put on different tires for different circuits and even cars and drivers. Going on slicks (SaFE) in Paris-Dakar is not an excellent choice. Or do put them on – but learn from its next race.

If I just must pick one suggestion for the future from my backlog here, I would choose one: To apply the two missing competences to EAS: HR (experienced from agile HR) and a pragmatic experienced agile coach, like me (but permanent and not a consultant). With this balance into the EAS I am sure a pragmatic strategy for an agile transformation can evolve rather than the one size fits all.

But at the end of the day, I say – take it to the teams and let them decide. That’s what I call teams first thinking and autonomy.

Here is my SWAT analysis on the


  1. Skilled people.
  2. Mature teams
  3. A feeling of “we”.
  4. Good implementation of SaFE in LC&I
  5. SWAP is a great slim process in general.
  6. Consultants welcome at trainings.
  7. Strong skills in Atlassian suite in Baltics
  8. Agile coaches are decentralized.
  9. Great learning tools (SABA and Linkedin).
  10. Culture of openness.
  11. Management close to the teams.
  12. SI#6 has great management
  13. SI#6 sessions are extremely informative and pedagogical


  1. Few great spaces for workshops
  2. Weak skills in Atlassian suite in Stockholm
  3. No standing workplaces available
  4. No pull culture. 
  5. Low skills in Jira
  6. No experienced Agile coaches in EAS
  7. SWAP 3.2 is a minimal “must have” for a VS instead of a toolbol.
  8. No collaboration tools
  9. Low meeting discipline (meeting
  10. No tools for workshops (post-it etc)
  11. Low discipline in structure capital.
  12. The most email intense organization ever
  13. SWAP is only development. Not procurement, business agility, maintenance and lifecycle management.
  14. Agile is a vision without a strategy
  15. SWAP is a push, not a pull, process.
  16. Retrospectives and demos “on top” and not by design.
  17. SWAP has no support for impediments
  18. No “flex” workplaces with ergonomic thinking.
  19. EAS are not a cross functional team. No team and HR skills.
  20. SWAP has no support for procurement processes (like SI#6)
  21. Roles and responsibilities not set.
  22. No Communitys/CoPs to ask for advice.
  23. SWAP – Team last thinking
  24. Hard to find a meeting room with short notice
  25. Forums have no value (Pulse, MAT, VSF etc).
  26. Onboarding of consultants takes too long
  27. Consultants not welcome in team-building.
  28. Stakeholders have no understanding for SWAP.
  29. EAS has no strategy, just ad-hoc.
  30. What are EAS and ACP. Fight-clubs? No names.
  31. One size fits all thinking.
  32. Agile is not a strategy.
  33. SWAP has no structure/support before CP1
  34. No follow up of CP5
  35. Requirements are weak.
    • No user stories
    • Jira is used in different ways.
  36. No (or weak) communities of practice.
  37. Too few Zebras in the Zoo
  38. Management not visible.
  39. Baltic/Swedish teams are too distanced
  40. No visible metrics.
  41. No demos.
  42. Fragmented locations
  43. Offshoring
  44. TATA
  45. High lead time
  46. Open space even for classified info.
  47. Not using English (Swedish/Lithuania)
  48. No history available
  49. No tool for surveys
  50. No handovers to new agile coaches
  51. Fear of taking on the value of Team coaches.
  52. No why in the SaFE approach
  53. No why defined in the need of Agile coaches. 
  54. Too many Agile coaches are consultants and no recruiting
  55. No focus on business agility, just delivery.
  56. EAS not supportive
  57. Innovation vs Lifecycle/Maintenance not measured.
  58. EAS theoretical and not close to the teams. No MVP in their backlog.
  59. No metrics for flow, just 
  60. Why do we send materials (ToR) and not publish?
  61. Business dev, regulatory, maintenance and lifecycle are the work types. Improvements are not a strategic work type. Why? The risk is that improvements come on top of delivery (not happen)
  62. Only quantitative metrics. Add metrics for flow and value.
  63. Nice slides bu why not use Jira when looking into ongoing work instead of PPT?
  64. Prioritization topics. Is this the same as Investment Opportunities? If so, do we follow the SWAP process and the checkpoints?
  65. 2019 the VS delivered 14 MVP with a lead time average 226 days. How do you take this velocity in your plan?
  66. Express requests (description) with either hypothesis or story format.
  67. Some risks were weaknesses. I can support a SWOT session.
  68. Compliance prio. relative prio needed vs the other work types. Also, a portfolio balance between work types to better support future ranking of work.
  69. Use a structured way of prio called rank? Rank = value/effort.  Value = Urgent+Important+risk+opportunity. Effort = Complexity/Time/Risk.
  70. A lot of talk of KPIs but no strategy.
  71. Very unstructured meetings in SWAP review.
  72. SWAP is not used for the discovery.


  1. Legal companies (Robur, Insurance) could be monoliths.
  2. HR is interested but not aboard yet.
  3. The new organization opens for real stream aligned teams
  4. Great interest for impact- and storymapping.
  5. Use the same metrics for SaFE and SWAP could be a interesting measurement.


  1. Agile coaches go to competitors.
  2. Low level of automation.
  3. Too much change at the same time cause.
  4. General problems in the bank has higher focus 
  5. Too complex setup for SaFE.
  6. Other challenges steal focus from innovation
  7. Too high trust in SaFE as a silver bullet instead of focus on agility.
  8. Reduction of flow due to not having any enabling or platform teams.
  9. SWAP is being “SaFified” too deep, creating one rigid process instead of two toolboxes.
  10. SWAP is not updated since 2 years back. Why not continuous improvement?
  11. SI#6 are underestimating the operational model which will conflict our way of working.

The action’s i suggest for further work with the agile transformation is formatted as user stories. I recommend this list is imported to Jira and to continue there, but first after a thorough prioritization and elimination of the waste.

Men du kanske tvivlar?


Håller du med? Eller inte? Diskutera här...