ScrumCordoba

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

noreply@blogger.com (Fabio) — Sun, 24 Apr 2011 01:52:00 +0000

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

noreply@blogger.com (Fabio) — Mon, 11 May 2009 22:52:00 +0000

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..

noreply@blogger.com (Fabio) — Wed, 06 May 2009 23:04:00 +0000

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

noreply@blogger.com (Fabio) — Sun, 19 Apr 2009 21:59:00 +0000

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

noreply@blogger.com (Fabio) — Fri, 10 Apr 2009 22:23:00 +0000

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

noreply@blogger.com (Fabio) — Fri, 10 Apr 2009 14:12:00 +0000

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

noreply@blogger.com (Fabio) — Sun, 01 Feb 2009 22:10:00 +0000

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.

El Agile en tiempos de Crisis (Agile in the time of Crisis)

noreply@blogger.com (Fabio) — Sat, 31 Jan 2009 20:01:00 +0000

Global crisis is for real. In 2009 most of the companies are planning for mitigate the impact of the global crisis and organizing resources for overcome the year with the less damage as possible.

Should they think in change? Of course they do.

The crisis is the opportunity to stick to lean development principles and adopt agile practices for optimizing the returned value of their investments.

1. Eliminate Waste

2. Amplify Learning

3. Decide as Late as Possible

4. Deliver as Fast as Possible

5. Empower the Team

6. Build integrity in

7. See the whole

aren't them great principles? certainly they are. Even more they need to be applied in a critical environment.

If any Crisis is an opportunity, certainly this year is the opportunity for companies to become agile. But the first step is to know and adhere to these seven principles, companies must understand that Principles conduct to Practices and if organizations adopt isolated Practices (agile practices) without a deep understanding of lean principles, simply it is not going to work.

Redefining "Distance" in a distributed Scrum team

noreply@blogger.com (Fabio) — Sat, 22 Mar 2008 15:51:00 +0000

While most of the bibliography about Scrum implementations address the challenge of having a distributed or a dispersed team with a strong advisory "WARNING - Do not use Agile in distributed teams, simply it does not work" , many of us have to deal with the reality of implementing agile in a distributed environment. I do not even know about any company that has not distributed issues:

Distributed customers

Distributed assets

Distributed knowledge

Distributed personnel

Then we cannot heed the fact of distribution of problems.

Then I would like to re-define the "Distance" concept used in Scrum teams. The fact that a Scrum team is in the same room, plenty of blackboards and little yellow papers does not mean that necessarily that the team is within a short distance. There are some other variables which must be analyzed as different forms of "separation".
There is an excellent article written by John Puopolo in the Scrum Alliance site: "Be there or be Square" that states most of these dimensions. One common conclusion is that it is impossible to be agile if you are separated. I would like to re-analyze this concept by redefining the Distance in Scrum concept:

Distance_in_Scrum = Multi-dimensional variable measured between different forms of separations:

A = Customer distance

B = Geographical separations

C = Business/Technology separations

D = Separations in Time and Chronobiology separations

E = Skills separations

F = Cultural separations

G = Organizational distances

Distance in Scrum Teams = f(A, B, C, D, E, F, G)

Multivariable Analysis

I would like to decompose the analysis of each variable in further blog's entries. From a systems point of view, each variable here represents a challenge in itself.

Many companies make the mistake of believing in Communication Technology as Distance Remedy, while the Dislocated communication media, can alleviate the problem, E-mail, Chat, Wiki sites, Phone calls, Phone meetings are of course less effective than the communication taking in-person. I have seen people seated at 2 meters of physical distance that do not communicate each other for weeks (working in the same project!)

Chronobiology is also another important topic I want to analyze. Global teams must understand the West-East effect of the Circadian Rhythm when time zones are really different, but also the longer cycle that derive from the North-South effect of being here in summer in Argentina when my colleagues are suffering a cold winter (!). There is no much research on that and I'm sure it impact on the global team performance.

Next entry I am going to analyze the chronobiology impact in Scrum teams distance.

Ventajas Competitivas en la Industria del Software en Córdoba.

noreply@blogger.com (Fabio) — Sun, 16 Mar 2008 15:32:00 +0000

Esta entradad del blog está en Español dado que este tema es un problema doméstico. Es como el problema que nos afecta a todos los Cordobeses, Talleres y su pésima campaña 2008...

Hoy en la edición del Domingo de La Voz del Interior aparece el Ministro Tulio Abel Del Bono (Ministro de Ciencia y Tecnología de Córdoba) con una nota que dice "Mejora de la competitividad en el sector productivo cordobés".
Sin dudas, Del Bono es una persona inteligente, la nota es clara y establece el nuevo paradigma del conocimiento como variable y Ventaja Competitiva fundamental y la innovación productiva como VC indispensable para competir con diferenciación.

Quisiera analizar la nota desde el punto de vista de la Industria del Software arraigada en Córdoba y revolucionada desde el 2001 hasta la fecha.

La primera contradicción que encuentro es la misma Ley de Promoción Software (Ley 25922).

En primer lugar quisiera dejar claro que la ley es muy buena en todos los aspectos y que es muy encomendable el esfuerzo realizado por la gente que luchó tantos años para poder tenerla, esta perspectiva no es una crítica destructiva, sino una oportunidad de mejora detectada a la Ley.

Inmendiatamente despues se hace evidente que la ley obliga a las empresas a contar con una "Certificación de calidad" de producto o servicio. Cuando investigamos un poco más sobre la Ley, nos encontramos que los modelos "reconocidos" son CMM, CMMI e ISO.

En la Industria del Software -quizás más que en cualquier otra área- los trabajadores del conocimiento son los verdaderos poseedores de la capacidad de las empresas. En el famoso "iron triangle" formado por Personas, Procesos y Herramientas, es evidente que el conocimiento está en las Personas y el manejo de conocimiento basado en mejora de Procesos y Herramientas ha traído hasta ahora resultados frustrantes.

Hablo con conocimiento de causa. He participado activamente de 4 assessments de CMM, CMMI, auditorías ISO, Engineering Process Groups, etc. Mi conclusión es simple:

Los modelos tradicionales basan la gestión de conocimiento en mejora de procesos, ignorando el talento de las personas como motor indispensable de la innovación.

La innovación productiva es dinámica. Depende de los Ingenieros y Técnicos que con imaginación, talento y sacrificio resuelven complejos problemas. Los procesos son el soporte de ese trabajo y son fotos estáticas de resolver un problema en forma similar al anterior.

En síntesis, El Régimen de Promoción de Software está impactando negativamente la Innovación Productiva en nuestra industria. El modelo de promoción eventualmente puede ser útil en industrias en donde los productos son tangibles y las máquinas en conjunto con procesos definidos solucionan el problema de la producción en serie.

Hay una nueva generación de trabajadores del conocimiento en Córdoba que están habilitados a trabajar en entornos cross-culturales y globales, con la única infraestructura de una Laptop y acceso a la red.
En este contexto los clusters no hacen la diferencia.

Si podemos rescatar un factor de éxito en la innovación tecnológica, es el aspecto cultural del Cordobés que le permite adpatarse a multiples entornos y resolver problemas en forma imaginativa. Nuestras empresas nunca podrán aportar la innovación productiva necesaria y mucho menos si tienen una ley de promoción que promueva la inproductividad.

γνωθι σεαυτόν - Know thyself

noreply@blogger.com (Fabio) — Sat, 01 Mar 2008 21:04:00 +0000

There is an ancient Greek aphorism that says: "Gnothi Seauton" (Know yourself). By ultimately understanding oneself is key for understanding what are our capabilities, our potential and understanding others as well.
Organizations are like humans too. There is a great book that states that every company has its own personality and according to its personality the organization is going to react in different environments.
(Companies are people, too. Discover, develop and Grow your Organization's true personality - Sandra Fekete with LeeAnna Keith)

Today I am analyzing how one organization manage multiple projects. Not surprisingly, I have noticed that while some organization appears to be reluctant to struggle among multiple projects, others are so eager to take advantage of the opportunities that many times losses all.

Probably one of the scariest but more benefitial effects on the upper management when the organization adopts a transparent, reliable Scrum framework is that the real organization capability is exposed. That means that all the stakeholders are now aware of the organization abilities, capabilities and bandwidth to absorb projects at the same time.

Where the limit is? - The overblown juggler analogy

One Juggler can deal with multiple balls according to his/her juggling skills, training, concentration, environment, etc. Multiple factors affect the amount of balls that one juggler can deal with.

Organizations are like humans too. And some organizations have to deal with multiple projects like a juggler.

The juggler does know his limitation, can be 3, 4, 5... 20, whatever number it is, there is a limit while juggling.

The concequences of jugging with more balls than possible have only a simple output: none ball in the air, all balls dropped.

Organizations might sadly discover this limit when they figure out that the delta added value to every project in paralel is not enough for getting anything done at all.

Here is the importance for every organization to create a healthy product porfolio. The same as stories, product must have a PRIORITY and organizations must understand their value, cost, knowledge point and risks in every case for treat them properly.

If the organization accept more work than its capabilities permit, then is going to suffer the overblown juggler effect: projects dropped, nothing at hand.