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:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
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?
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.
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:
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).
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:
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.
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):
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:
