Where is the driver? The importance of a Product Owner in an Agile Software Development Team

By using Agile Development teams can achieve impressive levels of productivity. However, no matter how fast your car could be if you don’t have a place to go.
Agile teams depends on the information and the clear guidance provided by Real Customer Involvement.

Traditionally, waterfall oriented organizations fail to adopt agility because they contract software development the same way as they buy things. The requirements are drawn up, a supplier quotes a price (based on their interpretation of the requirements and estimates of cost) and everyone signs a legally binding agreement.
The fact is that right after this agreement everyone argues about what is actually in scope, what is out of scope, and what constitutes a change request to the contract. The customer gets some hours of software development effort, the supplier gets some money, and everyone is unhappy.

But...

This is collaborative game!

Real Customer involvement drives the team to understand what is to be build.

The first step to have what you want is to know what you want.

But sometimes (most of the times) the development of a new product has a lot of unknowns and uncertainties. That’s right. And an agile framework provides an excellent alternative for this environment.
Scrum, for example, proposes the role of “Product Owner”. The Product Owner (PO) is the responsible for the Return of Investment of the project. He/She is in charge of collaborating with the team to explain what the stakeholders want, what they need, what they are willing to pay. The PO has to answer the question of “What Problems Will the Project Address?” and uses User Stories to get the problem and to make sure he captures the stakeholder type in the comments.
We use the User Story format “As a , I need to so that ” in order to force the discussion on what the stakeholder is trying to achieve and the costs of the business problems.
“I don’t know what is supposed the system to do.” Well, start small. The iterative nature of agility gives you a perfect fit to manage risks until you decide with more information available. In the meantime, collect the information from the stakeholders, the PO must capture both functional and non-functional requirements but most important, he/she needs to prioritize the User Stories in order to maximize the Return of Investment of the project.

In a framework that is business driven, the product owner is a must, it is not optional. You might have the best development team with a great Scrum Master, but if the Product Owner fails, all the project will fail too.
If you want to take the benefits of Agile, be prepared to collaborate, be prepare to trust, be prepared to continuously working with your team abandoning the “buying things” model. Software Development is a creative process that demands intellectual investment, adaptation, collaboration, guidance and require the active stakeholder participation.
Be prepared for driving your project to success.

Warning: Scrum can cause pain

The model proposed by Scrum is so simple that bottom-up feedback is immediate and many times could cause some pain. The Stand-up daily meetings (A.K.A. Scrum meetings) expose to the organization the productivity impediments and organizational inefficiencies. The intention of this outstanding almost real-time feedback is to allow the organization to correct and remove impediments in a record time.

Smart managers will use this information for re-engineering processes and correct organizational defects while identifying the possibilities to improve in a continuous identification framework.

Some impediments that may appear not to be obvious are:

• Workers that need training in the technology (blockers under-estimated)
• Unclear Priorities in the Backlog
• Team members are assigned and committed to other tasks
• Inadequate design
• Lack of commitment and team participation

However, not everybody is prepared to deal with this pain. While some managers can take this as a huge opportunity to improve and excellence, others can be afraid and be resistive and blind over the evidence and express: "Just tell me when will be done" , "This Scrum thing is not for us, our culture is different" (sic)

Some organizations prefer to be less than efficient while they are comfortable due to their margins due to the unique products in the market niche they are. They have the waste of abusing of excessive meetings, organizations based on hierarchies, excessive management and incompetence.

But this is a fast world. The market will ensure that agile companies with new technology or more efficient organizations just defeat the inefficient ones.

Source: Agile Ways Consulting Group

The Agile Way..

I am very happy to announce my new company web site:

Agile Ways Consulting Group

Little by little I'll be posting new articles and blog's entries there.

The objective of Agile Ways is to provide advice and help to companies that need to profit in an agile world. By the way, the first article here.

Open Agile Cordoba 2009 - Satisfacción Agil

Fué un placer compartir dos días en Agile Open Cordoba 2009. Hace pocos meses empezamos con la idea y con la colaboración de empresas locales (Intel, Xarae) y de compañías que ayudan a esta nueva forma de trabajar (Baufest, Sabre Holdings) pudimos realizar este evento que ha tenido una concurrencia muy grande, sobre todo considerando que fue el primer evento.
Pero lo más importante fué la gente. Vinieron de diferentes empresas, ámbitos y de diferentes industrias. Todos ávidos de conocer de qué se trata Agile o de compartir su experiencia. Si hasta se llegaron de países vecinos (Chile, Bolivia) de por supuesto de Provincias hermanas (Corrientes, Bs. As.).
Las sesiones fueron realmente aprovechadas, me hubiese gustado estar en más de una a la vez, pero los temas eran tan interesantes que costaba decidir a cuál asistir.
Hablamos de Planificación y Estimación agil, contratos ágiles, juegos, introducciones, etc. pero lo que más me llamó la atención fueron las ganas de las personas de cambiar hacia un nuevo paradigma de trabajo que nos permita realizarnos como mejores seres humanos. Nadie obliga a chicos de 20ypico estar un Sábado investigando y profundizando cómo ser un mejor profesional, sin embargo, ellos estaban allí... Esta gente es el motor del cambio en cada una de las empresas y en nuestra sociedad.
Dimos el primer paso hacia una comunidad ágil en Córdoba. Gracias a todos por haber compartido esta experiencia conmigo.

Por cierto, tremenda la buena onda de la gente de IES21 :-)

Se viene Open Agile Córdoba 2009

El próximo viernes se realizarán en el IES las jornadas abiertas Open Agile Córdoba 2009.

Es un paso para la comunidad ágil en Córdoba dado que nos reunimos muchos de los agilistas de Córdoba para organizar estas jornadas que son parte de la difusión que estamos realizando a nivel nacional (Argentina Open Tour) en la Comunidad Latinoamericana de Metodologías Ágiles.

El formato Open Space es óptimo para poder sacar provecho de la experiencia en distintas empresas a nivel local que están transicionando hacia Agile como nueva forma de hacer negocios en un entorno cambiante y agresivo.

Los espero el Viernes y el Sábado. Gracias a los sponsors (Intel, Sabre, Baufest, IES, Xarae, Sadio) vamos a poder atenderlos con un pic-nic ágil :-)

You cannot multi-task

One common issue among my clients in different industries is the fact that they manage multiple responsabilities and tasks in a multi-task fashion driven by interruptions.

Multi-tasking is a productivity killer. I has been demonstrated that when you are interrupted, the same task takes up to four times longer to be completed compared to the same taks with no interruptions.

The next immediate effect is the amount of errors introduced when you´re interrupted, being 3-4 times more when switching tasks and when you´re managing numbers and 4+ times errors when you manage words.

While keeping a cellular phone conversation in the car is worse than driving drunk (based on statistics), the same occurs in the office. To be on-line, chat enabled, trying to get things done but switching contexts contantly is a very bad idea.

Boosting productivity

Applying the simple agile principle of prioritization scrum teams assigned to multiple projects and driven by interruptions can deal with this. By defining in the planning day the context and the allowed switch for the day, the team can limit the interruptions and boost the ideal hours of productivity.

Using the context concept from David Allen´s GTD productivty system, team members can distribute their days like:

@Project B (Morning)

@Project C (Afternoon)

@Project A (COB)

Of course this requires the management commitment and a do-not-disturb policy across the organization. Managers can be interrupted, but team members should be able to manage their time in order to boost productivity.

You cannot multi-task. By dividing the day in smaller chunks with less interruptions your productivity as team member is going to be increased dramatically and you are not going to get stuck in the middle of non-productivity.

Decide as Late as Possible

After years of Agile Development I am now positive that no matter how well the development team implemented Agile practices, how well they run their iterations, improve their velocity, how sophisticated is the set of test automation if the organization is still driving business in an old-fashioned fixed price way. 

I have observed the auto-destructive behavior of making commitment per contract when information is the worst possible in the software product development cycle. Developers are pushed to provide estimates (assign probabilities) and these probabilities are written and signed in a contract, with no clues about what the customer really wants or what is to be developed. That's what Mary Poppendieck compares with get married with a woman you just know for a couple of hours.

Homer and Ned Flanders went to the casino's bar and get drunk in the "Viva Ned Flanders" episode, waking up the next morning in their hotel room and married to two cocktail waitresses: Homer's new wife is named Amber, and Ned's new wife is Ginger (who have video evidence of the two men marrying them while drunk). That's a funny episode but it is tough when you receive a project with impossible fixed dates and unknown scope.

Lean Development has an answer for that and there is a solution I suggest to my customers. Decide as Late as Possible and use Agile Contracts. Of course it is not a simple change. Simply some managers feel more confident when they have some linear (impossible) schedule in fornt of them. Well, this is the news:

* Making predictions DOES NOT make you predictable

Taking risks and commitments when information is scarce, in the beginning of the "cone of uncertainty" is simply a bad decision. Agile contracts suggest to share the risks until the cone starts to close, and commitments can take with more probability of occurence. Of course, this require long hours educating the customers and get a collaborative environment that allow working together.