My review for the book: Agile Project Management For Government

I've been privileged to ask for a review for the recently printed book Agile Project Management For Government written by Brian Wernham. My initial thought was that this was just another book about Agile Project Management complemented with some study cases for government agencies, I was totally mistaken, this is indeed a great book that covers real case studies in several countries and for very large implementations like the FBI Sentinel project.

These case studies just provoke the reader and keep him/her interested for reading the rest of the great material that this book has to offer. It's no secret the great expenditure of tax money that governments put to backup IT projects but what these cases studies made more than evident is that money is not the only enabler. On the same venue, well founded government projects are lacking agility and that is hindering their ability to deliver value.

This book provides hope for all those government projects and actors that can turn they look into more efficient ways for working close to the end user and deliver incrementally usable products. Much transformation is needed inside government officials and IT departments and for that this book offer nine Agile Leadership Behavior closely aligned to the Agile Manifesto. These behaviors if successfully implemented could turn disastrous projects into successful ones; what is even more important, government IT personnel can also deliver high quality software in shorter periods of time like their cousins in the IT private sector are already doing.

The big caveat is the rigid and bureaucratic structure that many governments enforce in their ranks. Brian did a great job describing 6 barriers that prevent Agile from success in government IT projects.  The mega-project mania really caught my attention because we're so accustomed to think that everything that governments do come in mammoth size. Smaller, faster and better seems to have been lost for the sake of complexity; this book does a great job remind us all that there is excellence in simplicity and light weight methods.

Five years from now I think that this book will still be in my bookshelf as a key reference book. What is even more important, people who have read this book would have delivered successful projects produced in an energizing work environment enabled by Agile principles and values. 

PMP®s vs Agile Project Managers: Clash of the Titans

Introduction

 

To the casual observer, a PMP® is in one corner and in the opposite corner we have an Agile Project Manager. This seems to be the situation because both advocate different visions of how to run a project, and even different concepts about what a project really is. The PMBOK® has been mainstream for years in project management, but in the last decade Agile gained more popularity and now seems to be ready to challenge the champion for the belt. But is it really true that these two are opposed, or would it be possible to find common ground? Don’t miss this fight that doesn’t promise knockouts but instead may go the distance.

Introducing the Opponents

 

For a PMP®, a project is basically control and detail planning; "plan the work and work the plan". Schedule, resources, risks and other competing constraints are evaluated, measured and specially controlled. Reactions to risks are not spontaneous, but rather come from a risk plan already elaborated. The principle does not sound bad and it has worked very well in various engineering fields. Proof of this are the bridges, pipelines and refineries built under the wise leadership of notable PMP®s.

But, and here is the big but, what happens when you cannot plan everything at the start or when the plan is too costly to maintain? Or what happens when you cannot know all the scope in advance? A PMP® simple answer would be, "for that we have rolling wave planning and that’s Agile enough".

On the other side of the ring we have the Agile prophets who say that they can lead complex projects with values, post-its and especially empowering people. That does not sound too bad either but who will be responsible for hiring, performance evaluations, procurement, contracts, budgets and other "insignificant" project matters?

Round 1 – PMP®s Attacking

 

Having competing constraints under control and identifying all risk in a project is definitely not a bad thing to have. Even knowing in advance the scope and freezing it would be a perfect thing in a project. Monitoring a project based on simple indicators that provide solid data is also another great thing to have. All this is not utopia, it actually happens in many large projects with large number of resources attached.

C-level executives making informed decisions based on solid data professionally compiled, analyzed and presented by capable PMP®s is also not utopia. For instance, oil and construction companies around the world have reported very successful experiences by running projects following the guidelines described on the PMBOK® framework.

Still, something seems not to be adding up. Oil and construction projects are large and complicated but not necessarily complex in nature. Software development projects on the other hand belong to a much more complex knowledge domain.

Round 2 – Agile Project Managers Defending and Counter-Attacking

 

PMP®s around the world recognize that one key factor in all projects is communication. And here is where Scrum with its team-centric approach has something better to offer. Tackling complex problems with empowered teams thinking creatively seems not have a rival in the PMBOK® process.

Agile Project Managers do a great job cultivating their teams and fostering communication and Agile values. They play a vital role helping their teams and organizations to transform to Agile. Things become tricky though when Agile organizations become bigger and bigger and more projects are added and team members are counted by dozens. Project areas like procurement or staffing, for instance, are not likely to be attended to by an empowered developer.

It can be inferred then that, even though Agile values and principles live in an organization and Scrum found a home in the heart and soul of team members, still someone needs to take care of some other project aspects.

Round 3 – Locking for the Knockout Punch

 

Successful PMP®s with years of experience managing multi-million dollar projects can be driven crazy by the all-the-time-changing-requirements environment of an IT project. Of course, a prescriptive approach like creating all the plans that the PMBOK® recommends can be taken. But this approach is doomed to fail due to the complex nature of software development projects. Adaptability and Agility seems to be the only way to cope with the changing requirements. But are the PMP® mindsets ready for these?

By the same token, PMP®s tend to look at communication as a process that can be formalized, monitored and even regulated. In a complex-knowledge domain, teams are cultivated. And communication occurs spontaneously with no barriers or hierarchies to prevent it.

The knockout punch from the PMP side tries to come from the side of prescription and emphasis in planning, monitoring and specially controlling.

In the other corner Agile Project Managers believe in the values and principles that they help their teams to cultivate. These values in time help team members to interact in such a way that a positive synergy is created. Still, some important areas of a project are running unattended because projects are not just about team members, technology and client’s requirements.

Scrum as a framework was not thought out as a complete instrument for attending to all project aspects. As light a framework as it is, Scrum is not equipped to deal with project aspects that require interfacing with other areas of the organization, client organization or third party organizations. Crucial aspects like watching the budget are things that cannot be ignored for the sake of keeping Scrum pure in its form.

The Agile side attacks back with a knockout punch that in reality is no punch but Agility to dodge punches and throw debilitating small punches.

Going the Distance

 

Good project managers on both sides need to recognize that the selected framework is just the vehicle for the ultimate goal of having a successful project at four levels: commercial, financial, technical and personal.

Frequently enough PMP®s fail to understand that Scrum as a framework is not about process and mechanics, but about values and mindset. This failure in understanding usually causes dysfunction and suboptimal results, if not complete project failure, in the attempt to adopt Scrum. The problem again seems to be in the oversimplified vision of a project that can be conceived-of only as a collection of processes and plans. Planning is indeed an important aspect of Scrum, but inspection & adaption, transparency, values and especially people are considered more important.

Agile Project Managers should also consider that they still need to somehow manage some portions of the projects, not necessarily people but processes to keep the project running. Not paying attention to anything but the team and Agile could create a bubble that might burst at any moment.

PMP®s can become Agile Project Managers, but this is not simply a matter of changing titles. A deeper transformation is required. As this transformation occurs, no one says that a PMP® needs to forget about the processes required to support the project. It is just that their mindset needs to be open enough to find the right balance. Needless to say, the command-and-control mentality has to go away to be replaced by openness and a trust-the-team mentality. That mentality has to transform, but the PMP®s’ other skills can still find their uses to support projects, as “adapters” to effectively interface between teams and the bigger organization.

Agile Project Managers can also take the time and energy to learn about the PMBOK®. There’s Agility there if we look carefully and with a very receptive mind.

One Japanese proverb says that “there is no small opponent, only small thinking” and small thinking is what might lead us to think that either PMP®s or Agile Project Managers have discovered the silver bullet approach for project management. Both approaches have something to contribute if rivals are ready to hear the other side and add the other’s lessons into their own toolkit.

Administración Agil de Proyectos

Resumen

Este artículo pretende atraer la mirada hacia el enfoque ágil de administración de proyectos que se ha venido utilizando con éxito desde hace más de una década en la administración de proyectos de desarrollo de software. Este enfoque se basa en la inspección y la adaptación continua de las tareas, procesos y buenas prácticas de interacción humana. La autogestión y el enfoque hacia tareas con alto valor para el cliente final son también componentes fundamentales de este paradigma.

Introducción
El campo de desarrollo de software es intrínsecamente complejo por los requerimientos cambiantes y poco tangibles, se suma a esto el alto grado de creatividad e innovación necesaria a la hora de construir software. En esencia los requerimientos son cambiantes porque los clientes en general no pueden definir por completo sus necesidades y porque estas van cambiando de acuerdo con las prioridades de la empresa y el rubro donde esta se desenvuelven.

Más aún, en este rubro alternativas como añadir más ingenieros a un proyecto o alargar la jornada laboral no garantizan en ningún caso que un proyecto pueda reencaminarse o siquiera terminarse.
Controlar los cambios a través de un proceso rígido de control de cambios tampoco es una alternativa pues genera excesiva documentación y burocracia. Así por ejemplo empresas con productos en la web no pueden darse el lujo de rechazar cambios o demorarse demasiado en implementarlos pues sus competidores podrían tomar ventaja si responden con mayor dinamismo.

De lo Predictivo a lo Adaptativo

Procesos tradicionales que tratan de estandarizar actividades que en esencia son creativas no funcionaron para este rubro particular. Enfoques como definir a máximo detalle y estandarizar procesos no tuvieron éxito porque simplemente cada proyecto es diferente en términos de tecnología, complejidad, interrelación y requerimientos. La creatividad que fluye en un equipo con ciertos individuos y en cierto proyecto particular es difícilmente medida, estudiada y replicada. Por el contrario, se buscaron alternativas como la “agilidad” que permite pasar de un enfoque predictivo a un enfoque adaptativo.

Dentro de este nuevo paradigma se reemplaza el enfoque que plantea la división del ciclo de vida del proyecto en fases bien marcadas y con actividades preestablecidas, por iteraciones cortas orientadas a tener productos tangibles al final de las mismas. Estas iteraciones cortas son precisamente micro-ciclos de vida que se desarrollan de principio a fin y que apuntan a construir un producto en incrementos finitos.

Al final de cada incremento finito se tiene una demostración para clientes reales de la funcionalidad implementada. Esta demostración es la que provee las entradas para adaptar el producto y encaminar mejor la siguiente iteración. Por su parte, el equipo de trabajo dentro de la iteración se auto-inspecciona constantemente y va adaptando sus prácticas y procesos para llegar a producir un producto con valor y calidad al final de cada iteración.

Enfoque en el Valor, no en las Tareas
Mucho del éxito del enfoque ágil de administración de proyectos proviene de minimizar la cantidad de trabajo innecesario que conduce a completar tareas que no contribuyen o contribuyen muy poco a agregarle valor al producto final. El valor es considerado no desde la perspectiva técnica de quienes construyen el producto sino desde la perspectiva de negocio de los clientes finales.

Priorizar tareas es clave dentro de este enfoque, la priorización se realiza tanto al inicio del proyecto como al final de da iteración. De hecho el proceso de control de cambios permite que nuevos requerimientos sean ingresados aún tarde en el desarrollo del proyecto pero estos no serán atendidos hasta que no se termine la iteración actual y hasta que hayan sido adecuadamente priorizados.

La forma en la cual se evita el scope creep consiste no en rechazar requerimientos sino más bien en aceptarlos pero manteniendo en todo momento una lista priorizada de requerimientos con alto valor para el cliente y que pueden ser implementados considerando la velocidad del equipo.

La documentación que acompaña a un proyecto es generada y mantenida siempre y cuando esta aporte valor al cliente final. Esta práctica permite liberar tiempo y recursos tradicionalmente destinados a estas tareas y reasignarlos a tareas que aporten mayor valor para el cliente.

El valor para el cliente es aparentemente difícil de medir en un producto intangible como el software, pero en la práctica las técnicas de análisis de negocios permiten cuantificar, medir y extrapolar no solo el valor de una característica para un cliente sino para una comunidad de clientes finales.

Los Principios Agiles
La agilidad se funda en los principios básicos planteados por el “Manifiesto Ágil” a los cuales se suman modelos de administración ágil de proyectos y marcos de trabajo para equipos multidisciplinarios.

Los principios del citado manifiesto se basan en pilares como el cambio de énfasis de los procesos y herramientas hacia los individuos y la interacción entre ellos. Esto viene de la mano de conceptos tales como empoderamiento del equipo y autogestión.

Se incorpora también el pragmatismo que apunta a tener software funcionando y de utilidad para el cliente final en lugar de documentos de diseño extensivos.

Un tercer pilar habla de la incorporación de los clientes en el proceso de construcción del producto, incorporación que es factible ya que al final de cada iteración el equipo puede tener un producto tangible (más no terminado) que puede mostrar para recolectar mejores requerimientos y retroalimentación. Este punto es de vital importancia ya que durante décadas se trató sin éxito de relevar requerimientos con diagramas y otros artefactos cuando en realidad lo más efectivo es acercar al cliente al producto que este espera tener como resultado de su inversión en el proyecto.

El cuarto y último pilar del Manifiesto Ágil tiene que ver con la adaptabilidad, es decir con la capacidad intelectual, organizativa, motivacional y creativa que debe tener un equipo para poder responder a los cambios inherentes al proyecto y reajustar su horizonte sin perder de vista que el objetivo final de sacar un producto al mercado con valor para los clientes.

Conclusiones

Los principios de la agilidad y la administración ágil pueden ser extensibles a otros campos de la ingeniería. Por ejemplo empresas como 3M o Nokia donde la innovación constante es fomentada, vienen aplicando estos principios desde hace bastante tiempo y con resultados por demás exitosos. Inclusive rubros en los cuales el trabajo repetitivo requiera poca invención pueden beneficiarse del enfoque de mejora continua (kaizen) que traen consigo las iteraciones.

Referencias
• Agile Project Management: Creating Innovative Products, Jim Highsmith, 2004
• Agile Project Management with Scrum, Ken Schwaber, 2004
• The Software Project Manager's Bridge to Agility, Michele Sliger and Stacia Broderick, 2008
• El Manifesto Ágil http://www.agilemanifesto.org/iso/es/
• International Institute of Business Analysis http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx
• Scrum Alliance http://www.scrumalliance.org

Las transaparencias que use para esta presentacion pueden encontrarse en este link http://percella.com/administracion-agil-de-proyecto/