Arguably the most important — but unfortunately, also perhaps the least understood — thing about agile is that it’s not a methodology. Rather, at its essence agile is a mindset that doesn’t just change what teams do, when they do it, or how they do it, but it reframes why they do it. Or at least, this is how agile is supposed to work in theory. In practice, the situation can be markedly different.
This is because in some organizations, agile teams are either internally resisting or externally blocked by approaches that work fine in a traditional project management framework, but are counter-productive in an agile framework. When this happens, the very idea of agile usually incurs everyone’s wrath and ire, when in truth the real culprit is a lack of adjustment. In other words: either because they don’t want to or they are not being allowed to (or a combination of both), teams are not truly casting off from traditional shores and setting sail for agile waters.
To address this dilemma — or better yet, to avoid it — here are four paradigm shifts that traditional project management teams should adopt to make agile work for them vs. against them:
1. Customer-Driven vs. Customer-Centric
Both traditional and agile project management focus on customers (internal or external). But there is a critical distinction in how this objective is approached.
In traditional project management, plans are developed in light of clearly-established customer goals, and specific activities are executed in order to achieve them. While customers are kept in the loop, they are not materially involved in the project (that is, unless something goes significantly wrong).
In agile project management, close customer involvement is vital. This is because customers are primarily responsible for driving the velocity, nature and direction of the project through continuous feedback loops. Of course, the project team is there to shape (and at times protect) the scope.
2. Change as an Asset vs. a Risk
In traditional project management, change is essentially seen as a risk factor because it represents a deviation from the plan. As such, there is an inherent, default resistance to change (which is a good thing, not a bad thing).
In agile project management, the situation is reversed and can be quite disorienting to those who hail from a traditional project management background: a lack of change can — and often does — represent a risk, because it may reveal a lack of experimentation and innovation. In other words, nobody is trying to do things faster, better and smarter.
3. Internally vs. Externally Managed
Both traditional and agile require management. However, how management is structured and delivered differs markedly between the two camps.
Traditional project management teams are led by a project manager who is responsible for resolving problems and making decisions, and if necessary escalating issues to senior management.
Agile project management teams do not have a conventional project manager at the helm. Rather, they are self-managed and self-organizing, which means their primary objective is to resolve problems and make decisions internally. Only the most serious matters are escalated outside of the team. Notably, this is less about philosophy, and more about pragmatism: agile teams need to pivot quickly and work efficiently, and constantly consulting a project manager throughout the day (and alas, sometimes throughout the night!) would slow down progress and lead to a litany of flawed deliverables and missed deadlines.
4. Teamwork vs. Individual Performance
One of the defining characteristics of traditional project management is the progressive elaboration of a piece of work. Team member “A” does her part, and passes things along to team member “B” who does his part, and so on until a unique product is delivered. Of course, team members should collaborate where necessary and add value where appropriate. But at its core, the approach allows for and often encourages optimizing individual performance — because when that happens and everyone does what they’re supposed to do (and at the right time), plans are carried out and projects succeed.
Agile project management does not function in this way. Team members cannot “silo” themselves — even if doing so would actually help them do a better job on their piece of the project — because their activities are so integrated with what their colleagues are doing (or what they aren’t doing), because things change from week-to-week — and sometimes day-to-day or hour-to-hour — based on continuous, high velocity iterations and feedback loops. In this sense, effective teamwork in agile teams isn’t just important or an ideal: it’s an absolute, fundamental requirement. Basically, everyone the team reaches the finish line together, or nobody does.
The Bottom Line
Nothing above suggests that agile project management teams are more functional or effective than traditional project management teams, or vice versa. Rather, the message is traditional teams that venture onto the agile landscape must shift their paradigms accordingly. Otherwise instead of rewarding, they are highly likely — if not virtually guaranteed — to find their agile experience regrettable.
Planview AdaptiveWork Go: Making Agile Work!
Planview AdaptiveWork Go is a simple-to-use task management tool that makes agile adoption a breeze thanks to personalized workflows that match each team’s unique style.With a wide range of built-in productivity, collaboration, reporting and monitoring tools — and supporting total, seamless integration with our award-winning cloud-based project and portfolio management platform Planview AdaptiveWork One — there has never been a smarter or easier way for teams to make agile work FOR them, instead of AGAINST them.
Learn more in our brief, informative and enjoyable video — click here.
