Product Primer - WTF is AGILE Development like - actually?
As an Aspiring Product Manager, what do I need to know about “Agile Development” to land my first job as a PM
If you’ve spent any time in or around modern tech companies - you’ve heard the term Agile.
Likely, it was casually thrown into a conversation discussing how companies Move Fast and Break things on the Cutting Edge of Technology.
Agile, more formally Agile Development, is ubiquitous in modern tech culture. For fun, I googled product manager roles to see how quick and often the word Agile appears.
In the 2nd posting, I see after 30 seconds, the following was spotted below for a Product Manager role with NBC;
Under “Qualification”
Strong experience with Agile methodologies, sprints,
Under “The Job”You'll lead and motivate a dedicated, cross-functional Agile team by communicating your vision, authoring user stories, optimizing team welfare and experience, actively prioritizing the backlog, and coordinating regularly and clearly with partners and stakeholders.
Twice in the same JD!
Bottom line: if you apply for a product job, you will be expected to work in an “agile” environment.
So - what the hell is AGILE?
Origination of Agile Development
Prior to Agile, Waterfall development was the king of the castle. What you need to know about Waterfall is the process is linear. The previous step must be complete before the next step can begin. This makes total sense for the traditional manufacturing of physical goods. I’m not putting up the walls frame and walls of my house before I set the foundation.
Then - the dot com boom happened and with it - the advent of modern scaled production of digital goods in the form of software. With this evolution into what the cool kids today refer to as Web2.01, manufacturing became infinitely more flexible with the raw materials being bits.
Around this time, some very smart and very rich people thought the producers in this new digital world could do better - and they did.
And Agile was born! It came out of a pompous think tank-like event at a ski resort in Utah in 2001, where the leading developers got together to re-think how modern software development got done. The output of their effort was the Agile Manifesto - which included the commandments of modern product development I share below.
Principles behind the Agile Manifesto
The following are the Principles of the Agile Manifesto with my emphasis in bold.
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.Give them the environment and support they need
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.Continuous attention to technical excellence
and good design enhances agility.Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Agile Spawning the Modern Product Manager
The modern product manager was born out of the agile manifesto.
The principle Business people and developers must work together daily called for a deeper collaboration with the extroverted business folk and the autistic developers. As you can imagine - over time the developers weren’t too keen on talking to the business folk every freakin day. Enter Product Managers!
PMs were brought in to engage all the business side of the house on a daily basis - translating all their asks into specs to be executed by the development teams, then keep those the business users abreast of the progress and ultimate release of new code
The original product managers were, well, developers! The more extroverted coders were the ones who were game to talk to all the other people in the business. Developers made sense for this role as they could effectively break down asks into tasks, writing the specs for other developers to execute upon.
Eventually, as technology companies became more mainstream, the demand for product managers became too great for only ex-developers to take the role. Suddenly, the business folk started creeping into products to fill that void - landing us where we are today.
How the Agile Manifesto Manifests in a Product Manager’s Day to Day
Immediately, in the very first principle, the stated highest priority is to satisfy the customer.
This bears out in the very first line of every user story2 - the problem statement. All new features are grounded in the needs of the end user. The software HAS to actually solve the user’s pain points to succeed.
It’s also why the feedback loop to the customer must be tight. I support product managers getting on calls with users with regularity. At a minimum, watch some videos of your CS team engaging users. You need to know how your users think - what they want, why they want it, and what they are explicitly trying to accomplish with your tools. It’s critical to the success of every PM.
By welcoming changing requirements, even late in development, the goal is to be able to pivot3 the strategy on a dime. There are endless reasons why you may need to do this. Sometimes this could be your biggest client throwing their weight around, other times it could be an existential change to which the industry your software belongs. Regardless of why - your dev teams need to be ready to change the focus of software development overnight
I’ve seen it happen over and over again - the needs of the business shift, and software development has to drop everything and adjust. It’s the reason we call the whole thing Agile - the ability to shift directions at any and every moment is what enables Technology Companies to thrive.
How does this affect product managers? If doing your job right, you’re the one breaking it to your dev team “Guys - your not gonna like this, but, we gotta drop everything…”
Operational Implications of the Agile Manifesto
Deliver working software frequently, from a couple of weeks to a couple of months is where the concept of a Sprint was born. Sprints, most commonly 2 weeks, but sometimes 3, or even 4, are meant to be the time-bound period to which a team delivers working software for one or more features as a result of the effort.
It’s an organizational mechanism, allowing for a complete team shift of focus every 2 weeks as new tickets are up for adoption4. Hotfixes5 will always be necessary, but pushing code to production a sprint by sprint helps on several fronts:
Frequently delivering useful functionally to your user-base makes them happy, and lets them know if something isn’t working, it will get fixed
It allows other stakeholders at your company to understand that their needs will be worked into a sprint at some point, ideally forecasted for a specific sprint
By building products with motivated people and trusting them to get the job done, we encounter the golden goose of any successful technology company. Success comes when the team doesn’t cast blame upon one another when things go wrong. We trust everyone was trying to do their job in earnest, and if something did not work, it’s on the group as a whole to fix it structurally.
It’s why at regular intervals, the team reflects to understand why failures occurred systematically. This is typically done in the form of a retro, where all the developers and product managers get together to call, typically after each major release of code - to discuss what worked and didn’t work in the latest iteration of development. Action items are then set in this meeting, to improve operations for the next development cycle.
A true high trust environment is difficult, if not impossible, to achieve 100% of the time. Despite it being Utopic in nature - it’s an ideal worth striving for. Get a bunch of smart, motivating people in a room, try to check the egos, have everyone do their part, and magic happens.
It’s part of the Agile Manifesto so that we don’t cynically forget, that collaborating with like-minded folks can, in fact, change the world.
Self-Organization in Modern Software Development
Focusing on self-organizing teams bears out in sprint planning, where a product manager prepares a series of tickets representing features and bugs, stack ranks6, and reviews with their dev teams. The dev teams then, independent of the PM, do an LOE(level of effort) estimate on how much effort those tickets will require. Armed with more data, the dev team lead then proposes a sprint back to the product manager for review in sprint planning based on what the dev team believes and agrees, is realistic in scope. The dev lead and product manager can then negotiate any changes needed to be done up until the sprint begins.
These negotiations can get creative. I’ve regularly offered up my own services as a QA analyst to get a ticket adopted where the developer capacity existed, but not QA. This agile self-organization is personified in that the people executing the work are organizing what gets done, by who, and when. There is no formality around BIG BOSS SAYS DO THIS, SO WE DO IT.
That’s not to say an executive won’t come in and start straight dictate working, but the general standard today in tech companies is ultimately everyone involved agrees and commits to the work done week over week.
Conclusion
You can pay $495 to become a certified scrum master to “Learn Agile” or you can subscribe to me Substack for $9.99 a month to learn enough to get you in the door with the product org (At least until the price of Pivot to Product increases at the end of Q3).
Don’t let the requirement for knowledge of agile stop you from thinking you can join any organization. At the end of the day, the agile manifesto is simply a best practices list that makes sense pragmatically. Anyone with an iota of intelligence can grasp “Agile Practices” after a few months on the job.
Don’t get played by those recruiters. Having read this article, you now “Know” the basics. Subscribe to my paid Substack, and I’ll fill in all those knowledge gaps you have to break in and thrive as a technical product manager
Got a product resume you need to up-level? I’ll review your resume, then talk tactics on a call.
Are you struggling with a product problem today? I’ll hop on a call and help you put forth the game plan to solve your issues.
In the name of always trying to be better, please fill out the Pivot to Product User Feedback Intake to give me a better sense of the Pivot to Product audience.
Web2.0: The result in big players who own servers scaling up the internet to be an economic juggernaut. IE Google, Meta, Amazon, etc
User Story: A specs document written in a user-focused manner
Pivot: A change in strategy or direction
Adoption: When a feature or bug is committed to delivery by a dev team
Hotfix: A piece of code delivered out of cycle ASAP, generally to fix critical issues in production
Stack Rank: The act of prioritizing any collection of work needed to be done, from most important to least important
Great article. I came across whitebelt on twitter. Read through his content and realized he's the guy who can help me pivot to product. Booked a call and it was packed full of value.
I've wanted to pivot to product for awhile but didn't know the steps. Everyone gave me vague advice. It was never clear what to do. But the call with whitebelt was different, he gives actionable personalised advice. Highly recommend booking a call with him if you're interested in breaking in to product.