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.
What is the Value of Agility?
One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
Are You “Default Ship” or “Default Delay”?
A couple years ago I ran across a blog post by Paul Jackson where he mentioned in passing the idea of a tension between “default ship” cultures in relation to corporations versus startups. For some reason, those two ends of a spectrum have stuck with me ever since, and after struggling with some culture change in my day-to-day job recently, I thought that it was an interesting subject that deserved a little more attention and dissection. Because, even though Paul positioned it as a startup v. corporate culture issue, my feeling is that it goes much deeper than that and is a topic that every Product Manager should be aware of and have their eyes out for — you never know when the “default delay” police will come knocking on your product’s door…
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…
When Push Comes to Shove – Picking Your Battles
In many organizations, conflict is part and parcel of the culture — some conflict can be constructive, some destructive, but most of it can just be downright annoying. And, because we often sit right in the middle of all of the random agendas, battles of ego, and emotional storms that can rage throughout the company, Product Managers often wind up dealing with the outcome of these conflicts if we’re not pulled deeply into them by one or more of our stakeholders. And while it can often be tempting to take on all comers, to defend your territory and your teams to the bitter end, the sad truth is that all too often, these conflicts simply aren’t set up in a way for us to “win” — and seeking that extra mark in our “W” column can often be counterproductive rather than helpful in the long run. All of the best Product Managers know that sometimes when there’s a fight that you’re not going to win, it’s far more important to lose gracefully than it is to die on a hill for something that ultimately didn’t really matter much.
- « Previous Page
- 1
- …
- 5
- 6
- 7
- 8
- 9
- …
- 43
- Next Page »