It’s Product Roadmap Building Time Again!
The end of 2020 is nearing, and it’s product roadmap building time again—at least for those companies that are still dedicated to the old command-and-control model. In the next few weeks, executives and (key) stakeholders will come together and define new functionality that they believe will meet business demands in 2021.
While investing in product roadmaps can yield a reasonable return by creating a shared understanding between the “the business” and product teams, I also believe that product roadmaps need to be living artifacts requiring continuous attention by everyone involved. To make that process as worthwhile as possible, adhering to the following seven product roadmap first principles has proven beneficial in my experience.
TL; DR: Agile Management Anti-Patterns
Learn more about agile management anti-patterns the aspiring servant leader should avoid during the organization’s transition: From applying the Stage-Gate® approach through the back door to the ‘where is my report’ attitude to other beloved signs of applied Taylorism.
TL; DR: 18 Signs of a Systemic Toxic Team Culture
What looked like a good idea back in the 1990ies—outsourcing software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. While they try to become more appealing to product and software developers, they still have difficulties understanding what it takes to build an attractive product/engineering culture. Learn more about typical anti-patterns and signs that an organization is causing a toxic team culture, impeding its efforts to become agile.
TL; DR: Lipstick Agile — Happiness in the Trenches?
Have you noticed how many people in the agile field are unhappy with their work situation? A situation where an organization already struggles doing agile, not to mention ‘becoming agile?’ This is what I call lipstick Agile.
Scrum Masters and agile coaches are close to either burnout or indifference. Product Owners who “own” the product by name only, and developers questioning why “Agile” is imposed upon them and often turns out to be just another form of micromanagement.
TL; DR: Scrum’s Nature: It Is a Tool; It Is Not About Love or Hate
Regularly, we find articles from developers detailing why ‘Agile’ in general and Scrum’s nature, in particular, deserve our collective disdain.
What has always struck me in this discussion is its emotionality. Scrum is a tool, useful to accomplish one primary task: delivering value to customers of emergent products in complex environments while mitigating an organization’s exposure to risk at the same time. So, if Scrum is not working in an organization, maybe it is because Scrum is applied to the wrong cause in the first place. Or, that its application has been mechanical, driven by folks who don’t know what they are doing. (Seriously, how hard can Scrum be if the manual comprises of 18 pages, right?)
The question then is: Why would I “hate” a tool unsuited for the intended purpose or applied incompetently? Would I hate a hammer for not being capable of accurately driving a screw into a wooden beam? Probably not, as the hammer wasn’t designed for that purpose, and neither sheer will-power nor stamping with your feet will change the fact.
TL; DR: A Remote Daily Scrum with a Distributed Team
We started this series on remote agile with looking into practices and tools; we explored virtual Liberating Structures, and how to master Zoom. We had a look at common remote agile anti-patterns; we analyzed remote Retrospectives, Sprint Plannings as well as remote Sprint Reviews based on Liberating Structures. This eighth article now looks into supporting a distributed Development Team organizing a remote Daily Scrum.