If you think your team could benefit from incorporating those other techniques, you should do that. The discovery work is probably the most important thing to introduce, but you’ll need a more refined process in order to make use of the outcomes of that work.
2 Likes
According to the scrum master course I took with an instructor that has apparently been there from the start, the whole point of agile is to enable the team to deliver value. If this is the methodology that works for your team, then that’s great. Too many large companies, such as mine, seem to be adopting the agile tools and protocols without any thought to what they actually improve. User stories have just turned into broken up PRDs and sprints are just delivery schedules. If you can say that you have used these concepts and speak to the situations, you have experienced I’m sure you will be fine in interviews.
1 Like
The days of agile dogma are thankfully slipping away for us at more modern-minded companies. If you end up at some SAFe org or some other place that blindly follows a framework they were probably sold for $100s of thousands, in my opinion you should move on. Fast and loose means you’re probably doing something more interesting.
Unless you like working for big, “corporate” companies, in which case, all the power to you. I consider that level of corporatism hard to bear given the choice, since I’ve noticed these types of companies tend to have no grasp of Product Management. They’re stuck in the tedious world of Product Ownership, Release Trains, story points, mandatory demo dates, etc. They’re in well too deep now to due the psychological comfort agile numbers and agile coaches provide corporate leadership. Instead, why not dedicate those resources to building customer feedback loops and hiring the most talented teams who know how to build good products, not recite the scrum manual.
For your career, you absolutely need to get the lingo down and try to understand why you’re doing the things you’re doing, which comes from understanding the nitty gritty background of Agile. Things like the Agile Manifesto are still full of useful concepts. A few reputable articles and videos online should do the trick. In terms of the actual day to day, your processes should focus on what makes the product sustainably successful, not what a book or Agile website says to do (beware of people who dedicated their careers to Agile too)
1 Like
You mentioned big corps are stuck in a world of product ownership instead of product management. Mind elaborating on that please?
1 Like
I mostly agree with everything I said… However, I would add that there’s nothing wrong with working at large companies that have these heavy overhead processes. These companies tend to have a wealth of good people for personal and professional networking, the best support for families, the best insurance, stock programs, etc. They got big for a reason and that’s to be respected.
I’m referring to what I call the PO vs. PM mindset. It’s an over-generalization but holds some water. Essentially, you don’t see “real” product management at companies that traditionally hire POs and all the other scrum bits. They’re still catching up to the PM-oriented mindset, though many companies think they’re already there. You typically see this at companies that purport to be “transforming into a software company” or some BS and yet continue to underinvest in their technology teams.
“Real” product management is not married to any particular agile framework, and has a lot more control over the product than a traditional scrum team — a team whose purpose is essentially to take custom software orders from the HIPPO (often several hippos, with conflicting arbitrary timelines). Real product management detests things like day-long sprint plannings, department-wide mandatory demos, counting up story points from devs who couldn’t care less, etc. These activities are waste centers, put into place by management. Why spend a day preparing for and then doing a demo on some widget, when you could be focusing on how to actually make a better product?
Tl;dr Go spend a few years making software at non-tech F500s, then do it at a tech-native company founded in the last 10 years that doesn’t start with FAANG, and you’ll understand
Edits
- Also, no hate on scrum, it’s a valuable tool I partially use every day. But any kind of blind adherence to a highly sellable framework = big red flag.
- I mentioned demos several times - they’re just an egregious example of wasting time but by no means the main culprit
- I recognize the flaws in using terms like “real” PM but this is Reddit and I’m on a phone