Scrum Bolivia Day 2013

I'm again part of the organizing committee for the Scrum Bolivia Day 2013 conference.

Check the conference official web site or follow us on Twitter. You can also find us to Facebook

Here is the brochure for the Scrum Bolivia Day Conference, you can expect something big for 2013!

Scrum Bolivia Day 2013 brochure from Juan Banda

The Scrum Alliance is once again our sponsor, check conference info in the SA webpage

My presentation for the Agiles 2012 - Cordoba Conference

Outsourcing Agile Without Losing Agile from Juan Banda

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. 

Presentation on Agile Planning

Agile planning from Juan Banda

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.

Outsourcing Agile without Losing Agile

Experience Report Abstract

Internalizing Agile values and practices is not an easy task, many teams invest years before they can think and act as a single cohesive unit. Many others didn’t reach this point and are disbanded or deliver results below expectation. Regardless of how far in the Agile path teams are, many organizations decide to outsource^[1] part of their operations and sometimes complete projects to outsourcing providers such as companies in India and more recently to Latin America. Outsourcing comes in different flavors, staff augmentation for example is one approach commonly used to add extra muscle to a team’s development effort. Other organizations opt to outsource their quality assurance work with the view that this is a safer option. Regardless of what you decide to outsource and to where, at the end of the day you’re introducing disruption in your in-house Agile team.

This experience report seeks to contribute to your toolkit with practical advice from somebody who’s been on the other side of the phone in an outsourced Agile team. You may have heard that culture is a big challenge in a distributed team, if so this experience report has some pieces of advice that can help you overcome this limitation. More importantly, this experience report will contribute with some insights about what to expect when you plan to outsource  work and how to take two not-so-Agile teams to a level of cultural alignment that enable them to work effectively.

 

Introduction

This experience report is not about a particular project or organization, it is a collection of experiences and observations gathered by the author from working in two organizations that provided outsourcing services for software companies based in the US. The involvement in these organizations allowed the author  to be part (performing roles ranging from Scrum Master to Project Manager and Agile Coach) of more than ten teams than served more than half a dozen of clients over the last five years. All these teams and clients were different in many aspects, but all had two things in common: they were trying to outsource part of their work and they claimed to use Agile. Outsourcing operations is a task challenging enough, but how you can outsource something more intangible like Agile? This experience report provides some insight about what worked and what did not and some advice that can help facilitate future endeavours.

Culture First

You might have read and hear about culture and how important it is to understand it when you work with people from other countries. While this is tremendously important it is not the only consideration. Of greater importance is understanding the organizational culture of your future (or current) outsourcing provider.

As workers, we all perform in a small silo in which a particular subset of culture coexists within a much broader expression of local culture. Outsourcing providers put effort to create this internal culture and make it look more like the culture of client’s home countries, but here is the first problem, outsourcing providers are not matching the culture of their client’s organizations ^[2].

Matching culture is not just a matter of speaking the same language (English in this case) it must first be determined what type of culture the client has and then see if there could be some alignment with the provider’s own culture. The Schneider Model provides good foundation for assessing the type of culture of both organizations; the four quadrants in this model are ^[3]:

Collaboration	Control
Cultivation	Competence

A simplified definition of this model would state that organizations in the Control Culture are highly hierarchical and have well defined structures of power and formal procedures in place. Typically these organizations believe in chain of command and concentrate decision power (and creativity) in a few individuals.

The Collaboration Culture is different from control in the regard that its focus is on people and teams. Success for organizations with this culture depends on teams and how well they interact.

The Competence Culture corresponds to organizations that value expertise and knowledge first. These organizations try to achieve excellence by introducing new products and concepts; their focus is in being the best but not necessarily believing in teams as the key for success. Motivation for people in these organizations comes from the feeling of building something great, different and/or technologically challenging ^[4].

Lastly the Cultivation Culture is typical in organizations that believe in that teams should be grown, not only staffed. Cultivation has to do with empowering people and allowing them to experiment with different approaches; a systems of informal believes to achieve goals is also present ^[5].

Outsourcing for economic reasons is perhaps the most common reason for taking work outside your country. The author has not yet worked for a client for whom the motivation for outsourcing was to be more Agile, motivation is always related to getting more people at a lower rate. While this motivation is more than valid usually what comes next is that clients decide where and with who to outsource based on an economic decision but not on organizational cultural alignment.

Critical advice, organizations that are ready to outsource should first understand the type of culture that they have in order to look for outsourcer matching.

Outsourcing in the Control Culture

The majority of the failures seen are related to this mismatching, for instance one client was so into the control culture that its organization had a procedure for almost everything. A ticket-based tool was available and developers worked only on something that has a ticket assigned to it, conversely bug reporting also produced tickets that were prioritized and assigned. Metrics were collected from these tickets to measure productivity and release progress.

When the service provider staffed an Agile team for this client there was a mismatching because the providers team was more into the collaboration culture. It took time and resources to bring this team to understand the control mindset that was required from the client so they could work more effectively.

Standup meetings were more like reporting meetings and further managers’ meetings were held to review metrics. Reports full of data and dashboards were also produced.  Interestedly enough this client believed in Agile and followed some of the principles such as maintaining pace, using frequent delivery and prioritization based on customer benefit. However, the client culture was in the Control Culture and remained there when it outsourced part of its operations to a provider.

Another symptom of the Control Culture is the excessive desire to work on up front requirements that can be derived into a detailed plan. For the provider this translated into user stories bigger than sticky notes and with much more planning detail as can be seen in this example spread sheet:

There is nothing wrong in putting detail into user stories, and it was actually good to keep all this information updated. The problem with the Control Culture is that any changes required a lot of burocracy to be approved and eventually impacted team’s velocity. Further, the overhead of following a heavy change management process prevented the team of taking fully adventage of the Agile Principle: “Simplicity--the art of maximizing the amount of work not done--is essential”.

Maximizing resource utilization is another highly desirable goal in the Control Culture. In this case the clients management team were constantly challenging and monitoring office attendance and reported hours. Reports like these were generated:

Of course,  these reported hours did not necessarily correlate with productivity or creativity or even motivation, but from the Control Culture perspective there was value in seeing everybody punching hours constantly and at an steadily pace.

Typical with this culture is having the Scrum Master and Product Owner performed by staff on the client’s side, part of this is because both roles are attached to management positions inside the client’s hierarchy. Large number of team members is another characteristic of this Control Culture, and this is because of the upper management belief that project managers can and should effectively manage large teams.

This project was successful to a degree but it required cultural adjustment that consumed resources. The provider’s team didn’t develop or perform to all of its potential, at least not from the Agile perspective.

Outsourcing in the Competence Culture

One client had a visionary idea for a new product that would use the latest and greatest technology and be delivered in less than six months. Time to market was critical and there was a good injection of venture capital. The client decided to seriously invest in recruiting talent in the US; hiring experienced developers in different cities. Since this was a project based engagement no relocation package was provided and work from home was the standard. The outsource provider role was to staff a team of experienced quality assurance engineers.

The client’s approach to tackling a challenging project was by throwing talented resources and a highly experience and decorated manager. All team members had experience with Agile from other projects/organizations.

Again most standard Agile practices were used. For example there was a daily call in which everybody talked about what they were doing. As this was a very distributed team these calls usually took more than 30 minutes for the 10 team members. However other meetings were then introduced to coordinate more and more activity since it became evident that developers were creating code that had already written.

Integration problems were then solved by setting up a continuous integration server and introducing some procedures for preventing duplicate check-ins. However, due to the culture of competence, collaboration among developers had to be constantly promoted. Perception in the team was that everybody should prove to be the best in their field, this complicated QAs work since reported issues were extensively debated before being accepted.

The outsourced QA roles eventually also fell into this competence mode and collaboration was being replaced by trying to prove who could find the most difficult bug or who can find more bugs in a regression pass. Group metrics were not as important for our client as individual metrics, this again contributed to create more competition among team members.

Product features and innovation was promoted but highly debated since every team member wanted to leave his/her mark in the product. The Project Manager/Product Owner was focused on building a stellar product to enhance his reputation, concentrating product decisions into his hands was not symptomatic of a “command and control” mentality but more of a “I have all the knowledge” mentality. No Scrum Master was appointed since this role was not wanted by any team member.

The project ended way beyond the intended schedule and with a cost overrun; however it was a market success. By talking to the team members in the project review it was evident that the project had been very exhausting because of the competition created. Team members didn’t feel that they have been part of a team and the same was true for the client’s team in US. Technically speaking the project produced good portions of code but written by different hands and with some lack of coordination.

Even though one of the Agile Principles says “Continuous attention to technical excellence and good design enhances agility” this is referring to the aim of the whole team for technical excellence, not only for individuals and their private quest for excellence in detriment of team collaboration.

The conclusion from this experience is that outsourcing in the Competence Culture is possible but it doesn’t necessarily follow the Agile mind-set, values and practices. Even if you develop the project internally the competition created among team members is not good for helping the team to work as a single cohesive unit. Depending on individual talents can be more risky and may restrict creativity or the team’s ability to collaborate and explore different approaches with innovative ideas.

Outsourcing in the Collaboration Culture

One of a most successful projects experienced was for a client that asked the outsource provider to staff a team for him that was not full of technical experts but a group of individuals that get along together. A team was formed with team members that had been working together for years in other accounts. This team had a good mix of experience but at the same time it was very diverse in ages, gender and skills.

From the very start of the project the client was interested in knowing all the seven team members in his outsourced team. He visited on several occasions and each time he contributed to build team rapport. They had many dinners and team building activities, the result was that the client flew back home the team were constantly asked him when he was coming back. Some of our team members visited him and again the same experience, good team building activities and good team collaboration.

This process did of course consume additional resources (time and money) but it greatly contributed to foster communication and cohesion among team members. A result of this effort was that the code quality was twice that of  the previous release created by another outsourcing provider in another country; the project was also delivered three times faster. Statements made by the client.

Furthermore, the team was able to keep its pace during the whole project fulfilling this Agile Principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. The following chart shows a typical productivity report generated for this project:

During the project review the client was asked why he hadn’t tried a similar approach to build the same type of working relationship with this former outsourced team. His response was that he tried but the culture of that outsourcing provider was more like in the Control Culture with little interest in team formation and satisfaction and more oriented to process and supervision.

This project achieved the three levels of success: technical, business and personal. Both the outsourced team and the client shared a common culture that allowed both parties to develop to their full potentials. Also to support this statement is the fact that one of Agile cornerstones is teamwork and teamwork needs the right conditions to flourish, conditions that in time are enabled by having the right team mind-set. Furthermore, this experience was evidence that the Agile Principle “The best architectures, requirements, and designs emerge from self-organizing teams” can be achieved when a team is provided with the right supporting culture to let it self-organize.  

PMP vs. Agile Project Managers: Choque de Titanes

Esta es una copia de la presentación que use en la conferencia del Scrum Gathering Regional Event Buenos Aires 2012:

PMPs vs Agile Project Managers - Choque de Titanes

View more PowerPoint from Juan Banda

Management 3.0 with Jurgen Appelo

I just have been in a course with Jurgen Appelo, the author of the best seller Management 3.0 and I can tell that this has really been a refreshing experience. Jurgen is definitely a great trainer that has the ability to keep the class focused and at the same time having a good time. Thanks to Jurgen I now can say that I understand Dutch humor.

Jurgen approach to management, Agile management would be best to say, is definitely what we need in modern (or want-to-be-modern) organizations. His experiences are something that can, and perhaps should, be applied to other organizations that are still struggling with Agile.

Estare en el Scrum Gathering Regional Event Buenos Aires 2012

Presentare el tema: PMPs vs Agile Project Managers: Choque de Titanes

Este es el programa de la conferencia Scrum Gathering Regional Event Buenos Aires 2012

Scrum 100

Estas son las transparencias de la conferencia que di el pasado 20 de abril en el auditorio de la Universidad del Valle:

Scrum 100

View more PowerPoint from Juan Banda

Y estas son algunas fotos de los asistentes:

Tour Cono Sur 2011

Un poco fuera de fecha pero aqui subo la presentacion que utilice para el PMI Tour Cono Sur 2011.

Este fue el programa de la conferencia PMI Tour Cono Sur 2011 - Santa Cruz de la Sierra

Administración agil de proyectos

View more PowerPoint from Juan Banda