Los resultados de la encuesta online (nuevo servicio de Linkedin, ojo no me pagaron por esa mención), han votado 2771 usuarios, supongo que todos miembros del grupo The Project Manager Network, la pregunta exacta es: Is PMP certification becoming more or less important for project managers?

Está bastante parejo el resultados, contrario a lo que se podría pensar, un 57% lo encuentra importante y un 43% menos importante.  Digo que sorprende ya que en un grupo como ese la mayoría a favor de la certificación sería bastante más abrumadora.

Al revisar los comentarios surgen básicamente dos ideas fuerza asociadas a cada posición

• A Favor, la certificación PMP (Project Management Professional) es un must que todo gerente de proyecto debe tener si quiere ascender en su carrera gestionando proyectos cada vez más importantes, y por lo tanto debe enfocarse en obtener la referida certificación, como un prerequisito para aquello.

• En contra, que básicamente se trata de un negocio del PMI, ya que por un curso de aproximadamente 1.500 dólares, más el costo del examen y la declaración de una experiencia de 4.500 horas gestionando proyectos (la otra forma es tomar otros cursos de organizaciones certificadas por el PMI) se puede obtener el PMP, pero ello no asegura que tengan las competencias necesarias.

Debo reconocer que en el año 2007, realice todas las gestiones para certificarme, para lo cual presenté las horas de pre requisito, según me consta las personas de contacto (contrapartes de los proyectos presentados) que puse en mi solicitud, algunas fueron contactadas y otras no.  Tenía programado un curso intensivo de una semana para preparar el examen, finalmente tuve que abortar mi proceso ya que fui nombrado Secretario Ejecutivo de la Estrategia Digital y la verdad es que se me hizo inviable cerrar el referido proceso.

Los Europeos, en particular los ingleses con su metodología de gestión de proyectos Prince2, su gran argumento a su favor es que no existe un modelo de negocios detrás de ella, el PMI se defiende con el argumento de que se trata de un método reconocido a nivel mundial y un estándar desde el punto de vista de la gestión d proyectos.

En todo caso se debe señalar que las certificaciones Prince2 o PMP no aseguran calidad, es igual que las certificaciones ISO, aseguran que se cumple un método/procedimiento para el proceso, lo cual al menos da garantías de consistencia en el proceso y los artefactos que se utilizan para su desarrollo.

Usted,  ¿qué piensa al respecto? , los gerentes PMP desempeñan una mejor labor a la hora de administrar proyectos, en este punto me encantaría contar con la retroalimentación de Eduardo Díaz, digo yo para seguir con el debate sobre proyectos TI y su gestión.

Andreessen realiza un planteamiento interesante y que me llevó a reflexionar si nuestros países van por el camino correcto en materia de industria tecnológica.  Ya desde el título del artículo Why Software Is Eating The World, hasta la muestra de lo que está ocurriendo con varios sectores industriales y como en cada uno de ellos el software está tomando un rol preponderante y en algunos caos resulta ser fundamental, algunos ejemplos de ello:

• Amazon: La librería más grande del mundo y camino a transformarse en el retailer más grande
• Netflix: El servicios de video más grande del mundo
• Itunes, Spotify, Pandora: Compañías dominantes en el mundo de la música
• Google, Groupon, Foursqare: Líderes en marketing directo a nivel mundial
• Skype: La empresa de telecomunicaciones que más crece a nivel mundial
• LinkedIn: La empresa de reclutamiento que más crece en el sector
• Paypal: Servicios financieros

Lo que tienen estos ejemplos en común son que las compañías que hay detrás de los distintos negocios, esto es, retail, entretenimiento, marketing, comunicaciones, reclutamiento y servicios financieros es que son empresas de software.

¿Por qué me llevó a reflexionar respecto de nuestro sector en la región?, es que en en general la industria del software representa un porcentaje muy bajo del total del marcado TIC en la región, somos básicamente revendedores (hardware, software básico) de tecnologías diseñado y producido en otras latitudes, al revisar las cifras de negocios asociadas a servicios de valor agregado y en particular desarrollo de software, estas son bastante más bajas.

Algunos países, están haciendo esfuerzos para cambiar aquello, me refiero a los esfuerzos emprendidos en Brasil, México, Uruguay por establecer una industria de valor agregado vinculada a la industria TI, me parece es la jugada correcta.

En Chile lo veníamos haciendo bien con la política de clusters, en particular el cluster de offshoring, pero alguien se llevó la pelota para la casa en el último tiempo y nos hemos quedado.

Es de esperar que en algún momento tomemos la senda adecuada y pongamos nuestras fichas en el software, por que como dice Andreessen, software is eating the world

Imagen: http://technosoftwares.com/services-2/software-development/

Al menos esto, hace que el impacto y consecuencias de este tipo de fracasos sea menor, por otra parte cada gerente de proyecto debe estar monitoreando si su proyecto tiene potencial para transformarse en un Cisne Negro o no, ya que con 17% no sería raro que en su carrera le toque encontrarse con uno

Como ven la e, es la parte pequeña del concepto siendo mucho más relevante lo que atañe al gobierno (government) si bien esto parece más o menos obvio, por obvio se nos olvida, ello implica que en todo proceso debemos preocuparnos de los temas de gobernabilidad por sobre los tecnológicos.

Los proyectos de gobierno electrónico, son una componente más del desarrollo del estado, muy importante por cierto y en muchas ocasiones olvidada, pero debe formar parte de un modelo completo de modernización.



Cada una de estas componentes son piezas fundamentales para cualquier proceso modernizador del estado.

Al momento de definir un proceso modernizador, este debe considerar las iniciativas y  acciones que se van a emprender en cada una de esas áreas.  A todo ello debe dársele un modelo de gobernabilidad para conducir el proceso.  En ocasiones me ha tocado ver proyectos en que el foco es la tecnología, no tomando en consideración las otras variables, lo cual va a llevar tarde o temprano a que el impacto del proyecto sea muy acotado e incluso presente riesgo de fracaso.

Probablemente debemos buscar una mayor cantidad de espacios de interacción entre técnicos y los gerentes públicos (autoridades).  En la medida que ese diálogo se de en forma natural mejores resultados de los proyectos TI obtendremos, y la modernización del estado podrá profundizarse, algo que requieren con urgencia nuestros estados.  re cordemos lo que nos plantea para el Estado el Foro Económico Mundial,esto es que el estado debe ser FAST flatter, agile, streamlined y tech-enabled.

Para ello, se juntan en algunas de las casas y al alero de buena comida y buen vino se desarrolla esta distendida conversa, utilizando diversas tecnologías a mano, tales como:  livestream, skype, twitter, browser, y por supuesto el mail.

El espacio no tiene un formato predefinido pero, la idea es conversar en un ambiente distendido, lo primero que tengo que decir es que fue un momento muy grato y el tiempo, fueron más de 3 horas se me pasó muy rápido.  Abordamos toda clase de temáticas tales como Open Data, desempeño de proyecto tecnológicos en el estado, rol de los actores relevantes, compras públicas TIC y algunos de mis hobbies como los volantines.

Les adjunto el video de la conversación, son dos ya que en un momento se produjo el infaltable problema técnico, Murphy que le dicen, y por lo tanto hay dos vídeos.

Parte 1:

Parte 2:

Si les interesa seguir a Marco, Ublado y Eduardo en su iniciativa los pueden hacer en Skype (eltestacido), Twitter @eltestacido y en su sitio web www.eltestacido.cl los jueves a partir de las 21:30

Imagen: Wikimedia

No he visto nada más obsoleto que el proceso de policía internacional en el ingreso y salida país. 

El proceso exige que los viajeros llenen de puño y letra un formulario denominado Tarjeta Internacional de Embarque/Desembarque - Chile cuando abandonan el país, el cual debe ser timbrado en Policía Internacional, luego se debe guardar la copia timbrada, habitualmente amarilla, bajo las penas del infierno si se le pierde, al parecer hoy es menos grave que hace unos años; hace tiempo se me perdió y el funcionario de la Policía me recibió de manera muy poco cordial cuando volvía al país luego de varios días de viaje. 

En el formulario se debe ingresar la misma información cada vez, a ningún funcionario le han avisado que la mayoría de esos datos están manos del estado y que al solicitarlos están infringiendo la ley 19.880?

El volumen de transacciones para el año 2010 de este trámite fue de:

Fuente: Sernatur

Analicemos algunas de las características del formulario:

• No está estandarizado, y existen diversas versiones del formulario, si bien en general se pide más o menos la misma información, los nombres de los campos difieren y en algunos casos los formatos varían, el documento de la imagen corresponde a la Aerolinea Pluna, solicita fecha de nacimiento en el formato día/mes/año, en el caso de Copa Airlines, sólo pide el año de nacimiento con cuatro dígitos. lo cual muestra un problema  de estandarización y interoperabilidad semántica?
• Cada línea aérea y agencia de viajes tiene su propio formato, algunos casos el formatos es texto libre en otros son celdas,  o bien está codificado como es el caso del sexo y ocupación.
• Debe ser llenado al salir del País y guardar una copia para el regreso, lo cual implica transferir la responsabilidad de la data al ciudadano.
• Se preguntan datos que claramente tienen propósitos estadísticos y otros datos con propósitos de control, ¿por qué la policía requiere conocer mi ocupación cada vez que salgo del país?, si en una pongo emprendedor y en la otra ingeniero (tengo ambos sombreros), ¿cuál vale?
• La mayoría de los datos son estáticos por lo tanto bastaría con mi identificador para obtenerlos cada vez y no arriesgarse al error de digitación, en cuantos de mis formularios en el campo nombre habréescrito Alejandro y cuantos será Luis Alejandro.

Producto de la cantidad de viajes que me ha tocado realizar he podido ver que el proceso de ingreso y salida del país es bastante ineficiente o al menos poco centrado en el ciudadano, imaginemos como se podría hacer esto en forma más eficiente:

Se imaginan que el documento Tarjeta de Embarque/Desembarque - Chile fuera un documento electrónico estándar, idealmente basado en los estándares nacionales de documento electrónico, esto es utilizando las normas y estándares de los decretos supremos 83 y 81, así es, el papelito  que uno debe llenar, con datos que además en el caso de los ciudadanos chileno el Estado de Chile ya tiene y no cambian, tales como: nombre, nacionalidad, fecha de nacimiento, sexo, estado civil llenados en forma electrónica y automática.  El proceso podría ser bastante más eficiente, si se utilizara un portal en la web con las siguientes características.

1. Se ingresan solo los datos necesarios al momento de la salida, en el caso de chileno solo solicitaría el RUN y una buena cantidad de datos que se piden se obtendrían de la base de datos del Registro Civil.
2. Los datos para fines estadísticos opcionales
3. Portal le asigna un número único de documento para ser utilizado en la entrada,  si es que es necesario ya que policía internacional podría acceder directamente con el RUN al momento que lo necesite.
4. Desaparece el concepto de original y copia como existe hoy
   

Algunos de los beneficios que un servicio como este presenta son:

• Es ciudadano céntrico, pensando en quien hace el trámite y no en quien requiere la data.
• Se reduce considerablemente la tasa de error por digitación, duplicación y falta de estandarización de los datos.
• Se reducen los costos de gestión de formularios en papel (10 a 1), en 1.965.217 son bastantes recursos fiscales que se ahorran.
• Se puede encadenar con el proceso de venta de tickets aéreos y por lo tanto obtener la data asociada a todo el proceso.
• La fiscalización de ingreso y salida del país es bastante más eficiente
• Las estadísticas de migración serían bastante más certeras

Este es un proyecto que no reviste mayor complejidad  y que es de alto impacto, espero las autoridades lo puedan evaluar positivamente.

El plan cuenta con metas cuantitativas y cualitativas y las principales son:

• Terminar con el menos un tercio de los proyectos tecnológicos con problemas de desempeño y resultados en los próximos 18 meses.
• Cada agencia debe identificar e implementar al menos 3 servicios en modalidad "cloud computing" en un plazo de 12 meses
• Reducir en al menos 800 dataceter del gobierno central, hoy cuentan con 2.100
• Establecer criterios más precisos para la entreaga de recursos a los proyectos, estos deben cumplir con: esquema y método claro de gestión, estrategia incremental de implementación, resultados cada 6 meses, uso de especialista de contratación  de proyectos TI
• Trabajar con el congreso en nuevos modelos presupuestarios para los proyectos TI más flexibles (estructura de externalización, multianualidad, varianza de resultados y requerimientos).
• Establecer mecanismos de colaboración e intercambio de prácticas.

Para lograr esto se va a trabajar como mencionaba en 25 iniciativas con los horizontes de tiempo planteados, las más relevantes son:

• Consolidación de servicios TI y datacenter
• Establecer un marketplace de servicios TI (convenio marco)
• Definir un política clara y precisa del uso de la modalidad cloud computing
• Estandarizar contratos para modelos IaaS y servivios TI comodities
• Desarrollar estrategia de servicios compartidos en el Estado
• Definir competencias y desarrollo profesional asociado a la gestión de proyectos tecnológicos basados en buenas prácticas (PMI)
• Eliminar los procesos de implementación en modalidad big-bang
  
• Desarrollar plataforma de colaboración e intercambio de prácticas
• Mantener y potenciar sesiones de trabajo TechStat
• Desarrollar competencias específicas en el proceso de contratación TI
• Simplificar los procesos de contratación TI bajando barreras de entrada a pequeñas compañías innovadoras
• Simplificar y modernizar el ciclo presupuestario asociado a los proyectos TI incorporando atributos que le son propios

Como vemos es un muy ambicioso plan que además debe contar en algunas de sus áreas con la venia de otros poderes del estado.  El horizonte de tiempo es corto veremos si Kundra tiene el nivel de convocatoria, empoderamiento y capacidad de ejecución (delivery) para lograrlo, pero ya es un gran logro que haya podido poner en agenda es documento de análisis y propuestas con el sello de la casa blanca en la primera hoja.  Recomiendo leerlo ya que da luces y propuesta que pueden ser replicadas en otras latitudes.
 
 Si desea bajar el plan: 25-Point-Implementation-Plan-to-Reform-Federal_IT.pdf

• Falta de vínculo entre el proyecto y las prioridades estratégicas de la institución
• Falta de habilidades de gestión de proyectos y administración del riesgo
• Falta de liderazgo y ownership del proyecto
• Poco conocimiento de la industria TI local y de lo que realmente puede proveer.
• Presupuestos mal definidos, ni proveedor ni comprador saben cuanto cuesta la solución
• Evaluación de propuestas con mirada de corto plazo sustentado en oferta económico y no en valor del gasto
• Pocas iniciativas para segmentar los proyectos en tamaños más manejables
• Arquitectura tecnológica mal definida
• Niveles de servicio (SLA's) mal definidos y/o no administrados

En los últimos días hemos visto por la prensa información con sendos titulares, describiendo el problema del contrato tecnológico Fonasa - Entel.  Más allá de lo superficial y poco documentado análisis al que nuestra prensa local nos tiene acostumbrado (cuando leo este tipo de reportajes, me pregunto nadie cuestiona en serio la calidad de nuestro medios en temas más complejos que los últimos eventos de farandulandia).  Tanto es así que hace unos días el diario La Tercera no fue explícita en el nombre del proveedor mencionando  "El contrato, firmado en 2004 con una empresa telefónica...", cuando alguno de ustedes escucha "empresa telefónica"  ¿piensan en Entel o en Telefonica?

Eso me recuerda algo que me ocurrió hace ya muchos años, en una entrevista que me hiciera el diario Estrategia, a la pregunta cuanto le iba a costar a Chile el problema del año 2.000, o Y2K como se conoció en sus momento, dije "estimo que serán unos 400 millones de dólares", pues bien en el artículo apareció 4.000 millones, al increpar al periodista por el error (ojo que estamos hablando de un medio se supone acostumbrado al manejo de números), me dijo "que daba lo mismo, nadie lee los números", mi reacción fue como la de Condrorito, "plop".

Retomando el tema que nos convoca, me parece importante relevar algunos antecedentes que son públicos. Una de la cláusulas definía que si el proveedor no cumplía con plazos de puesta en marcha de la nueva solución se debe mantener al operador actual y el nuevo operador debe pagar por los servicios manteniendo la continuidad de servicio, recordemos que Fonasa atiende a millones de usuarios y entrega millones de prestaciones.

Si alguien analiza este proyecto con mirada monofocal y basada unicamente en los aspectos jurídicos, efectivamente pueden faltar multas a cobrar (algo que que no me consta) y por lo tanto la conclusión puede estar ajustada a derecho puede que esté en lo correcto, ahora bien como me consta el proveedor no estaba disponible a más multas en ese momento y su respuesta fue: "me cobran más multas y me retiro del proyecto, nos vemos en los tribunales y que gane el más mejor" con el consecuente riesgo para la continuidad de servicio que esa situación genera.  En situaciones como esta se debe analizar el mayor bien común, el cual probablemente podría llevar a pasar algún otro bien de carácter jurídico.

En ese escenario debe primar la cordura y que en este caso se debe regir por la continuidad de servicio en un servicio de carácter masivo y que afecta a muchas persona, millones para ser más preciso.

Independiente de que el proyecto tenía problemas en su origen, en los servicios críticos que el estado presta a sus ciudadanos uno de los valores fundamentales es la continuidad de servicio, ya que sino es finalmente el ciudadano el que paga el costo final.

¿Qué hubiera pasado con el servicio si como se plantea se le hubiera rescindido el contrato a Entel en ese momento?

Otro elemento que vale la pena evaluar es cual va a ser el impacto futuro en el costo de los proyectos y contratos TI cuando estos terminan en la prensa y en los tribunales, me pregunto: ¿que porcentaje es el factor de riesgo que los empresarios TI pondrán en sus ofertas producto de la historia pasada y el potencial de judicialización de los proyectos?

Uno de los elementos más funestos en los modelos de externalización que el Estado (ojo este problema se da casi en toda la región, más al norte las relaciones PPP tienden a establecer relaciones win-win) establece, ya que la relación al menos con sus proveedores tecnológicos es bastante esquizofrénica.  Esto no hace más que aumentar los niveles de desconfianza.  Por otra parte la industria debe ser más responsable y seria a la hora de preparar sus ofertas, hemos visto varios casos en los cuales empresas se presentan a proyectos con el modelo de que en el camino se arregla la carga.

Lo anterior significa que el Estado queda en la indefensión? la respuesta es no, pero definitivamente lo que que deben cauterlarse en todo proyecto es el beneficiario final del servicio y que no sea este el que termine pagando la cuenta.  Por lo tanto vuelvo a la pregunta inicial ¿qué bien cuatelar?

Imagen: Desde sitio del Gobierno Australiano sobre resolución de disputas

Fuente problemas en proyectos TI:Proyectos TIC - Sector Público (octubre 2006)

¿Se imaginan que sólo el 32% de los proyectos inmobiliarios o de infraestructura fueran exitosos?

Hace unos días Mario Waissbluth me pidió unos datos sobre tasa de éxito/falla de proyectos tecnológicos en el Estado, o dicho de otra forma proyectos eGov, lo que me llevó a buscar entre mis cachureos, y me di cuenta que mis datos estaban un poco añejos, por lo que me puse a investigar nuevamente y llegué a números un poco más recientes, dicho sea de paso, creo que en Chile nos hace falta una investigación seria al respecto, todos los números que andan dando vuelta, tienen bastante de dígitos oscilantes, si sirve de consuelo los números que existen a nivel internacional tampoco hacen segmentación por industria o sector (público o privado).

El estudio más referenciado es el que realiza la consultora Standish Group, el cual es recurrente y existen datos desde 1994, que apareció por primera vez, estudio denominado Chaos Report.  He escuchado algunas críticas a este informe, por ejemplo relacionadas con la definición de exitoso que es muy  estricta, pero al menos sirve como referencia y además permite tener una evolución en el tiempo ya que es el único estudio que conozco que se realiza en forma periódica.

Antes de mirar esos números démosle una mirada a otras cifras que andan dando vuelta

• Chaos Report (1994) - 16.2% de los proyectos son exitosos.  Del 70% de proyectos no exitosos, 52% corresponden a fallas parciales (expectativas, o tiempos o $)
• Encuesta OASIG (1995) - Las respuestas más optimistas sitúan la tasa de éxito entre 20% y 30%
• Encuesta KPMG Canada (1997) - 61% de los proyectos se consideran fracasados
• Encuesta Conference Board (2001) - 40% de los proyectos no cumplen expectativas de negocios, luego de un año en operación
• Encuesta Robbins-Gioia (2001) - 51% de las implementaciones de ERP son fallidas
• Encuesta Revista Dr. Dobb's (2007) - 72% de los proyecto de desarrollo e implementación de Data Warehouse con metodologías ágiles, versus 63% con metodologías tradicionales.

Como se puede ver, todos los estudios coinciden en que la tasa de éxito de los proyectos es bastante baja, independiente de cual sea la definición de éxito se utilice.  Al observar la evolución de las diferentes mediciones del Chaos Report de Standish como se aprecia en el siguiente gráfico, podemos apreciar un aumento de las tasas de éxito no demasiado significativa pero al menos con una curva positiva, esto se debe fundamentalmente a mejores prácticas de gestión de proyecto, tipo PMI u otros, uso de mejores herramientas y metodologías de desarrollo.



En el ámbito del Estado el comportamiento es incluso peor, según el estudio de eGovernment for Development de la Universidad de Manchester, sólo el 15% de los proyectos son considerados exitosos, la definición que utiliza eGov4Dev es:

Los principales stakeholders del proyecto dicen que se han logrado los principales  objetivos y no han experimentado resultados no deseados significativos

En la gráfica se detalla el resultado de dicho estudio:

Sería interesante que las autoridades locales pudieran medir nuestro comportamiento, ya que si estamos en los mismos niveles, esto es, 35% totalmente fracasados (nunca se implementaron o abandonaron según definición del eGov4Dev) unos 100 millones de dólares del presupuesto de la nación van a dar a la basura.

Todos los estudios coinciden han las mismas causas de fracaso de los proyectos, las que se pueden resumir en:

• Especificaciones y requerimientos cambiantes o incompletos;
• Falta de involucramiento de usuarios
• Pocos conocimientos técnicos del equipo de proyecto
• Uso inadecuado de métodos y herramientas
• Expectativas poco realistasFalta se soporte gerencial
• Gestión de proyectos débil, lo que incluye no identificación de riesgos, falta de planificación, comunicación deficiente

Referencias

• Standish Group
• ProjectSmart  
• The business end of IT project failure 
• Why IT projects Fail, Al Niemat, Taimour 
• eGovernment for Development, Universidad de Manchester

Esto ha generado un diferencial importante en los proyectos de desarrollo de software, particularmente en las aplicaciones de negocios.  Esta brecha se aprecia de forma importante en el no cumplimiento de tiempos y recursos definidos para el proyecto y en una percepción bastante generalizad por parte de áreas usuarias, de que los informáticos no cumplen con plazos y costos.

Las principales dificultades que se plantean a la hora de desarrollar software (aplicativos de negocios) corresponden a la etapa de capturar los requerimientos de los usuarios, ya que luego de aquello se tiene la esperanza por parte de los desarrolladores que el mundo se va a congelar, es como jugar el juego del un, dos tres momia es.  Sin hacerse cargo de los continuos cambios que tienen los modelos de negocios, producto de la competencia, otros productos y en general situaciones de mercado en muchos casos no previsibles.  Según Standish Group cerca del 60% de los requerimientos cambian a lo largo de un proyecto.  Otro elemento importante a tener en cuenta que si cambias de opinión en algún requerimiento al comienzo y esto tiene un impacto financiero de X, este mismo cambio cuando el proyecto lleva un 70% de avance el impacto se multiplica por 100 (100X).  Por eso es que hay que congelar el mundo ya que sino el costo puede ser enorme.

El desafío que se plantea a futuro en el proceso de desarrollo de software es comprimir el tiempo, esto es, reducir el tiempo entre el surgimiento de la necesidad y contar con la aplicación que la soporta.  A partir de esto es que han surgido metodologías cuyo propósito es precisamente reducir ese tiempo y hacerse cargo de que el mundo sigue girando con su consecuente impacto en los sistemas de soporte al negocio.

Las metodologías denominadas "ágiles" que las hay en varios sabores, siendo las más conocidas XP y SCRUM han comenzado a ganar gran cantidad de adeptos.

SCRUM, método desarrollado por Jeff Sutherland y Ken Schwaber, el cual se basa en un método de producción en la industria automotriz, en particular, la empresa Toyota.  Dicha empresa diagnóstico un problema similar al mencionado en el caso del software, demasiado tiempo entre la idea de un nuevo modelo y su puesta en el mercado.   Con este método logró reducir órdenes de magnitud el time to market de nuevos modelos, transformándose en un líder en esta área.

Fuente: Softhouse

Algunos elementos básico de SCRUM

1. Opera en base a iteraciones cortas (15 días a 1 mes)
2. Equipos de trabajo pequeño (7-9 personas)
3. En cada iteración se implementan funcionalidades usuarias y estas deben ser demostrables
4. Usuario participa en las iteraciones
5. No requiere que digas todo desde el comienzo
6. Puedes cambiar de opinión en el camino
7. Cada equipo tiene un líder
8. Se trabaja con reuniones diarias (CORTAS), en las cuales cada miembro del equipo contesta: ¿Qué ha cumplido desde la última reunión?, ¿Qué obstáculos se presentan?, ¿Qué voy a terminar?

El propio Schwaber define SCRUM como una colección de buenas ideas más que una metodología en el sentido estricto y se basa en la transparencia, ya que todo el mundo sabe que está pasando con el desarrollo de una determinada aplicación en periodos cortos de tiempo (cada iteración) y no se encuentra con un "conejo" al final, que habitualmente parece más un jira-mono-canguro.  No todas las organizaciones han podido implantar estas prácticas con éxito, sólo el 35% lo logra ya que muchas no están dispuestas a transparentar el proceso.

La gracia de este proceso incremental además es que se implementa lo que se requiere realmente y no todos los chiches que a alguien se le ocurrió al comienzo del tiempo, recuerden que el 65% de las funcionalidades de un producto nunca son usadas, ¿qué porcentaje de Office utilizan?

Les recomiendo vean estos videos que adjunto de los ideólogos del SCRUM

Scrum et al. - Ken Schwaber, Google Tech Talls - 5/9/2006

Scrum Tuning: Lessons learned - Jeff Sutherland, Google Tech Talks - 7/12/2006