In this second article (adapted from a mine recent participation in a PMI Rome Italy Chapter’s webinar - can see first article here), I explain some difficulties generated by application of Agile Project Management in company. My scope is to expose the impacts of this change and meanwhile to suggest some solutions to better manage it.

Items I will expound in this article concern:

• Agile’s impact on some roles;
• Agile impact on processes.

In questo secondo articolo (tratto da una mio recente intervento come speaker in un webinar del PMI Rome Italy chapter - primo articolo) espongo alcune difficoltà generati dall’applicazione o introduzione in azienda dell'Agile Project Management. Il mio intento è quello di esporne gli impatti e, al contempo, suggerire alcune soluzioni pratiche per gestire al meglio il change.

Gli aspetti che andrò a trattare in questo articolo sono legati:

• all’impatto dell’Agile su alcuni ruoli;
• all’impatto dell’Agile sui processi.

Impact on some roles

Developers

Maybe Agile methods biggest impact is on developers. This methods depend on the availability of skilled developers who must be:

• Available to work in team,
• Able to manage a continuous changing,
• Sufficiently resourceful to solve problems.

Agile methods are light and offer stable guidelines or processes that all developers can follow. Developers skilled on technologies needed in the project are often a rare ware and in this mean I find useful the categorization proposed by Boehm & Turner about developer’s targets:

• 5 - subject skilled to find solutions in unusual situations;
• 4 - subject skilled to personalize solutions to adapt them in a new situation;
• 3 - subject skilled to implement features, estimating commitment and doing code refactoring;
• 2 - subject skilled to implement simple features, testing and following given suggests;
• 1 - subject not skilled to work in a cooperative environment.

While level 1 is definitely unadapt to Agile and level 2 wastes too time for instructions, levels from 3 to 5 are useful. Higher in the rank is needed when a project is unpredictable in its path of making.

Forse il più grande impatto dei metodi agili si ha sugli Sviluppatori. I metodi agili dipendono dalla disponibilità di abilissimi sviluppatori che devono essere

• disposti a lavorare come un team,
• in grado di gestire il cambiamento continuo,
• sufficientemente intraprendenti per risolvere i problemi.

I metodi agili sono metodi molto leggeri e non offrono rigorose linee guida o processi che gli sviluppatori (anche i meno bravi) possono seguire. Gli sviluppatori qualificati sulla tecnologia da usare nel progetto sono spesso una merce rara a tal scopo trovo utile la categorizzazione che Boehm & Turner hanno fatto rispetto ad alcuni target di sviluppatori:

• 5 soggetto abile nel trovare soluzioni in situazioni inedite
• 4 soggetto abile a personalizzare soluzioni per adattarle ad una nuova situazione
• 3 soggetto abile a implementare funzionalità, stimare l’impegno e effettuare il Refactoring del codice
• 2 soggetto abile a implementare semplici funzionalità, eseguire i test e seguire le indicazioni date
• 1 soggetto non abile o non vuole lavorare in un ambiente collaborativo

Mentre il livello 1 non è assolutamente adatto all’ambiente Agile e il 2 farebbe sprecare tempo in attesa di istruzioni, i livelli dal 3 al 5 sono utili e si sale in questa classifica di livelli quanto più imprevedibile è il progetto da realizzare.

Tester

In Agile world testing needs to be done during development, so testers have to work directly in touch with developers. However if it’s applied a test-driven-development approach, typical in some Agile methods, testers role is limited cause they work before that code is realized by developers

Anyway testers need to acquire new skills and features cause they don’t have to execute classic functional testing but to design and prepare automated tests. So a new figure of tester is requested.

Nel mondo Agile il test deve essere fatto durante il ciclo di sviluppo, quindi i tester devono lavorare a stretto contatto con gli sviluppatori; tuttavia se si usa l’approccio test-driven development, tipico di alcuni metodi Agile, il ruolo dei tester è più ridotto perché essi lavorano prima che il codice sia realizzato dagli sviluppatori.

Ad ogni modo i tester hanno necessità di acquisire nuove competenze ed abilità in quanto non viene loro chiesto di eseguire dei test funzionali e di sistema ma spesso di progettare e preparare test automatizzati quindi occorrono nuove figure più adatte al ruolo di tester.

Customer

In Agile environment, customers are more involved, more frequently and with more influence. Agile recommends a constant closeness of client to the development area. To find this attitude so involved in development could be difficult and it is not enough to have a customer account cause this figure necessary has to be "committed, competent, collaborative, representative, and authorized". Until this condition of engagement isn’t realized, Agile is not a solution!

In ambiente Agile, i clienti sono molto più coinvolti, più frequentemente e con maggiore influenza. Agile raccomanda che via sia una vicinanza costante del cliente all’ambiente di sviluppo. Ma trovare questo atteggiamento, così coinvolto nello sviluppo, potrebbe essere difficile e non è sufficiente avere un rappresentante del cliente perché occorre che questa figura sia “impegnata, competente, collaborativa, rappresentativa ed sia autorizzata”. Finché non si giunge a realizzare questa condizione di ingaggio, l’Agile non è una soluzione!

Executives

If we wish that a new approach is possibly applied is primary to have the executives support. The change in the executive’s point of view is the bigger and deeper cultural shift requested in Agile. Executives:

• justify expenses and commitments if there are specifics releasing timing for some features deliverable,
• prefers advances on tasks as well as plans and schedules,
• don’t like features sizing, but request estimating that is more difficult in Agile.

The only way in which a project manager can work to build an executive trust is to convince him that Agile is faster and with higher quality in realization and benefits will be clear if he is open to a tempt in a project.

Se vogliamo che un nuovo approccio abbia possibilità di applicazione, è fondamentale che vi sia il supporto dei dirigenti. Va detto, inoltre, che il cambio del punto di vista dei dirigenti rappresenta il più ampio e profondo cambio culturale richiesto dall’Agile. I dirigenti:

• giustificano spese e impegni, se hanno date precise di rilascio relative a determinate features/deliverable,
• prediligono avanzamenti su task oltre che piani e schedulazioni.
• non amano il sizing delle features, ma anzi richiedono l’estimating che risulta difficile in Agile.

L’unica soluzione che ha un project manager di lavorare nel costruire la fiducia con quel dirigente e convincerlo che l’Agile rilascia più velocemente e con più alta qualità, e che i benefici si avranno se è disposto ad un tentativo su un progetto.

Impact on processes

Planning

Agile is characterized to proceed on planning with less formalisms. This could be embarrassing to people accustomed to prepare Gantt, collect evaluations, and make resource allocations and level off. But in my experience I find that people’s attention is instead focused on other aspects deemed more important as prioritization, breakdown of features in story, and so on.

L’Agile è caratterizzato dal procedere nel planning con minori formalismi. Questo potrà imbarazzare quelle persone che sono abituate a predisporre Gantt, raccogliere stime, fare allocazioni di risorse e livellarle, ma dalla mia esperienza rilevo che l’attenzione delle persone è invece su altre cose ritenute più importanti come la priorizzazione, la scomposizione delle feature in story, e così via.

Maybe the other aspect of planning that is often impacted in Agile is the estimate: people (even developers) must be accompanied to make a sizing or a "relative estimate", with steps or something similar. About this I have experienced that after few iterations, teams really appreciate this lean and fast approach.

Forse l’altro aspetto della pianificazione che viene spesso impattato dall’Agile è la stima: le persone (anche gli sviluppatori) devono essere accompagnate a fare un sizing ovvero una “stima relativa”, con punti o cose similari. Su questo fronte, devo riconoscere che dopo poche iteration, i team apprezzano molto questo tipo approccio snello e rapido.

On estimates, I point out that one of things that seems to inhibit people and raise skepticism, is the estimate in point through games, as Planning poker, cause people feel a fade of formalism and consider this method too unstructured or even a loose of time for the team. One of tricks that I use to mitigate this resistance is to make people think about how much time they invest in creating a Gantt (based on absolute values eg. hours, days, weeks...) and review it periodically. It turns out that people are bored and absolutely overloaded by that charge, however they deem unnecessary. So after this observation, after 1 or 2 iterations applying the estimated relative, I see that these people have embraced mechanism.

Sempre in merito alle stime, devo rilevare che uno degli aspetti che sembra interdire le persone, e far sollevare qualche scetticismo, è la stima in point attraverso i game, come il Planning poker, perché le persone vedono sfumare un formalismo e reputano che sia un metodo poco strutturato o addirittura un passa tempo per il team. Per attenuare questa resistenza, uno dei trucchi che uso è quello di far riflettere alle persone su quanto tempo investono nel realizzare un Gantt (basato su valori assoluti come ad es. ore, giorni, settimane, ..) e nel riesaminarlo periodicamente: si scopre che tali persone sono tediate e assolutamente sovraccaricate da questo onere che reputano peraltro inutile. Quindi dopo questa osservazione, applicando la stima relativa, dopo 1 o 2 iteration vedo che tali persone hanno abbracciato il meccanismo.

Project control and administrative documents production

I’m going to talk about:

1. Administrative documentation absence
2. Control data absence

1. Administrative documentation absence

Agile methods usually product few administrative documents about project status. When it comes to status project documentation, Agile use the term “barely sufficient”. This approach can feel lost manager accustomed to receive huge documents and frequently some of them consider those lean approaches as a way to not control project.

Instead, as I have explained in a recent speech for a large TLC company, that is now implementing Agile Project Manager on its IT area, these methods produce many numbers and point of views about project status, thanks to production of burn down/up chart, Kanban board, roadmap, product/iteration backlog, velocity chart …

I metodi Agile usano produrre pochissima documentazione gestionale sullo status di progetto. Quando si parla di documentazione sullo status di progetto, l’Agile usa un termine “barely sufficent” che intende “appena sufficiente”. Questo tipo di approccio può far smarrire i manager che sono abituati a ricevere documenti voluminosi, e spesso, alcuni considerano questi approcci snelli un modo per “non controllare” il progetto.

Invece, come spiegato recentemente anche in un mio recente intervento in una grande azienda di TLC che sta implementando Agile Project Manager nell’area IT, questi metodi producono moltissimi numeri e viste sullo stato di progetto grazie alla produzione di burndown/up chart, kanban board, roadmap, product/iteration backlog, velocity chart, …

Solution

One of tricks I use to teach to skeptics that this is not a problem is to show some examples of “Information radiators”. Where it’s possible to note and understand in a while the project status laying eyes over one of this boards without losing time opening and searching information in a document. A manager in a big company refers me that he is able, by his information radiator to manage immediately at phone some emergencies; in facts when someone contact him, he can manage work, give some addressed and answering about intervention timing only by looking to the board.

Uno dei trucchi che utilizzo per far comprendere agli scettici che questo non è un problema è quello di far vedere alcuni esempi di “Information radiators” dove si può notare che in un attimo, senza dover perdere tempo ad aprire un documento e capire dove si trova una certa informazione, posando lo sguardo su uno di questi board si può comprendere istantaneamente lo status di progetto. Un manager in una grande impresa, mi ha riferito che con il suo information radiator riesce a gestire al telefono istantaneamente alcune emergenze, infatti quando qualcuno lo contatta riesce a orientare e indirizzare a colpo d’occhio il lavoro e fornire delle risposte su tempi di intervento semplicemente guardando il board.

2. Control data absence

Low control feeling appears also through those skeptics that reporting to not be able to understand the finalization project if the focus concern one iteration at a time.

La sensazione di scarso controllo si manifesta anche attraverso quegli scettici che denunciano di non riuscire così a capire quando finirebbe il progetto se ci si focalizza su una sola iteration alla volta.

Solution

This feeling/issue is easy resolved explaining roles of roadmap and forecast done with “point done and remaining”

More specifically, talking about the roadmap, this scheme helps more than WBS to implement the rolling wave planning concept and follow the dynamics of the work. It uses some banal post-it to explode epic in feature, and feature in story; this offers (such as WBS) a holistic picture of doing.

Then, about forecast, just to do few easy calculus with the help of velocity and "done point". Calculating new forecast is so fast that it will definitely conveyance those who are afraid of not knowing constantly "where the project is going."

Questa sensazione/difficoltà si supera facilmente se si spiega il ruolo di una roadmap e del forecast fatto sulla base dei “point done e remaining”

Più specificatamente, parlando di roadmap, tale schema aiuta molto più di una WBS ad attuare il concetto di rolling wave planning (progressività nel dettagliare) e a seguire la dinamicità del lavoro in quanto utilizza banalmente i post-it per esplodere le epic in feature, e queste in story e offre (come la WBS) un quadro olistico del cosa fare.

Poi, in merito al forecast, basta fare due “calcoletti” con l’aiuto della velocity e dei “done point”. La velocità con cui saprete calcolare il nuovo forecast farà abbracciare sicuramente coloro che temono di non sapere costantemente “dove sta andando il progetto”.

Timeboxing impact

Some Agile methods (like Scrum) need a strong adhesion to timeboxing concept especially about iterations (known as sprint in Scrum). This concept requires that at the end of iteration team stops work respecting the status of what has been done and also, in terms of respect for a sustainable pace of work, people do not do overtime. Unfortunately there are many situations, that I had opportunity to see, in which teams make frequent two mistakes about timeboxing:

1. doing the impossible to respect the "end deadline iteration";
2. considering to close iteration after few days if they see that they cannot just close all the story provided in that iteration.

First situation can lead to disastrous consequences for the team creating a "false velocity", so in successive iterations planning meetings it will take reference to this performance! This situation, triggered by problem solver spirit, that soul generally some cultures, is easily solved after some iterations cause rapid release (duration of iteration) makes people understand that they can not live this stress every 2/3 weeks . However, the project manager must take swift action to bring team to a regular rhythm, because the "race" to beat time inevitably leads to a poor quality and, if Agile is being introduced in the company, could be a boomerang because the customer will sees poor achievements and team will loses confidence in the approach.

The second situation leads to velocity distortion because “points done" refer to iteration that are variable in length. I must say that if it is not exceeded this rigidity to close the iteration in provided intervals it’s possible to mitigate reading velocity problem, calculating "points done" on a weekly basis, and not in reference to iteration.

Alcuni metodi Agile (come Scrum) richedono una forte adesione al concetto di timeboxing, soprattutto per quel che riguarda le iteration (note in scrum come sprint). Tale concetto richiede che alla fine dell’iteration, il team si fermi rispettando lo status di quanto fatto e inoltre, in termini di rispetto di un ritmo sostenibile di lavoro, le persone non facciano straordinario. Purtroppo, molte sono le situazioni che ho avuto occasione di vedere, in cui i team fanno 2 errori usuali in merito al timeboxing:

1. fanno l’impossibile per rispettare la “scadenza di fine iteration”,
2. considerano di chiudere l’iteration dopo qualche giorno se vedono che non riescono a chiudere proprio tutte le story previste nell’iteration.

La prima situazione può portare conseguenze disastrose per il team perché “falsa la velocity” per cui nelle iteration planning meeting successive si prenderà a riferimento questa performance!! Questa situazione, innescata dallo spirito di problem solver, che anima generalmente alcune culture, si risolve facilmente dopo qualche iteration in quanto le rapidità di rilascio (durata delle iteration) fa comprendere alle persone che non possono vivere questa situazione di stress ogni 2/3 settimane. Tuttavia il project manager deve intervenire rapidamente, per portare il team ad un ritmo regolare perché la “corsa” per battere i tempi porta inevitabilmente a una scarsa qualità e, se l’Agile è in via di introduzione in azienda, potrebbe rappresentare un boomerang perché il cliente vede realizzazioni scadenti e il team perde fiducia nell’approccio.

Anche la seconda situazione porta a falsare la velocity perché i “punti fatti” sono riferiti a iteration che sono variabili nella lunghezza. Devo dire che se non si supera questa rigidità a chiudere l’iteration nella periodicità prevista si può mitigare la il problema della lettura della velocity, facendo i calcoli dei “punti fatti” su base settimanale e non in riferimento alla iteration.

Conclusions

Agile requires a bigger consideration about relationship inside team and with stakeholder, acting more trust and patience, and helping to understand the best of the new approach.

As in many life’s situations others will follow if you proven expertise in what you propose, passion in the way of presenting the changes and conviction about the things presented.

L'Agile richiede che si abbia maggiore considerazione delle relazioni con il team esponendo maggiore fiducia e pazienza, e con tutti gli stakeholder di progetto aiutandoli a comprendere i vantaggi del nuovo approccio.

In tutti i casi, come in tante situazioni della vita, gli altri vi seguiranno se dimostrate competenza su quello che proponete, passione nel modo di presentare i cambiamenti e convinzione circa le cose che presentate.

Biography

I am a senior project and program management consultant with 20 years of experience in managing a variety of projects. Some of my significant achievement include support for planning and monitoring of "Great Jubilee of 2000" programme in Rome (Italy).

With my expertise in Project Management and over a 15 years of experience as teacher and coach, I have discovered, assimilated and accumulated many project successes and failures.

Antonio Marino, PMP, PMI-ACP
Senior manager

www.actpoint.it

Photo: Google image