Υπάρχει μια σιωπηλή υπόθεση πίσω από το SCRUM που σπάνια αμφισβητείται. 'Οτι δηλαδή το business γνωρίζει τι θέλει. Ότι ο Product Owner έχει σαφή εικόνα της αξίας, ότι τα requirements μπορούν να μεταφραστούν σε user stories, ότι το backlog είναι μια ιεραρχημένη αποτύπωση επιχειρησιακών αναγκών. Στην πράξη, ιδιαίτερα σε σύνθετα πληροφοριακά συστήματα, αυτή η υπόθεση καταρρέει σχεδόν από την πρώτη κιόλας εβδομάδα.
Το business συχνά δεν ξέρει τι θέλει. Ξέρει τι δεν θέλει, αντιδρά σε αυτό που βλέπει, επαναπροσδιορίζει στόχους καθώς κατανοεί τις δυνατότητες της τεχνολογίας. Σε ένα περιβάλλον όπως η διαχείριση μετοχολογίου ή οι εταιρικές πράξεις, όπου οι κανονιστικές απαιτήσεις συνυπάρχουν με επιχειρησιακές ιδιαιτερότητες, η “ανάγκη” δεν είναι ποτέ στατική. Ένα αρχικό αίτημα για «απλή διανομή μερίσματος» μπορεί να εξελιχθεί σε πολυπαραμετρική διαδικασία με εξαιρέσεις, χρονικούς περιορισμούς και dependencies από εξωτερικούς φορείς. Το SCRUM δεν σχεδιάστηκε για να αντιμετωπίσει σταθερές απαιτήσεις, σχεδιάστηκε για να επιβιώνει μέσα στην αβεβαιότητα.
Το αποτέλεσμα είναι γνώριμο. Backlogs γεμάτα user stories που μοιάζουν περισσότερο με ευχές παρά με απαιτήσεις, sprint plannings που βασίζονται σε εικασίες, και reviews που καταλήγουν σε φράσεις του τύπου «δεν το φανταζόμουν έτσι». Σε μια ομάδα που υλοποιεί σύστημα παρακολούθησης συναλλαγών για εισηγμένη εταιρεία, ένα story για “ενημέρωση θέσεων επενδυτών” μπορεί να θεωρηθεί ολοκληρωμένο τεχνικά, αλλά να απορριφθεί επιχειρησιακά επειδή δεν λαμβάνει υπόψη ειδικές περιπτώσεις nominee accounts ή καθυστερήσεις από τον θεματοφύλακα. Το SCRUM εδώ δεν απέτυχε. Απλώς λειτούργησε ως καθρέφτης της ασάφειας.
Η επιβίωση του SCRUM σε τέτοιο περιβάλλον δεν είναι θέμα πιστής εφαρμογής των ceremonies, αλλά αλλαγής νοοτροπίας. Το backlog δεν μπορεί να είναι στατικό artefact. Πρέπει να είναι ένας ζωντανός μηχανισμός μάθησης. Ο Product Owner δεν είναι μεταφορέας απαιτήσεων, αλλά διαμεσολαβητής γνώσης ανάμεσα σε business και τεχνολογία. Οι ομάδες που αντέχουν είναι αυτές που αποδέχονται ότι κάθε sprint δεν παραδίδει μόνο functionality, αλλά και κατανόηση. Σε ένα έργο υλοποίησης πλατφόρμας investor relations, η συνειδητή επιλογή να ξεκινήσει η ομάδα με “ατελή” user stories, αλλά με συστηματικά refinement sessions και στενή εμπλοκή των stakeholders, οδήγησε σε ταχύτερη σύγκλιση από μια υποθετικά “πλήρη” ανάλυση που θα είχε γίνει upfront.
Αυτό που διαφοροποιεί τις ώριμες ομάδες είναι η ικανότητά τους να μετατρέπουν την αβεβαιότητα σε διαδικασία. Να εισάγουν πρακτικές όπως story mapping, prototypes, spikes, και iterative validation με το business. Να αποδέχονται ότι το “wrong increment” είναι μέρος της πορείας και όχι αποτυχία. Και κυρίως, να δημιουργούν ένα περιβάλλον όπου το business μπορεί να παραδεχτεί ότι δεν ξέρει, χωρίς αυτό να εκλαμβάνεται ως αδυναμία. Σε τέτοιο πλαίσιο, το SCRUM παύει να είναι μηχανισμός παράδοσης και γίνεται μηχανισμός ανακάλυψης.
Η μεγαλύτερη παγίδα είναι η ψευδαίσθηση βεβαιότητας. Όσο περισσότερο προσπαθεί μια ομάδα να “κλειδώσει” τις απαιτήσεις σε ένα δυναμικό περιβάλλον, τόσο απομακρύνεται από την πραγματική αξία. Το SCRUM δεν επιβιώνει επειδή οργανώνει την εργασία, επιβιώνει επειδή επιτρέπει τη συνεχή επαναδιαπραγμάτευση της αλήθειας μεταξύ business και IT. Το ερώτημα δεν είναι αν το business ξέρει τι θέλει. Το ερώτημα είναι αν η ομάδα είναι έτοιμη να ανακαλύψει μαζί του τι πραγματικά έχει αξία.
Βιβλιογραφία
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
- Pichler, R. (2010). Agile Product Management with Scrum. Addison-Wesley.
- Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
- Patton, J. (2014). User Story Mapping. O’Reilly Media.
- Ries, E. (2011). The Lean Startup. Crown Business.
