Project Management: There’s No Silver Bullet
I think it’s time that we put the whole agile versus waterfall debate to rest.
An argument over nimble iterations versus good planning is preposterous, because a good team needs both.
Because effecting good project management is no more about adopting the right wholesale principles, than being a good chef is about buying a good kitchen island and a knife set.
We would love to pretend that guiding principles solve real world problems.
But they don’t.
An answer without a question is not a solution. Thus, waterfall or agile without context are no silver bullets.
No, this piece is not an agile or a waterfall bashing fest.
Instead, the key guiding introduced in this post will help us dissect components of project management principles like agile and waterfall, and then design a process and a methodology that is tailored to your organization.
Why Agile or Waterfall isn’t for everyone
Dogmatic advocates married to principles tend to say “Oh they work for all situations”, and this is usually symptomatic of folks who have not observed many of the “all situations”.
Project management, like product prioritization and programming paradigms, there is no end-all solution, there is only the one that is right for the job.
Let me start with a few examples.
I have lead and managed startup product and engineering teams in a few different verticals and fields of tech, including education, commercial banking, systems engineering, IoT and e-Commerce.
Agile for instance, didn’t work particularly well for B2B SaaS models in education, commercial banking, or systems engineering, nor did it work for B2C IoT.
Nor did a “pure” waterfall approach.
Yes, I know what zealous advocates would say:
“That’s because you didn’t do agile correctly.”
Well, if that’s the canned response to this situation, then I’m sad to report that not many teams out there are truly doing agile, or waterfall, “correctly”.
In fact, that’s not how a truly scientific theory or paradigm works. No theory or paradigm ever perfectly describes the material , there will be negative data points.
If the principles (or ideologies, really) you are committed to comes with a fine print that unconditionally throws out negative data points, then it is not science.
With that said, if we can agree on this and regroup around actual concerns in the field, then it will be easier to steer this conversation towards a more pragmatic direction.
A Good Process Requires Good People
By good people, I’m talking about responsible, productive and proactive team members.
A common lie told by those trying to make money off of teaching project management methodologies is that:
Oh, if you do this right, it fixes your team.
No, it doesn’t.
Processes and methodologies don’t fix people, no more than a good theory of gravity fixes gravity itself.
Sure, certain processes could inspire certain actions, and could be conducive to positive change.
But what a good methodology could not fix, is poor motivation and bad mindset.
An instance of a vile work experience in my career that always stands out is this most “agile” team I’ve seen. It was a series-C funded fin-tech AI startup, it was also perhaps the most unproductive company I have had the misfortune of working with.
And they did everything by the agile book.
But the problem wasn’t with agile methodology, the problem was with many of the people on the team.
When it didn’t work, they simply tried everything. They tried every “great” methodology they could find, they hired coaches and consultants to effect the process. I’m pretty sure by now they’re trying the Spotify model, and it’s almost a given that this effort will fail too.
Because the company was littered with irresponsible employees and was lead by irresponsible founders and managers.
At scrum planning meetings, team members looked for least-effort tasks to fill up the sprint so they could collect their next paychecks. At grooming meetings, it was a game of shifting responsibilities to the most proximal black hole so nobody could hold anyone responsible. At daily standup, people were just regurgitating the same vacuous plan they came up with during planning and grooming.
Because nobody cared.
The company, methodically, did everything detailed in the agile book, and yet it goes back to the principle of garbage in, garbage out. The company’s internal operations fails colossally and continues to burn through tens of millions of funding each year.
Within two years, the company lost most of its core talent.
The company, being all agile and all, was the opposite of a productivity magnet. For very obvious reasons.
The takeaway here is that don’t wishfully think that you could turn a ship full of unmotivated, lazy, undisciplined or toxic people around by just adopting a new management methodology.
If you want good cider, toss out the rotten apples, start with a good bushel.
How to Design a Methodology for Your Team
Notice I used the word “design” instead of “choose”.
Ok let’s start with a very basic concept:
Methodologies are not domain- or industry-agnostic, they are dependent on what you do, what your team does, what your ecosystem does and what your clients do.
and very, very much so.
With that said, there are a couple of things to keep in mind.
Dimensions of a Good Project Management Methodology
Instead of slapping a label on a methodology, I usually define the methodology I design by how it helps one visualize and management four (+1 bonus) key dimensions.
Dimension #1: Project Portfolios
The methodology should allow the team to straightforwardly visualize the portfolio of existing and future projects, along with their respective statuses.
Dimension #2: Executional Capacity
Then, it is time to turn the project portfolio on its side, and visualize the loading and allocation of individual resources. The methodology should provide concise representations of team resource utilization.
Dimension #3: Timeline
The offshoot of the first two dimensions is a visualization of a reasonable timeline.
Dimension #4: Risks
Once you have a timeline in place, measuring how likely (or unlikely) is the team to deliver on the portfolio of projects with current resourcing, by the timeline specified, comes in handy.
Bonus Dimension: Skills
While not technically a part of project management, but the four dimensions defined above will provide valuable insights into opportunities to recruit, train or reassign team members with certain skillsets.
With all that said, it doesn’t really matter if you are talking agile, waterfall or something else, because all these dimensions are relevant regardless of the methodology you are using.
Thus, the better way to define your tailor-made methodology for your team, is to assess how your methodology helps to visualize and manage each of above dimensions.
This is more meaningful than a bandwagon slogan, that’s for sure.
Methodology Should Agree with Communication Pattern
Some might call this a special case of Conway’s Law.
Conversely, a methodology that doesn’t agree with the underlying the communication structure within your organization will result in process waste, usually in the form of resource underutilization.
The question then becomes…
Do I change the way people communicate to fit the methodology, or do I design a methodology that preserves existing communication patterns?
That, is a great question!
Because there is no right answer.
All I can offer here from my experience is — it depends — on how you measure your communication and collaboration efficacy, as one often seeks to preserve and magnify satisfactory results, and rectify less than desirable ones.
Shared Responsibility is a Double-Edged Sword
Shared responsibility could be manifested through collaboration between stakeholders, project management, and executors.
Another form of shared responsibility could also be the matrix (or higher dimension) organization in which managers of business units negotiate with managers of functional departments to broker resourcing and timeline in order to achieve company-wide objectives.
This may come as a surprise — but despite being the cornerstone of a healthy project management structure, shared responsibility should be wielded with caution.
Why?
Because not everybody is proactive, not everybody has a strong sense of responsibility and ownership.
I have run cross-border teams, and it is often hard for someone working in the U.S Tech industry to understand why shared responsibility could potentially be problematic in other cultural scenarios.
Yes, there are times where you don’t get the choose your team members, and you are ruthlessly stuck with people who don’t feel a strong enough sense of responsibility to participate in multi-dimensional communications within the organization.
In these scenarios, a matrix or higher dimension organization, introduces more deadlocks and responsibility gaps, than flexibility and coverage.
When this happens, you either try to get rid of people who won’t play ball, or you need to learn to play a different ball game…
And that ball game is — provide clear, linear instructions for those who don’t proactively communicate.
This again, echoes my earlier point that processes and methodologies don’t fix people. There are times where you have to design methodologies around the team members you have.
Product Manager vs. Product Owner Debate
This is a moot one to be very honest.
A product manager is a job function, and a product owner is a role.
Any person with ideas and expertise to propose a project can be a product manager, but this doesn’t mean you shouldn’t have product managers who have deep knowledge of market conditions, potential product-market fits and relevant product development experience.
What you want to call a product-related stakeholder is up to you, as long as the person provides ample expertise to define, specify and advise during product design and development process.
My two cents.
