Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

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:

New chapter from book Agile 101: Principles Behind the Agile Manifesto

Nearly 15 years ago, in 2001, 17 software developers met in Utah. They were critical of the then popular software-development models, which they considered rigid or heavy. That meeting included people like Kent Beck, Martin Fowler or the Scrum founders. They had decided to meet in order to talk about the new techniques and processes to develop software.
That meeting gave rise to a number of principles governing the new alternative (and Agile) methods they were proposing: the Principles behind the Agile Manifesto. One of these principles is:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Clearly, this is what should be done in any type of development. We start every project with that in mind, but soon people start getting into a rush. Our director asks how many hours we’ve spent (and we’ve spent a lot already). Our client asks when all the features will be ready. Our workmates ask if they can take that two-week holiday we owe them.

It starts to look ugly. We’re in a mess again. We have to redo the Gantt chart with the new delivery deadlines, we have to look for another set of dates for those holidays (even our own holidays), and we have to give the director loads of explanations. “The client requested lots of changes” “The technology was new.” “We miscalculated.”

Here’s where we should be firm and ask the team for some extra effort, and decline little changes requested by the client. If it isn’t written exactly like that in the contract we signed or the minutes of a meeting we had six months ago, we’re sorry but we can’t do it.

The thing is, clients also did this. They wrote a very clear contract in which they stated each and every feature that they wanted (or the ones they wanted when they drafted it). Maybe they no longer needed those features or had realised that there were other, more important things, but they’re in the contract and they should be done. The project cannot end and leave 30% of undeveloped functionality.

At the moment, we have lost sight of what should be our top priority in our job: early and continuous delivery of valuable software. From here on, there are just tough negotiations and a contract that we would try to fulfil as soon as possible with the least amount of damage possible.

The contract might have tonnes of clauses and stipulations, but regardless of what it says, what the client wanted on signing it was a solution to the problem at hand, not an argument about whether to implement one functionality or another.

But if we deliver our software early and often, we can let clients test it and use it and tell us what they think. We can allow them tell us if there is something missing or what could be improved. They will want us to implement things they find they now need, and they will be delighted in turn to take out that .rpt file-exporting feature that no one remembers requesting or knows why it was requested in the first place.

When we finish the project, the client will have a product that really solves their problems, one that has been evolving while they learned, and one that they have been able to use and test from the early stages of the project. It sounds better for both the provider and the client, right?

New chapter from Antonio Martel's book, Agile 101: Principles Behind the Agile Manifesto
 “How do you
manage a project when you have received no previous training in project
management? Well, by suffering a lot.”
Albert Cubeles

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.

Agile 101 book

Pretty soon my first book on Agility will be also available in a new English edition. You will be able to find there same contents and same topics that were addressed at the Spanish edition or that you can find here in my blog but ready for English speakers:

  • Scrum pros and cons
  • Agile estimations with Scrum
  • Help and hints to pass your Professional Scrum Master (PSM I) Certification test.
  • Real life projects experience and practical know-how on how to deal with situations that we all have gone through any time in our professional lifes.
I leave you here with the foreword of this brand new edition (translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt):

“Extra! Extra! New edition Agile 101. Read all about it”


Your company has just appointed you project manager. You’ve heard about Agile methodologies, Scrum, Kanban, and lots of other things you’d like to try. You’ve started reading all about artifacts, principles, and manifestos, but nothing is crystal clear just yet.

You don’t know whether your lack of knowledge will put your project at risk, but probably what worries you the most is that all these things are nothing but buzzwords, the current fad, and that they won’t have any real effect on your day-to-day work… or even worse, that such a big change in what to call things and how to do them will make your team, your clients, and your company reject those ideas altogether. Luckily for me, or unluckily maybe, I have also gone through all these problems, so in this book I will tell you how I solved them (when I’ve been able to) or, at least, what I tried and what eventually failed.

Don’t expect this document to be an exhaustive Scrum guide. I don’t know everything about Scrum, and the implementation I follow is far from perfect. For a thorough knowledge of Scrum, I recommend following some of the popular Scrum guides that you can find either online or in books like the one by Henrik Kniberg, not to mention the one by Jeff Sutherland, creator of Scrum.

Even though I follow a survival Scrum style and I still have lots to improve, Scrum has worked for me. Using it, we have managed to gain credibility in difficult projects, projects that were not working the way we expected. We managed to reduce the amount of stressful situations that, luckily, now happen far less often, and we have increased the satisfaction of the clients who, sprint after sprint, get their money’s worth. We have not been able to follow Scrum methodologies to the letter in every project we have worked on, but just trying to be more Agile we have improved our results in the projects we are working on.

When we start using Scrum, we all tend to use the terminology of this framework, talking about daily sprint meetings, product backlogs or burndown charts. We follow our Scrum guides to a tee, when in fact no one understands them, not even ourselves. Not understanding the spirit behind these rules, we end up creating a waterfall project—like we always have done—disguised by jargon that makes us look more innovative.

Rather than telling you how to do things, or explaining in detail how many meetings you should have and how many minutes each one should last, in this book I want to describe what the purpose is behind those meetings, what the artifacts described in Scrum guides are for, and what you might get out of them. I’ll help you understand the Agile principles that underlie this way of working and that really make this work. I hope you find this book very useful!

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

Scrum en la práctica: Cómo lo usamos en DESIC

La semana pasada publicaba un prezi con una introducción al uso que dábamos a Scrum en DESIC. Esta semana les dejo con el enlace a una segunda presentación en la que concretamos con algo más de detalle cómo usamos Scrum en el trabajo diario en DESIC:

  • Cómo hacemos los tests
  • Cómo planificamos los sprints
  • Cómo ha sido el proceso hasta llegar a la versión de Scrum que utilizamos actualmente y qué nuevas automatizaciones queremos incorporar.
Tienen acceso a la presentación aquí: Scrum en la práctica: Cómo lo usamos en DESIC.
Scrum en la práctica: Cómo lo usamos en DESIC - Antonio Martel

Qué certificación agile elegir: ventajas y desventajas

También me preguntan de cuando en cuando me preguntan a través del blog qué certificación ágil es la más valorada o cuál es la que más les conviene para acceder a un puesto de Scrum Master o Product Owner.

Actualmente, las tres más importantes son Professional Scrum Master (PSM) de Scrum.org, Certified Scrum Master (CSM) de Scrum Alliance y Agile Certified Professional (PMI-ACP) de PMI (los mismos de la certificación PMP).

Las dos primeras tienen su origen en la misma persona, Ken Schwaber. Ken es uno de los creadores de Scrum, que junto con Jeff Sutherland, definió las versiones iniciales de Scrum que presentaron juntos formalmente en la OOPSLA del 95.

Juntos crearon también la organización Scrum Alliance en la que comenzaron a certificar profesionales de Scrum con la certificación CSM.

En 2010, Ken decide dejar la Scrum Alliance y fundar el instituto scrum.org para intentar orientarlo más hacia el objetivo de divulgar Scrum. Desde este nuevo instituto (scrum.org) se comenzaron a entregar las certificaciones PSM. Desde 2012 hay también un nuevo competidor en liza, la certificación PMI-ACP que está sonando bastante fuerte desde entonces.

Comparativa entre las certificaciones ágiles

  • PMP. Test sólo online. Coste 150 dólares. 80 preguntas en inglés a resolver en 60 minutos. Necesario tener un 85% de preguntas correctas. El certificado no expira.
  • CSM. Antes del examen debes tomar un curso de dos días cuyo coste puede rondar entre los 1000 y los 2000 dólares. Luego un test presencial de 35 preguntas (en 2012) de las que tendrás que acertar 24. Al parecer no es complejo. Deberás renovar el certificado cada dos años aportando 100 dólares y, a partir de 2015, un cierto número de SEUs (algo equivalente a las PDU de PMI).
  • PMI-ACP. Se requieren 1500 horas de experiencia ágil previa y 21 horas de un curso de formación ágil en cualquier institución que te lo certifique. Test de 120 preguntas en un centro Prometric. El certificado debe renovarse cada tres años para lo que se debe obtener 30 PDUs nuevos en gestión de proyectos (1 PDU equivale a una hora de formación o actividad profesional).

Qué certificación ágil elegir

Esto depende de muchos factores: Cuál es la más valorada en el sector en el que trabajar, la facilidad o no de acceder a un curso de preparación, tu disponibilidad de tiempo o dinero o los conocimientos previos sobre Scrum que tengas.

Probablemente PMI-ACP o CSM sean más valoradas actualmente que Professional Scrum Master pero te cuento los criterios por los que yo aposté por esta última (PSM I):

  • PSM I es una de las tres certificaciones principales. Está respaldada por uno de los fundadores de Scrum y lleva tiempo en liza por lo que a la hora de pedir una certificación Scrum es siempre una de las requeridas.
  • Viviendo lejos de alguna de las ciudades más importantes era difícil para mí tomar un curso de preparación para CSM o para pasar un test en un centro Prometric. Al coste del certificado se requeriría añadir el de los billetes de avión o la estancia de una o dos noches de hotel.
  • El tiempo de preparación es más bajo para PSM que para PMI-ACP que también me habría requerido tomar algún otro curso de gestión de proyectos y gestionar con PMI los PDUs que obtuviera.

Teniendo todo esto en cuenta e intentado ser ágil en la toma de decisiones (como un Product Owner priorizando su backlog) la respuesta era clara para mí. Con PSM I iba a obtener probablemente un 80% de los beneficios de cualquiera de las otras dos certificaciones pero a un coste en tiempo y dinero mucho menor. Además el tiempo en recuperar mi inversión era mucho más bajo. Así que desde 2013 estoy certificado como PSM I.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Referencias:

Suscríbete