When the organisation thinks about “moving to agile” or “adopting agile” commonly they think Scrum to form agile teams, then start the debate about how best to scale agile, SAFe, Scrum@Scale, Less, etc.
They then set up an Agile Transformation Project to plan the implementation of agile methodologies, how to adopt the new skills , designing new processes, defining new roles, how to put together something that in general goes against the current WoW.
At the heart of the transformation are the people, they who will suffer the change, who are asked to become agile, who need to change their WoW. So while all the above-mentioned activities go on how about if we asked teams,
- to work on the most important things [PRIORITY].
- to cut the work into the smallest possible value [SIMPLIFICATION].
- to finish started work before takin on new [OWNERSHIP]
- to seek/provide help from/to peers [COOPERATION]
- to deliver value on a regular basis [CONTINUOUS DELIVERY].
- to get feedback as often as possible [COMMUNICATION LOOPS].
- to adapt their work process iteratively [CONTINUOUS IMPROVEMENT].
… in order for them to get a feeling for agility, ahead of teaching a new methodology, rules, and roles to become agile .
The above are plain common-sense activities that would be easy to coach, implement and monitor; activities that by themselves promote agility principles. It would become much easier, once these are mastered and adopted, to shape up the team’s delivery model as well as the organisation’s business agility model (agility at scale).
As the teams, and by extension the organisation, find their own agility model it is much likely for the evolution to new WoW to succeed and business agility to fit into the company culture.
Adaptive Ways 