A lean approach to portfolio definition

When adopting agile as a product development methodology, the organizations wouldn’t forget to manage their portfolios accordingly.

It happens frequently that when organizations want to adopt agile, they think it’s only a matter of introducing just one more new methodology in the “assembly line”. They wrongly imagine that it’s only a matter of having the teams doing new things or, either, performing the old ones, better and more efficiently.

What they usually lose, is that introducing agile means to be ready to change organizational habits, behaviours, rules, policies, processes, tools, etc.

The portfolio management is one of the practices that should change.

Ok, let’s imagine you must arrange a portfolio of three different but inter-connected products, which will be developed using agile methodologies. You should have a first raw list of the main features each product should have (EPICS).

Then, You should arrange a workshop in which the most important stakeholders should attend: product managers, program & project managers, CEO, etc.

Be sure you will have post-its of different dimensions and paper tapes available and a large wall where to stick them: you will make great use of some visual management techniques.

Start the meeting, deciding the time-frame within which the products should be deployed.

Then, write the name of the products involved on the Y axis.

Now it’s time to ask the first product manager (or ProductOwner in SCRUM) to write each feature of the product on one post-it and hang it to the wall, positioning it on the timeline where it is supposed the feature must be available. This first chronological prioritization, must be done according to the business value each feature is supposed to bring to the organization.

Then it’s the turn of the second product manager.

Finally, the third product manager does the same.

Now it’s time to analyze and verify the interconnections between the products, asking the three product managers and the other stakeholders, to recognize and highlight any dependencies. This is one of the most important moment: the dependencies, indeed, can be conditioned by several factors: technical, tactical, financial or business ones; thus, choosing the right attendees for this meeting is paramount. It happens that during this phase new features arise.

According to the dependencies just drawn, the attendees must reason on how to reconcile every concern and necessity, by moving the features anticipating or delaying their availability.

Once the reconciliation above is finished, it’s time to analyze risks and impediments. This is a brainstorming session: each person writes on a post-it a risk or an impediment and stick it apart from the portfolio chart just defined.

The facilitator, arranges the items by category, clustering them, remove the duplicates and when the list is consolidated, asks the attendees to sort them by importance. Then, s/he assignes an identification number to each.

The facilitator, then, asks the audience about the impact of each impediment against the portfolio in terms of features, dependencies  or even months and/or products.

The workshop is almost finished. Now it’s time to collect the features and the related attributes (sequence, dependencies, dates, impediment references), into the product backlogs and the impediments list.

More reading here (see the book list page):

• Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum Craig Larman – Bas Vodde
• Scaling Software Agility: best practices for large enterprises, Dean Leffingwell
• Lean-Agile Software Development: Achieving Enterpise Agility Alan Shalloway, James R. Trott, Guy Beaver Net Objective Lean Agile series

Be good

Video of my talk at PMI-NIC Agile Project Management Event

This is the video of the talk I held December the 2nd in Milan at the Agile Project Management, regarding the product owner and how to adjust a bit his duties and responsibilities in order to create bridges between the traditional and the agile way of conducting projects (PMI-NIC Agile Project Management, Lightning talk at APM: Beyond SW Development (PMI-NIC))

PMI-NIC Agile Project Management

• deliver value to the customer in a steady pace
• involving as much as possible the customer with agile
• adopting the communication style to and supplying project progress data the customer wants (adopting the “barely sufficient approach” Alistair Cockburn suggests)

Lightning talk at APM: Beyond SW Development (PMI-NIC)

December the 2nd, the PMI Northern Italy Chapter has organized an interesting event “Agile Project Management: Beyond the software development”.

In that occasion, me and other four associates have the occasion to present a brief talk regarding our past experiences.
The talk I’m going to present is about the Product owner role in SCRUM as a “zipper-man” (or superman?).

Let’s meet there, in Milan Corso Venezia 47!

Acting as a zipper: here is the Product Owner.

The product owner (PO) in SCRUM, is one of the most crucial figure of the stakeholders community formed around a SCRUM project.

His role is to behave as an interface primarily between the team and the management, adapting the behaviour, the ledership style, the way he communicates time at a time, in relation to which he is confronting with.
He should master the communication and negotiation techniques, he should also know how to manage politics and take advantage from it.

On the other side, the Scrum Master is mainly a coach, a mentor, somehow it could be tought as a wise father in charge to give the team support and guidance. He must have strong communication skill as well and he should be an active listener and  a servant leader, protecting the team and creating a favorable workplace.

The PO is even more important when the client organization is not part of the one that is creating the product and, moreover, if it is not familiar with the agile practices and concepts.

It happens in these cases that the client organization is also particulary fond of the traditional way of conducting and controlling projects and it doesn’t want to change the way it works.
The PO, hence, must actively keep the client informed by sending at a regular basis, fresh information about project’s progress, using the same “project language” of the customer: gantt, Earned Value analysis, etc.

It is obviously auspicable, looking from the agile perspective, that the client participates at least to the Demo/Reiew meeting that the team holds every end-iteration, showing the actual progress in term of what was developed so far and that is ready to go live.

SCRUM and XP as well, indeed, prescribe the practice of “customer-on-site” that means the client is strongly involved in and engaged with the team, in the same workplace, during the entire lifecycle of the project. This could be challenging, but it brings lot of advantages that are mostly related with the fact of establishing short lines of communication that drives to short feedback between the team and the customer, avoiding misunderstandings and shortening the time necessary for decision making.

One last advantage is that the customer itself is able to see how the project is progressing, looking at the Task Board, the sprint and release Burndown Chart, the Impediment Log.

But, as we assumed initially for the sake of this example, our customer doesn’t want to be so much involved and engaged, he is not interested in any agile practices or knowledge, he only wants the product he asked for within the time, cost and quality decided and, finally, he wants to receive punctual updates about project’s progress

In short,a real nightmare for a pure agilist :\
Someone said me that in these case s/he refuses the job.

My opinion is that even in these cases, we should be adaptive and responsive to the situation, by adapting our style to the customer’s one, using the Product Owner (internal in this case) as a zipper, a tradeoff figure, an active interface between the traditional project management style of the customer and the agile approach of the internal team.

Let’s assume we choose the second case.
First of all, I suggest to the PO to try continuosly to engage as much as possibile the customer.

The first duty that the PO must assolve, is to gather the requirements and write the user stories. During the meetings he will held with the customer for that, he should find the way to give some “agile” pills to the patient: talking about the ceremonies (planning, daily, demo and retrospective meetings), the artifacts (product, release and sprint backlog, burndown charts, impediment backlog), the roles and, why not, the rules of SCRUM.

Another important thing the PO should do during the gathering requirements meetings, is to collect all the functionalities the customer wants, initially without a great extent of detail and to ask the customer to prioritize them, understanding the real business value the customer assignes (see this previous post).

The most important requirements, those with an high prority, must be “decomposed” into user stories, the other less important requirements will be put into the product backlog as they are, without exploring them too much in this first moment.
This because those requirement will be analyzed only after the first versions of the product are available, giving the customer the opportunity to change his mind, introducing something else or, even, cancelling such requirements because he already achieved the ROI.

Then, the PO, should try to bring the customer at the “war room“, the place where the team is working, to let him to be part of the “flow” even if for few moments.

In this occasion the Scrum Master must be present as well, behaving as a Cicerone explaining how and why the workplace is arranged that way, how the data reported on the information radiators can be interpreted, how the team works and why such a high level of involvement is so important.

Another important step of persuasion the PO should try, is to insist to have a customer representation present during the demo meeting, inviting him or asking to delegate someone else, to participate the demo/review meeting, to see how the product is evolving.

In these situations, indeed, I prefer to set short iteration lenght, because the fact that the client is not so involved and passionate, increases the risks and the probability of misunderstanding. Having the possibility to release frequently, on production, small chunks of working software, helps to prevent it.

The PO, then, must interact proactively with the team acting as the customer, giving opinions, guidance and solving problems about what and how the product should be and work.

And finally, the last great effort the PO has to do, is to keep informed the customer at a regular basis with the progress status of the product, by transforming the information spread around the several information radiators, into the documents the customer really wants: the WBS, the Gantt Chart, the Earned Value Analysis.

Creating the WBS is somehow simple because it is mainly a hierarchical structure of the work that must be done, dividing it into nodes, sub-nodes and leaves that must be arranged by deliverables. The term deliverable means a piece of finished functioning work, that can be released to the customer in order to be evaluated and eventually put on production. This, for an agilist, sounds good because the equation could be deliverable = iteration or in the worst case deliverable = release.

The WBS hence could be arranged by reporting the releases, the iterations for each release and finally which stories the team is going to implement for each iteration.

Actually, this is only the first step the PO should do to keep aligned a recalcitrant customer with the progress of an agile project, by creating traditional project management documentation. The other steps are create a Gantt chart from a SCRUM Task Board and produce a status and forecast report about the perfomance of the project, by relating the burndown chart data, the velocity, the iterations planned into a fantastic Earned Value Analysis.

I’ll try to cover also these two last point (the tough ones actually) in some future posts. Keep in touch!

Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

1. Maximize and accelerate the ROI
2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

• Remove any impediments
• Give answers and explanations to any doubts or open points
• Deepen, if necessary, user stories that are not clear
• Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

SCRUM (2^ parte)

Ecco la seconda parte della saga “SCRUM”.

Avevamo iniziato qui (http://www.emilianosoldipmp.info/2010/11/08/scrum-1-parte/) parlando in generale di SCRUM e di una delle sue componenti principali: gli artefatti.
Oggi parleremo di altre due componenti: time boxes e ruoli.

Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.

This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

SCRUM (1^ parte)

In un post precedente, raccontavo di come poter conciliare realtà aziendali lontane da un modello di business prevalentemente orientato ai progetti (matrice debole), con le tematiche agili, tanto in voga in questi periodi.
Questo è il primo post di una piccola serie, in cui fornisco indicazioni rispetto a SCRUM: uno dei più utilizzati framework agili.  

• Perché non esiste un’analisi dettagliata del lavoro da eseguire
• Perché è necessario fornire al più presto al committente, valore di business, anche parziale, attraverso il prodotto rilasciato
• Perché i change di progetto potrebbero essere frequenti in rapporto alla volatilità del mercato di riferimento in cui si opera
• Perché la tecnologia utilizzata è innovativa o poco sperimentata
• Perché i rischi sono molto alti
• Perché è necessario ricevere feedback dagli utenti con buona frequenza

Ti ritrovi in qulcuno dei punti sopraccitati?  

Bene!  SCRUM potrebbe aiutarti a trovare le risposte giuste…SEGUIMIIIIIII!!  

Come funziona?

SCRUM suddivide il lavoro in tempi precisi, dà loro il nome di sprint e identifica una durata media di 2/4 settimane ognuno.  

Quando terminato, lo sprint permette di rilasciare in produzione un “pezzo di prodotto” funzionante, sin da subito utilizzabile dal committente.  Identifica ruoli che hanno perimetri di responsabilità ben definiti, chiari a tutti e regolamentati.

 Non necessita di analisi e piani di progetto “ultra-dettagliatissimi“. Solitamente SCRUM dedica a tali attività solo il 20% del tempo impiegato dalla normale attività di project management. 

Solo lo sprint corrente si giova di analisi sufficientemente approfondite, cosa non obbligatoria per i successivi sprint.
Questi ultimi, infatti, verranno particolareggiati quando arriverà il loro turno.  

Prevede infine, regole ben definite che scandiscono rapporti, tempistiche, modalità e strumenti, permettendo agli appartenenti al team, di essere efficienti, efficaci, focalizzati.  

Quali i principi ispiratori?

I principi ispiratori sono ovviamente mutuati dal manifesto agile. 

1. Soddisfare le esigenze del cliente
2. Accettazione dei change di progetto come normali accadimenti
3. Rilasciare prodotti funzionanti, anche parziali, frequentemente
4. Far lavorare a strettissimo contatto i tecnici, gli ingegneri e le persone più vicine al business
5. Puntare all’eccellenza tecnica, di design e di qualità
6. Essere motivati e motivare il team
7. Preferire comunicazioni dirette (face-to-face)
8. Ritmi lavorativi sostenibili
9. Semplicità a 360°
10. Retrospezione dell’operato

Cos’è esattamente SCRUM

SCRUM è un framework che permette il governo agile dei progetti. Riguarda essenzialmente il processo, gli strumenti, le persone, le modalità; non detta leggi inerenti le tecnicalità o le modalità in cui svolgere il lavoro che produce il prodotto, bensì ne governa l’avanzamento.  

E’ un approccio facilmente adattabile a progetti software, ma portabile anche a progetti di tipo hardware, marketing, operation (solo per citare alcuni esempi).  

Sono diverse le dimensioni dello SCRUM:  

• Strumenti e artefatti (Artifacts)
• Tempistiche precise (Time boxes)
• Ruoli (Roles)
• Regole (Rules)

Artifacts

SCRUM Backlogs

Product Backlog

E’ il registro delle funzionalità necessarie, ordinate per importanza.  

Il Product Owner è il responsabile unico di tale registro.  

Egli, con l’aiuto degli altri stakeholder, comincia con la compilazione delle user stories: casi d’uso dell’applicazione descritte per singola tipologia d’utente.  

Dalle user stories vengono derivate le diverse funzionalità che le compongono e queste vengono elencate.  

In base alle priorità dello sponsor/committente, ai rischi identificati, al grado di dettaglio disponibile, alle funzionalità vengono assegnate priorità.  

E’ proprio da quelle in cima a quella lista che si comincerà a lavorare.  

Release Backlog

E’ un sottoinsieme del product backlog: identifica le funzionalità da implementare, raggruppate per versioni di prodotto che verranno rilasciate in produzione.  

Sprint Backlog

Rappresenta l’insieme delle funzionalità in ordine di priorità, che dovranno essere implementate nello sprint corrente.  

Queste vengono analizzate, scomposte in task, stimate dal team e prese in carico dai singoli componenti.  

Burndown chart

Burndown Chart

E’ un grafico che rappresenta il totale del lavoro mancante (ore o punti) suddiviso per giorno.  

Via via che il team evaderà lavoro, il trend della linea sarà discendente. E’ una rappresentazione che restituisce immediatezza rispetto alla resa e alle performance del team.  

Impediments Backlog

Lista degli impedimenti o dei problemi identificati, che risultano essere ostacoli al libero svolgimento del lavoro.  

Tale registro è gestito dallo Scrum Master, il quale dovrebbe affrontare e risolvere, nella teoria, i problemi emersi entro 24h dalla loro nascita.  

Bene per questa sera può bastare….nel prossimo post ripartiamo da qui: time boxes, ruoli e regole. 

Have a nice evening