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!

#agilebs Agile Tour 2011

In may I participated to the Agile Coach Camp Italy 2011.

One of the last things we made before the camp was definitely closed at Agile Coach Camp 2011, was to write a letter to ourselves.
The facilitator said that in that letter we would had written something that we experienced, felt, thought, during the camp and which we would have loved to receive in the future.
He said also that that letter was a “magic letter” that it would come to us in the right moment, in the future, to help us remembering and continue pursuing our objectives and desires towards agile implementation.

Yesterday that letter came back to me again and surprisingly it was cool to verify that most of the wishes I did to myself at that time, are all almost realized.
The first advice, the most important, contained an invitation to myself to continuosly share my knowledge giving to the agile community what I received and learned, at least with the same enthusiasm the other participants of the camp put during all the three days.

Actually this morning I participated to the AgileTour 2011 in Brescia and I had the opportunity to give two different talks: the opening talk about agile and a more detailed one regarding SCRUM.

Even in this occasion, the conference was organized by some “brave”guys, belonging to a non-profit community (WebdeBS) having two important things in common: the passion for agile and lean and the desire to share them with the others.
The conference was amazing and it was very interesting to see how many participants were completely involved in and engaged with what we were sayng.
Really a nice event

Thanks guys  @__ce @carloz @cirpo @bauno @albertobarrila @odracci @AgileBrescia #agilebs #webdebs!

AgileTour 2011 Brescia

October the 15th I’m participating to the AgileTour 2011 in Brescia.

I’m keeping the opening speach and I will facilitate a SCRUM session.

Let’s see in Brescia!