There’s a tool in the Scrum toolbelt that is so utterly critical to success yet so fundamentally misunderstood by far too many development teams, Scrum Masters, and Product Owners. I’m talking, of course, about the Sprint Retrospective. I’ve seen it time and again, teams that are able to hit all the right notes in their standups, reviews, and planning sessions — but who wind up botching their Retrospectives in such a horrible fashion that they miss out on the single most important part of agile product development, continuous improvement. Certainly, it’s never fun to take time out of our day to look back and discuss what went wrong in the past two weeks — much less try to come up with new things to try on a sprint-by-sprint basis. But it’s the single most important part of the culture that we’re trying to build — the culture of agility, of adjusting, of improving…of change.
How Much Technical Debt is Too Much?
Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…
The Product Lifecycle
This post comes courtesy of a direct request from one of my supporters over at Patreon, who asked me if I could give them a 10,000 foot-level overview of the Product Lifecycle from ideation to delivery. While nothing here should be terribly earth-shattering or world-changing, I think it’s important for us as Product Managers to stop on occasion and think about how things should work for us from the point of an idea to the days supporting a thriving product. So here’s my personal take on the subject — as always, if you have thoughts or comments, feel free to drop them here or hit me up on Twitter!
Goals & Non-Goals
One of the most important part of our jobs as Product Managers is setting goals — goals for ourselves, goals for our teams, and goals for our products. Goals are important — they set the North Star for us to know where we’re going, why we’re going there, and how we know whether or not we’ll be successful when we get there. Properly-formulated goals are an essential component of being a successful Product Manager. But how many of us think about non-goals? Those things that we are intentionally choosing not to do in a given project, the things we don’t expect to change due to our efforts, or the subject matter areas that (for one reason or another) we don’t want to address at this time, with this team, or with this project. Non-Goals are just as important as actual goals, and here are a few reasons to keep them in mind in your next kickoff session…
New Year, New Perspectives
So, another year is starting up, and we’re just now starting to unpack ourselves from the holiday break that so many of us take time to enjoy with our families and friends. The best thing about a new year is that the future really is a blank slate, 365 days to make of them what we will. Sure, there’s carry over from last year, but there’s far more to look forward to than to look back on. It’s the perfect time to stop for a moment and take stock of what happened last year, what you want to do this year, and how you’re going to make 2018 more successful than 2017!
Story Points are a Signalling Tool
I was called into a meeting with a team here in the office a couple weeks ago because they told me they had a “question” about the estimations that they were doing. As we started talking, it became immediately apparent what the problem was, they were getting into arguments about whether their estimates were “too big!” Apparently, someone had told them that they “couldn’t” have any stories that were above a certain value, or at least that’s how they took the directions they were given. I stopped them for a minute and had a quick discussion about the reasons why we estimate stories, and why it’s incredibly important for the story points to reflect the size the team thinks the work is, regardless of what other people “want” them to do. I walked away to leave them to their work, and was entirely unsurprised when I saw some 20-pointers land on the backlog. Far too many teams suffer from some malady similar to that of this team — they forget why we’re asking them to estimate, so they start to engage in anti-patterns that undercut the very purpose for which estimation exists. In a follow-up conversation with another member of our Product Team, I started to think about how to describe Story Points as something other than “estimates” — and I came up with the idea of them as a “signalling tool”…
Understand the Purpose of Your MVP
The concept of MVP is an interesting one in the Product Management world — interesting, in that just like the role itself, it seems to mean something different to almost everyone that you talk to. On one side of the spectrum, you’ve got the Lean Product folks who seem to think that a landing page without any other context is an MVP; on the other you’ve got people who seem to think that you’ve got to have a full end-to-end solution that’s just ugly to achieve an MVP. The truth, however, lies somewhere in between the two — as I’ve noted before, there are some key considerations that come into play when coming up with our MVP (When is an MVP *not* an MVP?, but there’s more to it than just understanding the “Minimal”, the “Viable”, and the “Product”. Ultimately, MVPs must all serve some purpose; otherwise there’s really no point in it.