because agile doesn't work according to McKinsey

The reason agile doesn't work in companies is because the business function isn't adequately represented in project teams.

Se vi ricordate di come è composto un team agile, il team agile è fatto per essere autonomo nelle decisioni e nell’esecuzione delle attività di progetto, infatti ci dovrebbe sempre essere un rappresentante del business che sostanzialmente decide sulle funzionalità da sviluppare e la priorità degli sviluppi.

Ora, sebbene sembri facile avere un rappresentante del business all’interno dei team agile nella pratica non è né facile né scontato che se presente un rappresentante del business, questa persona abbia le competenze, l’esperienza e l’autorità per decidere le funzionalità da sviluppare e la loro priorità.

In realtà il rappresentante del business all’interno del team agile potrebbe decidere sulle funzionalità da sviluppare e la loro priorità solo nel caso in cui sia lui il responsabile del prodotto che il team sta sviluppando.

Supponiamo che un team stia sviluppando l’applicazione nativa per un retailer e che il product owner dell’app nativa venga assegnato al team agile di sviluppo. Bene, il product owner nel momento in cui viene messo di fronte alle scelte decisionali relative all’applicazione da sviluppare si troverà nella condizione di dover chiedere pareri e autorizzazioni per ogni singola decisione rilevante che abbia un impatto sulle altre funzioni organizzative con cui l’app dovrà necessariamente interagire.

Let's take some examples to clarify the dynamics:

  • Dobbiamo decidere la grafica dell’app –> Bisogna contattare l’art director o l’ufficio immagine dell’azienda per avere il sign off sulla grafica dell’app –> Il team agile deve aspettare le approvazioni del caso.
  • Dobbiamo decidere sui metodi di pagamento da attivare sull’app –> Abbiamo bisogno del direttore finanziario che approvi i metodi di pagamento e faccia le configurazioni
  • Dobbiamo decidere sui contenuti del catalogo dell’app –> Abbiamo bisogno del direttore merchandising che definisca quali sono i prodotti da mettere in vendita

and so on.

Tutti questi intoppi possono essere adeguatamente gestiti con un lavoro di pianificazione iniziale e un’attività di stakeholder management che è prassi normale in un progetto gestito in modalità waterfall.

Clearly, for complex projects, a planning method must be adopted rolling wave planning or more simply to adopt some best practices such as keeping a list of activities that are not completely defined and analyzing their dependencies to understand if these can have an impact on the total duration of the project.

The tools that traditional project management methodologies make available to manage these situations are:

  • Open questions (log)
  • Issue list (log)
  • Definition of blocking and non-blocking activities
  • Project requirements document
  • Product requirements document

Leave a Comment

Your email address will not be published.