Reminder: don't trust fancy methodology names I tend to repeat myself over all of the articles I'm publishing here, yet let me do it one more time for this particular topic: I don't believe in dogmas. I believe that many dogmas are more aspirational and theoretical than actual, factually implemented practices. Especially within the context… Continue reading Building the right product: why, what and how
Tag: Agile
Product Design, Roadmap and Estimations
I've written about this topic already, a long time ago. Yet, it was with other words, with less experience. And I'm doing it again, as throughout the teams I met and worked with, it still seems like a key pushback, while it really is in the best interest of everyone, engineers, PMs, and anyone else… Continue reading Product Design, Roadmap and Estimations
Responding to change
Plans make us feel safe. And even if they're useful, we'll reach success by getting out of our comfort zone.
Customer collaboration
Customer collaboration: trust, transparency, communication and shared vision as your best bet against low churn.
Working software
Obvious value is obvious: working software over comprehensive documentation
Individuals and interactions
The end of Agile hasn't come series, part 2.
I’m one of the first who, in a team, will want to get proper tooling and processes. Why? Especially because once it’s here, I only want to focus on individuals and interactions.
The end of the agile world hasn’t come
It’s amazing the amount of articles I’ve been reading lately, or the amount of people I’ve heard discussing the same thing: the end of Agile.
Seriously?
Continuous Performance Testing: Why you should care
Yesterday, I attended the eZ Conference 2015 in NYC as a speaker.
As the Product guy at Blackfire.io/SensioLabs, I gave my take on the importance of Continuous Performance Testing.
Complexity to assess feasability
A recurring joke I hear when teams start using complexity points, and don't fully understand its principles, is their attempts to quantify the stock exchange value of complexity points vs man-hours. Funny, but pointless.
Complexity points are part of the Scrum paradigm. Mixing up paradigms is rarely a good idea.
Yes Alice, you should follow the white rabbit!
Empty your backlog, delete issues
A backlog is like a garden. At some point, if you don't spend enough time maintaining it, weed will grow. And your Japanese garden will turn into a wasteland.