Agile vs. Traditional Project Management: a Quick Q&A with Don Souza
There’s been a lot of talk lately about the realm of project management, particularly when it comes to the radically different approaches and trends of today’s offices (see agile). And as with most transitions, some people are suffering from blind excitement while others are moving forward begrudgingly, secretly hoping for a resurgence of the “good ol’ days.”
In order to help ease the process, I sat down for a quick chat with Don Souza, our own Director of Program Management, for some insight on these shifts and what we can do to make adoption as painless as possible.
Project management has changed significantly since the implementation of agile processes. What major shifts have you seen specifically?
While there are several process differences between traditional project management and agile, the most significant shift is from hierarchal-based responsibility and task assignment in favor of the “self-organized” team-based approach.
Traditionally, the onus for project success has resided with the project manager by creating, communicating and executing on a completed and linear project plan. In Agile, the whole team is responsible for success.
Agile fosters shared responsibility amongst the “self-organizing” team, with just enough planning and scheduling to keep the team efficient, provide business value and produce demonstrable software. And rather than looking to a single project manager for task delegation and direction, the shift towards agile encourages problem-solving and feature creation from multiple points of view.
Speaking of, by now most of us have heard the notion that everyone, no matter their title, is taking on some level of a project manager role these days. Can you talk a bit about that?
The recent trend towards agile has produced a people shift in how each thinks about work and how it contributes towards the team. Agile permits those not trained in specific processes to take on the role of project manager. We’re currently seeing this at all levels of the org-chart with successful results!
At a minimum, everyone in the agile workplace must be their own “project manager” in tracking individual tasks, duties, expectations and how this fits with others on the team and the overall project. Non-project managers and those without a formal process background instinctively tend towards what they want to accomplish over how it will get done. Agile provides the framework and guidelines for this approach, with enough true process providing boundaries, but not necessarily exact technique, dependencies, flowcharts, etc.
A smaller team with a collection of people all wearing and sharing the project management role is proving better for delivering product to the customer faster!
A lot of seasoned project managers like yourself are finding the shift to be a bit difficult. Can you talk about the main pain points of the everyone’s-a-project-manager approach and how can they be resolved?
Pain Point #1: It’s not uncommon for someone to “fall into” the role of acting project manager without asking for it. As a result, organizations see varying degrees of acceptance here. Some act and move forward with glee, others neutral, and lastly some grudgingly or not at all.
Resolution: Management needs to recognize the differing levels of acceptance. Encourage those that relish and thrive in that type of environment, guide those that are neutral, and accept those where it isn’t a good fit. Also, have the acting project managers who enjoy it mentor those who don’t. Peer training is often the best!
Pain Point #2: Most, if not all, acting project managers will have little or no formal training. As a result, there will be a wide variety of differing styles and approaches. It’s unlikely any will have traditional certifications or training in Gantt charts, work-flow-diagrams, etc.
Resolution: To resolve this, settle on a simple, yet effective ‘Minimum Viable Product’ project management style. Agile is perfect for this! Start with the basics and some simple approaches everyone can agree upon.
Pain Point #3: It’s difficult for the team and management to get complete status and the overall picture, including accountability and metrics. Acting project managers will show varying inclination for documenting and measuring their team’s progress and results.
Resolution: Create an agile story to settle on a basic reporting template everyone can use. Focus on the results and value, and what can be learned from them! Format is secondary!
Pain Point #4: Often employees will take on the project manager role simply to get their work done. They suffer from the “if I don’t do it, it won’t get done” syndrome. Initiative is good, but this scenario can lead to unhappy workers. The overall project environment can become very horizontal without a clear, designated manager with oversight jurisdiction.
Resolution: Designate someone on the team, preferably a volunteer, to oversee the big picture. Acknowledge this will take some bandwidth. The best manager will promote, incentive and reward this.
Pain Point #5: Eveyones-a-project-manager is not a long-term solution. This approach can work in the short-term, meaning up to twelve months or less. Assuming success, which should be anticipated, the lack of a more structured approach will inhibit growth as products and companies move forward.
Resolution: Accept this risk and shortcoming in the near-term. Set a standard and checkpoint for when ad hoc project management has reached a ceiling. Move to the next Agile step and have the team members agree upon some additional process everyone can accommodate. By this point everyone will have some real world project management experience.