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”…
For the past three years, I’ve posted a list of five things that every PM should be thankful for (you can see the other installments here: 2014, 2015, 2016). It started as a bit of a lark, something to fit in with the holiday, but each year’s list has been more popular than the last, so it’s become something of an annual tradition here at the Clever PM. Just as in prior years, consider this an unranked list of five things to be thankful for — not an exclusive list, certainly, but without these things our jobs would be incredibly more difficult than they already are. If you have other things you’re thankful for, feel free to note them in the comments!
During this year’s ProductCamp Seattle, I sat in on a great presentation by Dave Manningsmith where he discussed several dysfunctions of the daily standup ceremony (or “ritual” as he referred to it) that so many of us participate in on a daily basis. And it really made me think a lot about just how badly so many of us actually do in our standups — whether it’s because we’re used to status reporting in authoritarian cultures, because we’re really just teams in name only but still executing as individuals, or (most likely) because the organization has never really taken the time to understand why we do standups, so they don’t even understand that they might be doing them wrong. Here are some common anti-patterns and resolutions that will help you ensure that you’re at least closer to doing a standup “right” in the future…
I recently had a really great conversation with a fellow co-worker about how and why companies struggle with the adoption of agile methodologies like Scrum. It just so happened that he had come from a very large company where someone had undertaken something unheard of — they attempted to objectively measure the effect that Scrum participation had on a variety of employee metrics, including productivity, job satisfaction, and overall output. The interesting finding was that for teams who skipped any one of the five key Scrum ceremonies, their overall scores were literally no better than teams who maintained an old-school, waterfall approach — while every team that performed all five of the key ceremonies on a regular basis has scored vastly greater than their peers, across the board. Seeing this data in tangible, objective numbers really stuck with me, and I think it’s important to discuss just why these ceremonies are so important to successful adoption of agile processes.
I’ve been working on B2B solutions for a very long time (dating almost all the way back to the turn of the millennia), and in that time I’ve come to realize that far too many applications try to be everything to everyone, and as a result really wind up serving nobody at all. You can see this in many product designs that try to capture all of the possible things that you could do at a given point in time, rather than leading you through a logical path, or showing you the most likely things that you may want to do. As much heat as I give the “ribbon” change that Microsoft introduced in Office a few (many) years back — conceptually, it was the right thing. It focuses you on the specific things that you need to do in some contextual space, without requiring you to remember which specific menu item someone decided to hide that option under. While the rollout was challenging, in my opinion, the approach really encapsulates a concept that I like to call “build for the novice, enable the expert”.
There are a lot of different hats we wear as Product Managers, which means that there are a great many opportunities for us to do the right thing, at the right time, for the right people. But the inverse of that is also true — by virtue of wearing so many hats, there are a lot of opportunities for us to do the wrong thing, at the wrong time, for the wrong people. These anti-patterns have a tendency to sneak up on us and bite us when we’re least expecting it, and therefore least prepared for them. But by being aware of them, we can keep our eyes open and try to avoid them if we spy them sneaking up on us in our rear-view mirror. This is far from an exhaustive list, but I’ve compiled five mistakes that Product Managers often make that set us up for almost inevitable failure.
There are a great many company cultures in the world that go out of their way to avoid conflict of any kind. And, while the intent is good — nobody wants to work in a combative workplace — the common practice of lumping all conflict together into a single bucket and trying to toss it out the window winds up being counterproductive in many ways. You see, conflict isn’t always a bad thing; certain types of conflict actually make us better at what we do. When we engage in constructive conflict, we hone our ideas, challenge our own assumptions and biases, and push others to do the same. In an environment completely absent all conflict, we might as well all just be “yes men” and simply rubber-stamp every idea that comes around. Successful businesses are not built that way. Here are some things to think about when it comes to engaging in constructive conflict.