Finding the Right Balance: Merging the Project Managers and Agile Practitioners in a Common-Collaborative World

Agile details may not be important for the top management as the classical project approaches may not be relevant to the Agile practitioners. But, are they really so incompatible as we think?

I think that one of the best ways to think about this discussion is going back on the origin of both approaches and understand what they have been originally designed for.

Project Management as a Science

My understand of Project Management is that it derivates from the Business Administration area. Modern Project Management had a strong growing during the Industrial revolution and World War II, but we have records of the concepts of project management being used many centuries back. As projects grew on complexity and costs, new processes and tools were required to measure them and avoid them to fail.

Let's consider the most common framework, the PMBoK, maintained by the PMI (Project Management Institute). The PMBoK is not a framework, but a set of best practices that must be customized to fulfill the needs of each implementing organization. It was first published in 1983 so, it is not a surprise that it relies on classical approaches of business planning and organization, which may, in some cases, be not suitable for nowadays business needs, although it is regularly updated and bring excellent tools and techniques that are currently fresh. It is still the most respected reference in project management. Of course, other approaches such as PRINCE2 exists, but their objective is basically the same.

The main complains on classical approaches relies on the excess of bureaucracy, controls, disciplines and unrealistic schedules that are planned in the beginning of the project and forgot during the rest of the project lifecycle. Sooner in this article, we return to this topic.

Agile Approach

Agile approaches are newer, dating from early 2000's and were born in the software development industry, as a way to escape from the excess of processes and documentation that usually overwhelm the developers and analysts with process and put the coding, tests and user participation as a mere detail in the deliveries. Other approaches were developed based on those principles, but I'll try to keep agnostic to methods and focus on "Agile" spirit.

The confusion and misunderstands of concepts begins, in my very humble opinion, here. Let's take a look at the Agile Manifesto, the cornerstone of the Agile methods, that established the main concepts of it and try to destroy some misunderstandings:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Please, observe that I highlighted the word "Over". There is a clear reason for that. When the Agile Manifesto states "something over another" it does not mean "something ANULATES another". It means that the importance of Interactions, Working Software, Customer Collaboration and change response MUST BE prioritized during the development lifecycle (keep in mind that we are still talking about software development here. We will talk on how this relates to project management soon). It is VERY IMPORTANT to highlight that Agile does not suggest, imply or impose - in any moment - the elimination of documents, processes and planning. This is a common misunderstanding that may sink the Agile implementation in its beginning.

So, what about documents and processes? Well, they need to exist. Formalization is required, as a reference and also legally, when we establish a commercial relationship. But, we need to understand that they are not the essence of the work. They are tools to (i) facilitate the work between teams and tools and (ii) keep a record and history of development for future maintenances, upgrades and improvements.

Complex softwares must not depend only upon comments on code. Sometimes, a more consistent documentation is required. The main question that the Agile raises here is: Are we software developers or instruction manual writers?

And, when we talk about software development, it makes totally sense. When you spend 25% of you time coding and debugging and 75% documenting, something is very wrong. It may be the company process that is too bureaucratic, the development tools and environment that may be not friendly or something in the middle of both.

Applying Agile concepts in the software industry are presenting good results: Taking some figures from Brazil, in 2011 42% of the Agile-developed software were successful, against 14% of the traditional-developed softwares (see the details in Portuguese). A more recent statistic from Standish Group Chaos Report states that Agile Software development are twice successful than the traditional based ones (see the study here). And it is easy to explain: Taking out from the technicians a workload that, for them, are not valuable, make them concentrate in what is important: Develop and look after solutions.

Projects: A more complex monster to feed

Software development is a part of a project. Usually, a project is something bigger (ok, it may be a software-development project) but it hardly escapes from interfacing with supporting areas (Compliance, Legal, Finance, HR, Logistics, C-Level...)

Here the collision of the two worlds start to be clearer: Many business areas are not interested in Kanbans, Sprints, Stand-up meetings and post-its. They simply want to provide information so IT guys crunch it into something that they want. Many business think this words and concepts are not for them and don't want to waste time on this.

C-Level members and Financial Planning wants something realistic to prepare their budgets and long-term strategic plans. Try to explain to your CEO that you still not have all the sprints planned for the following deliveries and that the backlog is still being prioritized, which may also cause delays in providing a consistent budget. If the CFO is present the meeting may get a little more tense...

The other side also exists. When you rely on a inflexible, over-controlled, over-disciplined and bureaucratic portfolio and project management office, both C-Level and business areas may get angry at you because you simply can't change the priorities of the companies without engaging a meeting with 20 different people, that will ask thousands of different questions, that will lead to other three different meetings. After most of the people have agreed, that priorities have changed... again!

But it does not mean that we can't mix-up the best of the two worlds and create a hybrid approach.

Balancing things up

How to put traditional Project Managers and Agile Practitioners to work together and taking the advantage of the best of the two world?

My first thought on this is that both roles are still important. The Agile daily activities are very dynamic and needs responses quickly. Sometimes, the Scrum Master must be focused on his team and activities and will not have time to deal with the details of the legal department or with logistics delays. Also, he may not have the required soft-skills to deal with some specificities of the business, what may cause some damages during the way.

Also, project managers may have a more open transit between the different levels of the company. They can make use of their influence and relationship to facilitate the work of the Agile project teams, bringing them the responses and escalating issues that the Agile teams are not able to solve, by resistance of the Product Owner, Sponsor or other external event.

Project Managers are also used to deal with uncertainty. They may support the Agile teams on translating their uncertainties in estimations based on assumptions and risks probabilities, what will surely give to the top management a more clear view on the risks and the mitigative actions to be taken.

Reporting: Translating Agile into a business-palatable language

Burn-out charts, Epics and Sprints burn-down, Control charts... all of them are essential to measure the performance of the project evolution on the project team. They allow the team to take quick correction courses, reprioritize things-up and reorganize themselves in the spirit of self-management, so strong in the Agile groups.

But, if you try to show this in a Project Steering Committee with a C-Level group, they will probably not care about the amazing results. They want to know, basically: Time-to-market (are we on track?), Budget (are we spending to much?) and Features (are we delivering what we have committed to our shareholders/customers?)

Project Managers have the communication skills in their DNA (or, they should have!). Consolidate information, create graphics, messages, classify information monitoring risks, issues, escalating, engaging... those tasks are trivial for them and they do it very well. Also, due to the characteristics of their job, they usually understand things very quickly and translate it into a very clear business language.

Also, applying some concepts of lean-PMO, reviewing the required documentation load for Agile projects, usually working with Architecture and Engineering teams, may create useful and concise reports (not unnecessary piles of paper or gigabytes of useless information). The same applies for Financial reports: Project Managers can easily help translate the expenses and planned resources in more realistic reports, making the Financial Planning team happy!

Having a well engaged Scrum Master, Product Owner and Project Manager team may add a competitive differential in your Agile organization.

Do not trash your resources!! Adapt them!

Both Agile and Classical outputs are useful and applicable in the organization. The secret is how to extract the best information from both of them and show the right data to the right people in the right occasion. It is possible to translate the sprints planning into a schedule, although it demands a close control of it (c'mon, project managers: you already do it... daily, I hope. Just do it with you Scrum Master now!)

Issues and risks logs still need to exist. They are more dynamical, but still essential. Project Status Reports must exist to keep the organization informed. But it must address the essential information, focusing the sprints deliveries and users engagement.

The differential here is the frequency. How many times a day those checks must be performed? The PM must join the daily meetings? How will be his dynamic in those meetings?

The constant analysis of both set of techniques and tools is required to keep a hybrid model updated. Scaling Agile tools and traditional PM tools into your company's project management framework may add up some boost in your project management environment.

The Magic Formula!!

There is no magical formula. When you read the PMBoK, the book highlights every now and then that "This is not a manual. You need to understand your needs and make the correct customizations". The same applies here: Organizations are living entities; they have their own dynamics, their own cultures, ethics and behaviors. How, when and what you are going to deploy depends a lot on and deep environmental analysis. And this is another point where the Project Manager can help. He knows the organization assets enough to provide good advices on the way to go.

Collaborate: That's the spirit!

Both Agile Practitioners and Project Managers can benefit from the knowledge of each other. It is common to see an embate between what is better: Agile or Waterfall, as if we were discussing what programming language is better, what in the best video-game console or what is the best soccer team. The best for you - in all the prior examples - is what works for you and for your company. But, when you have the opportunity to mix-up a bit of different flavors in the same recipe, you may achieve an unexpected result - that may be amazing! The competition, in my opinion, is not "what is the best" but "what is the best mix".

One thing that is undeniable: Project Management discipline, as we know it, is changing. It will not desapear but many of the tools and techniques that we rely nowadays will surely change drastically. When we collaborate merging concepts of both sides, we may be writing a new chapter in this discipline. We may be developing the new "best practices" that may become viral and begins anywhere, from a startup in Argentina to a multinational in Germany.

Believe me: When we work together, results are amazing! Sharing the knowledge between the traditional and the new may come-up with new tools and techniques.

And, after all, isn't it what Agile is all about?