Scrum – Flashcard

¿Que es una FlashCard? Si vamos a la wikipedia y con un poquito de ingles

A flashcard or flash card is any of a set of cards bearing information, as words or numbers, on either or both sides, used in classroom drills or in private study. One writes a question on a card and an answer overleaf.

Digamos que son tarjetas con una pregunta en un lado y la respuesta en el otro. Para los que son como yo, es decir, no tienen una memoria de elefante y mucho menos un coeficiente intelectual super elevado y que aprendemos a base de repetición pues son una gran ayuda. He encontrado en las FlashCard una manera de llevar siempre conmigo los conceptos que quiero y si me cuesta leer un libro pues si “alguien” lo resume en flashcards pues bendito sea.

Scrum es una de los temas mas populares y siempre en diversas charlas y entrenamientos las personas se quedan con dudas sobre algunos conceptos o no te alcanza el tiempo para explicar todos. Así que para no dejar las cosas en el aire he decido llevar siempre conmigo una flashcard de Scrum para regalar a aquellos entusiasmados (Si solo una no me las regalan ).

Bueno felizmente mi hermana se encargo de hacer las tarjetas y de pasada aprendio algo de Scrum sin que le explicara jajaja “Que es eso de gallinas y cerdos?” me decia. Las tarjetas estan en ingles pero pues con el tiempo que me de sacare unas en español. El contenido fue extraido  de “Agile project management with Scrum” de Ken Schwaber por una pagina que tengo pendiente linkear.

Aqui les dejo unas fotos. Si alguién va a traducir el contenido porfavor aviseme por comentario y asi no hacemos doble trabajo.

Si quieren ahorrarse el trabajo de la fabricación voy a mandar ha hacer otro set si se apuntan para que nos salga mas barato pues me dejan un mensajito.

Asi que ya saben FlashCards de Scrum no salga de casa sin ellas y solicitelas a su ScrumMaster/ScrumTrainer/ScrumCoach mas cercano jajaja.

Saludos

Sobre… “The Core Protocols – mejores prácticas para las personas”

Interesante me parecio The Core, que no es ni mas ni menos que un conjunto de practicas publicadas libremente, sobre la formación de equipos en el desarrollo de software. Ahora que andamos en la onda de preocuparnos en las personas y su interacción The Core provee unas guías y practicas que ayudan a que los equipos interactuen de manera sincera. Todo esto bajo una serie de compromisos.

Es interesante su similitud con muchas practicas de metodologías ágiles asi como nuevas tendencias de management o Agile Management. Bases como ser sincero, saber pedir ayuda, tener decoro al inter-actuar con los demás, compromiso, manifiesto de intenciones, decisiones de equipo, apoyar las mejores opciones sin importar de quien vengan, Equipo o Team.

Otro tema que gusto mucho es que tocaran el tema de Personal Space que es algo que apasiona, es el estudio de los espacios personales, la distancia entre las personas al conversar y que significados puede tener la distancia que se toma entre cada uno. mas

Todos estos temas son tocados en The Core, no soy muy partidario de las cosas complejas, felizmente esta no lo es y es libre!!. Es decir podemos colaborar y esta versionada. No me queda mas que recomendar su lectura y espero tengan éxito en su implementación

mas infomarción The Core

Si les va mejor el español Link

Procesos sobre personas

Esa obsesión de querer reemplazar a las personas o hacer su necesidad la menos posible. Tratar con personas es complejo por ello se trata mucho de evitarlo, pero tal vez no es la mejor opción.

Procesos sobre personas

Esto lo vi via Navegapolis

Sobre… “Burn-Up Chart el hijo olvidado de Scrum”

Sin animo de burla me vino a la cabeza el nombre de “el hijo olvidado de Scrum” porque no es mencionado mucho cuando se evangeliza Scrum, es mas algunos se hacen de la vista gorda al escucharlo.

El Burn-Up Chart es uno de los artefactos de Scrum que nos permite cumplir con la gestión visual o visual management. Pero que hace tan especial al Burn-Up chart?. Pues simple su hermano mas popular el Burn Down chart nos permite solo ver cuanto vamos sobre un Sprint.

El Burn-Up chart nos permite mucho mas, nos permite ver que tanto cambio el alcance del proyecto en el tiempo, cuanto nos falta para los deadlines o fechas de entregas y nos permite ver el valor ganado en el proyecto. Es decir una visión mas amplia es ideal para reportar estados del proyecto y explicar al cliente en que se esta poniendo esfuerzo y que esta obteniendo a nivel del proyecto

Como podemos ver en el grafico un burndown chart nos permite ver como aumentan los story points o puntos de historia de usuario a lo largo del proyecto esto es muy importante que sea conocido por la empresa para el manejo de sus costos. Otro punto importante es que la columna vertical (eje Y) tenga una unidad medible, en este caso puntos de historia permite el objetivo, también podrían usar funcionalidades como puntos del eje Y como el grafico inferior

Como vemos el cliente podrá ver en todo momento que esta ganando con el tiempo.

Otro de los puntos fuertes es que nos permite ver cuando se interceptaran la línea de progreso con el total de trabajo pendiente podemos ver si el comportamiento es asintótico y tener una idea de la relación trabajo-aumento de requerimientos en el proyecto.

Para no cansarlos quería exponer los puntos fuertes de esta herramienta  y que a grandes luces no es tan motivadora como su hermano mas conocido el BurnDown chart pero nos servirá para cumplir esos benditos indicadores y reportes que nos suelen pedir.

Fuentes: http://niksilver.com/2008/01/19/burn-up-and-burn-down-charts/
http://alistair.cockburn.us/Earned-value+and+burn+charts

In a nutshell – Poka Yoke

¿Que es Poka Yoke?

Poka Yoke = “A prueba de errores”. En el mundo industrial y de producción el termino se refiere a un sistema orientado a evitar errores o identificar estos tempranamente. Todo esto orientado al logro de alta calidad.

Un Poka Yoke puede estar compuesto principalmente de un sistema de deteccion (antes que ocurra el error) y un sistema de alarma (una vez ocurrido).

"la causa de los defectos recae en los errores de los trabajadores, y los defectos son los resultados de continuar con dichos errores".

Shigeo Shingo

ok y esto donde va?.

Poka Yoke lo vemos en casi todo lo que tenemos. Los conectores de los celulares, los cables para instalar un pc, los conectores USB, etc. Nos presenta solo una manera de ser conectados no podemos cometer errores con ellos. A veces cuando realizamos tareas repetitivas podemos asegurar la calidad implementado alguna técnica de detección y una de alarma es decir un Poka Yoke.

Un videito donde se explica el Poka Yoke junto con otro principio chaku-chaku que explicaremos en otro In a nutshell

 

 

Como siempre las referencias

Si les va en ingles:

Zero Quality Control: Source Inspection and the Poka-Yoke System (Link)

Si les va en español:

Poka−Yoke en español (Link)

In a nutshell – Scrum

¿Que es Scrum?

In a nutshell (en pocas palabras) y recurriendo a la madre de todos los vicios la “Scrum Alliance”

Scrum es un framework (marco de trabajo) basado en equipos para desarrollar sistemas complejos y productos.

¿Simple no? ok ok un poco mas

Plantea trabajar en ciclos o iteraciones llamadas Sprints y durante estos ciclos el equipo de trabajo toma requerimientos del cliente llamados user stories, de manera que estos sean desarrollados por su mayor retorno de inversión (ROI) para el cliente. Al final de cada iteración se obtiene un producto potencialmente entregable.

Así que ya sabemos Scrum no es un nuevo plato de comida, ni un estornudo es una opción para trabajar en desarrollo de productos y sistemas.

Hasta aquí acaba “In a nutshell” ¿Queremos mas?

Si le vas al ingles :

• Scrum Alliance http://www.scrumalliance.org/ 
• Serie de Videos muy explicativos http://www.agiledevelopmentwithrob.com/blog/agile-videos/332/introduction-to-agile-and-scrum-part-1/

Si les va el español mejor :

• Navegapolis http://www.navegapolis.net/content/view/694/
• Proyectos Agiles (definiciones) http://www.proyectosagiles.org/

Bueno este es el primer post de “In a nutshell” como saben no es para explicar todo sino para no andar perdidos en un tema o termino que ronda en el ambiente

Sobre… “in a nutshell posts”

Muchas veces como personas de tecnología o tal vez no de tecnología requerimos tener cierta cultura general sobre temas tecnológicos.

¿Para que?, pues principalmente para que no nos engañen jajaja o para saber tomar decisiones en base a conceptos básicos. Si estas gestionando proyectos o simplemente requieres tomar decisiones tal vez no necesites saberlo todo pero haber leído en algún sitio sobre temas que rondan mucho por el ambiente.

Es por ello que nacen los posts “in a nutshell”, termino en ingles que significa “en pocas palabras”, en peruano “Poco floro”. Simplemente usare este tipo de post para explicar conceptos a nivel ultra básico pero que nos permitirán salir de la ignorancia. Si esa chica malcriada llamada ignorancia.

Así que quedan inaugurados los posts “in a nutshell”

Sobre: “Scrum Release 2.0?”

Basado en el artículo http://www.scrumalliance.org/articles/12-scrum-release-

hay ciertos puntos a tomar en cuenta cuando se tiene en manos una metodología ágil y quien mas que la vedette de las metodologías agiles: “Scrum”

The product owner job is incredibly difficult. Almost all people fulfilling the product owner role are surprised by how much work it is

El rol de product owner tiene ciertos problemas actualmente, no termina de ser bien asimilado y es uno de los mas combinables en Scrum. La similitud con un rol existente en diversas organizaciones llamado “Product Manager” hace que aparentemente el mismo no tenga sentido. Para sacar una conclusión sugiero leer esta interesante cadena de post en el siguiente vinculo.

Traditional methodologies provide answers to all problems, and this is why they don’t work—they assume a simplistic rather than a complex problem. They proceduralize answers; Scrum calls on the participants to use hard work and common sense.

The desire for a more formal, regular, advanced Scrum is normal. That is what our profession is all about and why we were drawn to it. We take complexity and normalize it into computer programs. Resisting doing the same to Scrum is extremely hard, but necessary, because the further development of Scrum to address individual or organizational difficulties is the death of Scrum and the birth of still another useless methodology.

Conclusiones?. Scrum es exigente, no resuelve problemas los expone (los resuelven las personas), no trates de normalizarlo (perderá la esencia), no adaptes algo que no conoces (modificarías tu auto antes de manejarlo por primera vez?) y paciencia un paso a la vez.

Farewell champions

Una pequeña conversación

Bueno no he posteado mucho ultimamente porque ando metido en la campaña TISolidario.org. Dense una vuelta para ver mas o menos de que trata. Lo contare con mas detalles luego.

Mientras tuvimos una pequeña conversación con @elfederiko y @jersson sobre varios temas. El principal era en base a un articulo de Juan Palacio en Navegapolis y su complemento en ChileÁgil. Como mi primera experiencia pues espero disculpen temas de edición y que ya encontramos solución para otras versiones. La idea era divertirse y aunque al comienzo se puso muy seria la conversación, luego se fue relajando y salio como se esperaba.

No pensamos igual y eso hizo esto divertido. Tal vez no alcanzo el tiempo para debatir algun tema especifico a detalla pero creo que este sera el primero, pero no el ultimo de nuestras conversaciones. Espero los distraiga, o entretenga mientras lo escuchan.

No se olviden dejar sus comentarios!

Fe de Erratas: Se menciona el site de Juan Palacio como Navegapolis.com cuando es Navegapolis.net

Sobre… “El fin supremo del ScrumMaster”

Si conoces que es Scrum puedes continuar leyendo si no es así pues te tomara solo 10 minutos aprenderlo en el siguiente video Video Scrum in 10 minutes

Si ya conoces los roles de Scrum como el ScrumMaster, Product Owner y Team. Pues entremos en materia.

En una cátedra sobre Scrum a una empresa ajena al software surgió la siguiente pregunta: “Entonces como persona. ¿Cual es el fin máximo o final de un ScrumMaster?”.  En ese momento vino a mi mente un disyuntiva que tenia con un compañero. El solía resaltar la importancia de un ScrumMaster y su fin máximo como la eliminación de obstáculos o la exposición de los mismos, así como proteger al equipo de cualquier agente externo.

Hasta aquí tenemos la tarea hecha, pero como ScrumMaster, como persona, que es a lo que apuntaba la pregunta, un ScrumMaster debería apuntar a ya no ser necesario, es decir, a desaparecer.

Recuerdo que muchos se rasgan las vestiduras pues encontraron en el rol una profesión pero si entienden el concepto natural de un ScrumMaster y su afán de servicio entenderán que no hay mejor ScrumMaster que aquel que siente felicidad al ver que el equipo ya no lo necesita. Es decir, son auto-gestionados. Cuando el equipo a llegado a un nivel de “Madurez Ágil” el ScrumMaster ya no seria necesario. Ellos podrán cumplir las labores que realizaba el ScrumMaster y es más, esto beneficiaria al equipo a niveles de compromiso e integración. Es más la ausencia de un ScrumMaster lleva al proceso de Scrum a un nivel extremo y por ende da resultados muy interesantes.

Es como la practica de llevar Extreme programming al extremo, también se puede llevar Scrum al extremo.

 

El fin supremo de un ScrumMaster es ya no ser necesario, esto es fácil de entender al hacer relación entre un ScrumMaster y el Coaching. El fin de un coach, de un buen coach, es que ya no se le necesite mas. Claro que económicamente ya no le sea rentable.

¿Que otros trabajos tienen ese fin supremo?. El de ya no ser necesario.

Sera un nuevo tipo de oficio que ha evolucionado. Sera que son profesiones que al no ser económicamente rentables, caigan en una trasgresión de sus valores morales. No puedes mentir, no puedes decir que siempre serás necesario cuando sabes que la naturaleza de a lo que te dedicas es que ya no se te necesite. Esta es una de los males que aquejan al buen coaching y que desprestigian la profesión. ¿Será que también afecta a los ScrumMaster?