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”…
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.
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.
One of the things that I love about the Product Management community here in Seattle is how close-knit we are, so when I reached out to Tricia Cervenan, a fellow Product Manager and General Assembly instructor, for her thoughts on the industry, the role, and what it means to her, I was not disappointed. I met Tricia a few years back at a panel discussion for General Assembly’s and have worked closely with her during our classes to help mold and modify the curriculum to best fit the needs of our students. I’m happy to have her as a returning judge for each of my courses, and more happy to mark her among my very close colleagues in the business!
In her own words:
Tricia Cervenan is a product manager at L4 Digital and part-time instructor at General Assembly. She has shipped over 15 digital products and is most proud of the teams she’s help to build while doing so. Tricia is a co-organizer for App Camp for Girls Seattle where she teaches 8th and 9th grade girls confidence and coding while taking them through the process of building iOS apps in a week. When she’s not building software or working with those new to the industry, Tricia finds joy in long distance cycling, world travel and a good cup of coffee.
At some point in my meanderings online, I heard tell of a Slack channel that had been set up for Product Managers to engage with each other and discuss topics of concern to those in the profession. And, being the Clever PM that I am, I had no choice but to check it out — that channel turned out to be hosted by the folks at the Product Coalition, and administered by none other than Jay Stansell. The channel has turned out to be an exceptionally popular location for PMs to share articles they’ve written, ask for thoughts or feedback on idea that they have about how to improve the craft, and even to just humbly ask for advice when they’ve hit a brick wall on something. When creating my list of participants for this 10 Questions series, I knew right away that I’d want Jay’s thoughts on the role, and he was more than happy to oblige.
In his own words:
I’m a product person, who is grounded in design, shaped by technology and inspired by profitable business models. I “cut my teeth” in a travel start up in 2007, and grew it into one of Australia’s leading travel products. I’ve since been fortunate to craft products and product experiences for some of Australia’s largest brands. Today, I take my start-up learnings, attitude and culture, into coaching Agile, Lean Startup and Design Thinking methodologies at Australia’s most innovative insurer, IAG.
What I’ve enjoyed the most from my story so far, is the talented people who have become friends. It’s these connections that inspired me to launch the product community ProductCoalition.com – a place for product people globally, to connect, collaborate and inspire.
And without further ado…my ten (eleven) questions for Jay…
We live in a day and age where there’s a ton of information and mis-information out there about pretty much every topic imaginable, and Agile development is certainly not immune to this phenomenon. In fact, anyone who looks for help in pushing through an Agile transformation in their organization is immediately confronted with a vast array of presumptions and preconceptions about what Agile is, why it matters, and most importantly what it delivers. The simple truth is that the reality of an Agile transformation — both in process and in outcome — is often so very far removed from the myth that we as Product Managers need to be ready, willing, and able to step in and manage the expectations that our stakeholders have about what’s going to happen and what they’re going to get from it. Here are three very common preconceptions that simply must be squashed for us to lead a successful cultural transformation.