The world of today is volatile, with complexities rising and ambiguity increasingly present. Agility has often been proposed as a manner of dealing with this new context, but hasn’t always proven to be an easy solution: there’s plenty of issues with agile implementations that are behaving sub-par.

One of the key reasons for this is culture. Examples are the adoption of bad practices leading to lowered productivity, employees playing the blame game and leading to poor innovative practices within the company, hostile company culture and working environments where people see work as an us-versus-them story.

Another reason for agile failure is a mismatch of agile between different agile teams, or between agile teams already having made the transition, and teams yet to move towards the new way of working. A mismatch in cadence appears, with teams moving at different speeds. Differing speeds or paces of delivery isn’t necessarily an issue (often, teams will work at varying speeds regardless of the way of working), but matching rhythms and aligning key points in each process is crucial to be ensure work is processed and transferred smoothly, downtime is reduced to a minimum and expectations are set for all stakeholders involved.

Similarly, a mix of agile and non-agile (or rather: not-yet-agile) teams can lead to a misalignment in terms of goals and the approach, with iterative development processes being intertwined with waterfall projects. Both require a different communication style and can lead to conflict in end user expectations.

A third reason for troublesome agile adoption is going too far in the iterative direction – promoting short-sighted, easy and quick decisions over more long-term thinking. Both disciplines have their value and should be used at appropriate times – a product owner plays a big role in maintaining the project’s vision and keep a helicopter view of all work to be done. Lack of long-term vision, or too heavy emphasis on short-term decision making will lead to an increase in technical debt: effort required to completely finish work, after having cut corners because the quick way of doing things prevailed over the right way to doing things.

The problem with creating technical debt is that we’re effectively borrowing against the future team capacity: this work will need to be done to do things right (as opposed to doing things fast and attaining a for a faster time to market). Someone will need to spend effort on technical debt, and that time will not be spent on doing other tasks – or work that might bring more value to the business.

Last, but not least, we need to emphasize the big difference between working agile, and actually bringing value. Unlike life’s hard thought lessons, the business world does not place more value on the journey over the destination. Businesses thrive on results, not just processes. Similarly, you can have teams perfectly implementing agile that might not be doing anything worthwhile in terms of business value. The key is to always keep the business in mind, focus on value and make sure your agile process is in support of the value delivered to the business. Don’t just implement agile for the sake of implementing agile.

A new paradigm for project managers in agile environments

But what does this mean for project management professionals – are we all out of a job once everyone implemented agile?

The answer is not as easy as it may seem. We’ve touched on the topic before and came to the conclusion that project managers still have their place in agile environments, but that a different discussion should take place on the actual job description these experts are trying to fulfill.  Similarly, when reflecting on the meaning of the challenges we just described, we can distill the following recommendations for project managers submersing themselves in new, agile waters.

Focus on value

A first recommendation reflect on the need to focus on value for the customer. This means that project managers will be required to steer on the quality of deliverables, not only in terms of adherence to specifications and briefs, but also to value required by the client. In a way, we’re moving away from the traditional constraints of time, scope and resources and moving towards a model where value is delivered by managing the flow of value throughout all processes. By leveraging techniques like epics, stories and the product backlog for managing scope, continuous delivery or integration for setting the pace of delivery and product teams for managing resources agile hopes to increase time-to-market, innovative capacities and end-user satisfaction. Of course, with costs managed as work now flows through teams (or release trains), not the other way around.

New requirements

A second recommendation holds a mirror to the role of project manager in terms of job requirements. As the way of working changes, some disciplines will replace previously-learned ones and responsibilities will change.

• Support the agile team’s mission instead of accurately planning project tasks and managing resources. Remember, work flows through the team, teams aren’t assembled around work.
• Remove impediments for the team, instead of tracking actual versus planned. Most teams will be fixed, hence costs will be in check at all times. Instead of checking how much gas we’ve used, the agile project manager should ensure the engine keeps running as smoothly and efficiently as possibly.
• Keep stakeholders on the same track, ensure communication is up to an appropriate level between all parties and teams involved and act as a liaison, instead of reporting to senior management on the team’s performance.
• Strengthen the team’s ability to navigate risk and ambiguity in today’s world, instead of focusing of trying to remove risk in favor of certainty.
• Facilitate the team in improving and working together, enable them to make the right choices and do the right things right. Don’t rely on micro-management and control.
• Lead by example in applying agile principles and values, instead of adopting Prince2 or PMI methodologies.

Soothe the organization’s pains

Third, the project manager will be working in an organization new to agile, and have to navigate all the growing pains that come with it. Just as project managers will have to adapt, organizations will have to as a whole.

The key is that project focus will be abandoned in favor of product focus. Funding will need to be provided for the lifetime of a product to ensure product teams are staffed and nourished. Previously, funding was allocated on a per-project basis, ending as the product was delivered. Keeping the product team alive will require a paradigm shift that work and funding for a product will stop only when the product is decommissioned or retired. Though, of course, product teams can change during the product life cycle.

Shifting from projects following a project plan to products iteratively developed required a shift in appetite for change, shifting from change avoidance to embracing change. After all, as products evolve and features are introduced, new and practical insights can lead to change requests as product teams better understand how to serve their end users.

Returning to the “focus on business value” mantra, we’re also happy to say that projects should no longer care be tracked by variance in scope, time or resources – instead, you’ll need to deliver on… right, business value. Instead of reprimanding projects for going over budget or taking more time (both hard to avoid in volatile times), projects will be given the awkward eye when work isn’t delivering what it should.

Keep things moving

As mentioned earlier, teams will often move at different speeds. That’s not too out of the ordinary – teams are made up out of different individuals, with different skill sets and experiences, and are working on different products. The trick is to aligning team cadences. The key here is that this should be a s loosely an alignment as possible – the principle of loose coupling should be applied whenever possible, to avoid one team with impediments or challenging changes slowing down an entire value chain. As an agile project manager, this means trying to identify these critical hot spots as early on as possible by aligning with stakeholders to identify dependencies between teams. You’ll never be able to avoid dependencies, as not everything can be loosely coupled, but remain vigilant about dependencies emerging and make sure to take measures that remove tightly coupled dependencies.

Reporting on agile teams

We’ve touched on several of the key metrics for agile teams in this article, and as an agile PM you’ll be required to report on these.

• Business value delivered, quality and end-user satisfaction: there are hard to grasp in terms of numbers, so look beyond Excel spreadsheets for this. You can use a green, amber or red stoplight-like system for portraying the  sentiment here. Just make sure you’re actually reflecting all stakeholder’s sentiments here, not just your own or the teams’.
• Work completed and burned costs versus estimated values: these can be combined in a burn-down (for work) / burn-up (for costs) chart. Estimated values can be shown in a separate line on the graph to immediately visualize variances.
• Team velocity and lead time: the team velocity can be approximately measured after the first sprint, and fine-tuned based on subsequent sprints (by taking a rolling average, for instance). Lead time can be calculated by keeping tabs on the time required for a backlog item to be completed. Both values can be presented as numerical data.
• Risk register: similar to traditional project management methodologies, it’s important to report on known risks.
• Product changes: a critical look at your product backlog can help identify issues in terms of ambiguity or volatility. Reporting on changes made, or backlog items removed from the product backlog can help stakeholders reflect on the stability of the backlog.

What to do if your company or role is changing

To touch back on our opening paragraph, there’s no doubt that change is happening and will affect you as a project manager as well. If agile thought you anything, let it be that change needs to be accepted – so does yours.

Given the direction project management is going, two possibilities exist: either the role of project manager will remain in existence at your company, but the way this role is fulfilled will drastically change. Think about adopting specialized roles as an agile project manager in this case, and facilitate adopting the new way of working. The other option is that your role will fade away, and be replaced by new roles such as product manager, product owner or scrum master. Either way it’s a case of rolling with the punches, but it’s important to accept this change and not take this as a personal failure. Instead, embrace the fact that this is a change bigger than all of us, and we’ll all need to follow suit.