Ο όρος “Agile Transformation” έχει καταστεί τα τελευταία χρόνια σχεδόν συνώνυμος με τον ψηφιακό εκσυγχρονισμό. Διοικήσεις επενδύουν σε frameworks, πιστοποιήσεις και εργαλεία, με την προσδοκία ότι η υιοθέτηση του SCRUM ή γενικότερα του Agile θα επιφέρει αυτόματα αύξηση παραγωγικότητας, ταχύτερο time-to-market και καλύτερη ευθυγράμμιση με το business. Στην πράξη όμως, αυτό που συχνά μετασχηματίζεται δεν είναι ο οργανισμός, αλλά η ορολογία που χρησιμοποιεί!
Το πιο συνηθισμένο φαινόμενο είναι η επιφανειακή υιοθέτηση πρακτικών χωρίς αντίστοιχη αλλαγή στον τρόπο λήψης αποφάσεων. Daily stand-ups πραγματοποιούνται κανονικά, τα sprints εκτελούνται με πειθαρχία, και τα εργαλεία backlog management είναι πλήρως ενσωματωμένα. Παρ’ όλα αυτά, οι κρίσιμες αποφάσεις συνεχίζουν να λαμβάνονται ιεραρχικά, εκτός ομάδας, με αποτέλεσμα οι ομάδες να λειτουργούν σε ένα “Agile shell” αλλά με καθαρά waterfall πυρήνα. Σε ένα έργο ανάπτυξης πληροφοριακού συστήματος για κανονιστική συμμόρφωση, για παράδειγμα, μπορεί να παρατηρηθεί ότι το backlog ενημερώνεται δυναμικά, αλλά οι προτεραιότητες καθορίζονται σε τριμηνιαία steering committees, ακυρώνοντας στην πράξη την έννοια της συνεχούς προσαρμογής.
Ένα δεύτερο συστημικό πρόβλημα είναι η υποτίμηση του ρόλου του Product Owner. Σε πολλές περιπτώσεις, ο ρόλος ανατίθεται σε κάποιον που λειτουργεί περισσότερο ως συντονιστής απαιτήσεων παρά ως φορέας επιχειρησιακής αξίας. Το αποτέλεσμα είναι user stories που περιγράφουν λειτουργίες χωρίς σαφή σύνδεση με measurable outcomes. Για παράδειγμα, η υλοποίηση ενός feature για reporting μπορεί να ολοκληρωθεί εντός sprint, αλλά να μην χρησιμοποιείται ποτέ ουσιαστικά, διότι δεν υπήρξε πραγματική κατανόηση του επιχειρησιακού προβλήματος που υποτίθεται ότι επιλύει.
Παράλληλα, η τεχνική διάσταση του Agile μετασχηματισμού συχνά αγνοείται. Η υιοθέτηση iterative delivery χωρίς επένδυση σε automated testing, continuous integration και αρχιτεκτονική συνοχή οδηγεί σε συσσώρευση technical debt. Σε legacy-heavy περιβάλλοντα, όπως συστήματα που εξελίσσονται επί δεκαετίες, η προσπάθεια να “κουμπώσει” το SCRUM χωρίς refactoring της βάσης καταλήγει σε sprints που παραδίδουν μεν λειτουργικότητα, αλλά επιβαρύνουν εκθετικά τη συντηρησιμότητα του συστήματος.
Το κρίσιμο σημείο είναι ότι το Agile δεν είναι διαδικασία αλλά αλλαγή παραδείγματος. Προϋποθέτει μετατόπιση από τον έλεγχο στην εμπιστοσύνη, από την πρόβλεψη στην προσαρμογή και από την τοπική βελτιστοποίηση στη συνολική αξία. Όταν αυτές οι μετατοπίσεις δεν συμβαίνουν, ο “μετασχηματισμός” περιορίζεται σε ένα σύνολο τελετουργιών. Είναι χαρακτηριστικό ότι οργανισμοί με υψηλό βαθμό “Agile adoption” συνεχίζουν να αντιμετωπίζουν καθυστερήσεις, επαναλαμβανόμενα defects και χαμηλή ικανοποίηση χρηστών, ακριβώς επειδή η αλλαγή δεν άγγιξε τα θεμελιώδη επίπεδα λειτουργίας.
Η εμπειρία δείχνει ότι οι επιτυχημένοι μετασχηματισμοί δεν ξεκινούν από την υιοθέτηση frameworks, αλλά από την κατανόηση του γιατί αυτά χρειάζονται. Σε περιβάλλοντα όπου το business είναι πρόθυμο να αναλάβει ενεργό ρόλο, όπου οι τεχνικές ομάδες έχουν την αυτονομία να λαμβάνουν αποφάσεις και όπου η αποτυχία αντιμετωπίζεται ως πηγή μάθησης, το Agile λειτουργεί ως επιταχυντής. Σε αντίθετη περίπτωση, λειτουργεί ως ένας ακόμη μηχανισμός που καλύπτει τις ίδιες παθογένειες με νέα ορολογία.
Τελικά, ο πραγματικός μετασχηματισμός δεν είναι θέμα SCRUM, SAFe ή οποιουδήποτε framework. Είναι θέμα οργανωσιακής ειλικρίνειας. Αν ένας οργανισμός δεν είναι διατεθειμένος να αλλάξει τον τρόπο με τον οποίο σκέφτεται, αποφασίζει και μετρά την επιτυχία, τότε το μόνο που μετασχηματίζεται είναι το λεξιλόγιο και όχι η ουσία.
Βιβλιογραφία
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
- Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing Agile. Harvard Business Review.
- Denning, S. (2018). The Age of Agile. AMACOM.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
- Beck, K. et al. (2001). Manifesto for Agile Software Development.
