Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Promociones de Amazon: Kindle Flash y PublicaConKindle

Amazon quiere celebrar durante todo el mes de octubre el fenómeno de la autopublicación con una promoción especial en una selección de libros entre los que estará mi libro Certificación Professional Scrum Master.

Durante esta promoción, llamada #PublicaConKindle, el libro estará a la venta por sólo 0.99€ en lugar de los 2.99€ habituales. Amazon publicará pronto una página especial dedicada a este evento para promocionar la publicación independiente. Pondré el enlace por aquí cuando esté listo.

Habrán muchos otros libros en promoción durante todo octubre con esta promoción así que aprovechen ese mes para ver si está en oferta alguno de los libros que les gustaría comprar.

Mi primer libro, Gestión práctica de proyectos con Scrum, fue seleccionado de nuevo hace unos días para una promoción Kindle Flash. El 5 de noviembre este libro estará durante todo el día a tan sólo 1.49€. Avisaré también en este blog unos días antes por si te interesa comprar el libro en ese momento.

Aquí tienes los enlaces a mis dos libros en Amazon:

Amazon.com
Amazon.es
Amazon.com.mx
Amazon.com
Amazon.es
Amazon.com.mx

Dudas sobre Scrum

Un lector de este blog me preguntaba hace ya algún tiempo algunas dudas que le surgían en el uso de Scrum en sus proyectos. Algunas de ellas pueden ser bastante comunes a otros equipos de Scrum o que yo mismo he tenido cuando intentaba aplicar Scrum. Aquí les pongo algunas de estas respuestas (sería la solución que yo aplicaría en los tipos de aplicaciones que conozco pero puede que no sea el mismo tipo de proyecto/equipo/producto/etc.).

¿Qué pasa cuando una historia de usuario requiere análisis que debe ser desarrollado en el propio sprint?¿el resto del equipo que no analiza se pone con otras historias de usuario del Sprint Backlog?
La historia de usuario es ya parte del análisis y debería estar bien definida y concretada cuando se va a comenzar un sprint. Es cierto que en ocasiones, cuando el equipo de trabajo comienza a realizar la tarea puede encontrarse con dudas o puntos que no tienen claro. Debería bastar con una llamada al Cliente o una breve reunión para resolverlo.
Es un punto complejo éste. Es cierto que es habitual que el desarrollo pisa al análisis y llegue la hora de desarrollar funcionalidades que aún no están bien analizadas. Para esto es bueno mantener reuniones frecuentes con el cliente para ir avanzando y concretando tareas previstas para más adelante de forma que a la hora de planificar el sprint éstas funcionalidades estén listas para comenzar. Si aún así el desarrollo sigue encontrando tareas que aún no están bien descritas quizás deba dedicarse una parte mayor del equipo a analizar y concretar estas tareas en lugar de a desarrollar.
¿Qué ocurre con un equipo que mezcla seniors y juniors con grandes diferencias salariales?¿van a empujar todos con la misma intensidad? 
Bueno, en principio, se supone que la diferencia salarial corresponde a su nivel de experiencia y saber hacer en su trabajo por lo que los junior cobran menos. Conocen aún poco sobre la tecnología o el producto y que, a medida que van aprendiendo y adquiriendo experiencia esta diferencia se acorta o desaparece.
Si algún miembro del equipo entiende que no cobra a razón de lo que está aportando es cierto que puede perder el ánimo o las ganas de trabajar. Aquí entramos en un asunto de recursos humanos en lugar de Scrum pero yo le aconsejaría que comente con sus responsables el trabajo que ha realizado y lo que ha podido aportar y vea con ellos si tienen la misma percepción sobre esto y consideran que en algún momento puede hacerse una revisión de su salario.
¿Qué ocurre cuando el Team auto-gestionado tiene que tomar una decisión técnica?¿vale igual el voto de un senior que el de un junior?
Yo no pondría valor a los votos del equipo de trabajo. A veces la mejor idea puede venir del que lleva menos tiempo en el trabajo, aunque lo habitual sea que los senior sean los que más aporten en la discusión que llevará a la decisión técnica que finalmente se tome.
Algo que he utilizado a veces es escribir en una pizarra las ventajas e inconvenientes de cada solución. A veces, nada más terminar de escribir esos pros y contras todos nos damos cuenta de cuál es la solución que más conviene ahora. Otras veces esto no está tan claro y hay que apostar por una aunque no haya consenso.

Cuidado si la opción por la que se apuesta es siempre la de ‘hay que hacerlo así ahora porque no tenemos tiempo‘. Es verdad que a veces es la solución que se debe tomar ante una urgencia. Explícale bien al equipo de trabajo el por qué de esta decisión en estos momentos pero explícale también al Cliente que ahí ha quedado un asunto por resolver que deberá ser programado para un próximo sprint si no queremos que esa deuda técnica nos acumule más errores pronto. Si no hacemos esto, con los años, el proyecto se nos puede convertir en uno de esos proyectos en los que todo el equipo de trabajo está resolviendo bugs y no nos queda tiempo para desarrollar nuevas funcionalidades.Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

 

Gestión de proyectos con Scrum entre los más vendidos en Amazon México

Durante casi todo el día de ayer mi primer libro, Gestión práctica de proyectos con Scrum, estuvo entre los más vendidos en diversas categorías de Amazon México:

  • Número 1 en la categoría Desarrollo de Software de los libros Kindle.
  • Número 1 en la categoría Desarrollo de Software de todos los libros (Kindle y papel)
Llegó a alcanzar el puesto número 739 en ventas entre todas las categorías de la tienda Kindle de México. Además, aún hoy, si se busca en Amazon México por la palabra Scrum, mis libros salen en las posiciones 1 y 5 (Certificación Professional Scrum Master). Les dejo unas imágenes de las posiciones que alcanzó:
Gestión práctica de proyectos en los más vendidos en Amazon México
Gestión práctica de proyectos número 1 en dos categorías de Amazon México
Si aún no lo has leído y te interesa comprarlo, aquí tienes los accesos a las tiendas de Amazon en las que se vende:
Amazon.com
Amazon.es
Amazon.com.mx

From Agile 101: The role of product owner

Are you sure you need a Clippy-like assistant on your app?

Many titles could be used for the person who acts as Project Director on the client’s side: the person with the product vision that the company needs, the one that represents the company in the work team. If that person belongs to the external organisation that has ordered the work, the title which fits best might be Product Owner, like in Scrum. That’s because that person literally owns it, is the “Owner” of what will be built. If this person belongs to our own organisation—someone who will represent the “client” in the project—the title normally used is Project Manager or even Business Analyst, depending on the company doing the hiring and naming. Personally, maybe because of the type of projects that I normally manage, I’m more comfortable using the title Project Director.

Whatever we decide to call these people, their contribution to a project is key to its success. They decide which features the project will have, which ones are indispensable and which ones are not. Maybe they will be the users of the final project, and thus will have a very clear idea of which elements would be key to create a useful tool that they use daily at work. However, its usefulness shouldn’t be limited to just themselves or their department, but rather it should also take into account the requirements of the whole company.

When we start a new project, the Project Director on the client’s side and the users of the final product have lots of ideas and great expectations about the new system. Sadly, no project, no matter how big it is, accommodate each and every suggestion from its users. Some ideas would be irrelevant for most users, other features might be too expensive to implement, or they would take so long to build that the project would be delayed for too long before being delivered. It’s here where the Project Director on the client’s side, who knows the market well and has a clear vision of the product, will have to prioritise the most important features and discard those that provide less value to the final product.

To explain how far-reaching the responsibilities of Project Directors are, let’s imagine the following. Our company decides to contract the development of a new airline ticketing system. In the company, they have decided that Elena will be the Product Owner or Project Director, and she will have to transmit to the chosen company all the requirements and needs that the new system must deal with.

Elena has a very clear vision of what she wants and is extremely enthusiastic about the project. So are the IT, marketing, and sales department heads, who have prepared an exhaustive list of features that the new product should include. Even in informal conversations, every day the future users of the system make new feature requests. Elena doesn’t want to miss anything important and conscientiously writes down all these requirements in a notebook.

Two months later, Elena realises that the team carrying out the work in the development company is delivering from 4 to 6 new features every week, and this seems to be their maximum capacity. She is happy with the work they are doing, but she has a problem: in her notebook she gets about 10 new feature requests every week. The list is growing and soon she will need a new notebook.

First of all, she asks the work team to double their efforts and deliver 10 features a week. Unfortunately, not many more features are delivered, and worse yet, she can tell that the quality of those features has gone down. On occasion, they even have to stop everything and correct previous deliveries. If things go on like this, frustration and stress will take over the project.

From now on, Elena must decide what should and shouldn’t be done. Not every feature will be included: at least not now. Some will have to wait for future versions. And of course, the idea of including a Clippy-style assistant to the purchase process for flight tickets will get a clear “NO.”

But, which features should she have developed first? Which criteria should she apply? Elena realises that there isn’t a direct relationship between feature cost and value added to the final project. Some features are easy to build, but some others take a very long time to develop while not actually providing a lot of value to the final product. If she asks the work team directly how many days each of those features would take, she will know what was the approximate cost would be. If she asks the users to score importance of each feature from 1 to 5, she will be able to calculate the value for her company.

If there are two features that have the same approximate cost, but one has value 1 and another one has value 3, they will clearly add the second one. If there are two features with approximately the same value for the company, but the first one would be ready in 5 days while the second one would be ready in a few hours, it’s also quite clear which one they should work on first.

Elena knows that the value and cost of each feature aren’t absolute values, but just approximations. We don’t know how much an apple weighs, but we know it’s about 5 times bigger than a strawberry and that people like the strawberry more (at least, the people who will pay for it like it more), so the strawberry would be built first. It’s an easy way to decide what provides more value, faster, to our project.

Communication is one of Elena’s main responsibilities. She must be in contact with the work team, but also with the people in her company who have something to say about the product that is being built. She has to be able to say “no” when necessary: she has to be practical in this sense, making this decision swiftly and directly. And also, she should know her business inside out, to make sure that everything that gets built will actually provide value to the company. I would say that Elena has quite a lot on her plate, don’t you think?

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

How we used Scrum in our software projects

These days I have been preparing and updating a Prezi presentation about how we used Scrum (or Agile development) in our software development projects.

You won’t find there a Scrum theory implementation but the process and methods we used to try to become more Agile (whatever that means) and to deliver software regularly and frequently (working software).

Reach the presentation at Prezi: Practical Scrum – How we used it.
or have a look at it here:

Suscríbete