Traditional roadmaps make too many assumptions which causes miscommunication, wastes time and effort and renders you unresponsive to changing circumstances.
The idea behind Lean is to reduce waste. Let’s make our roadmaps less wasteful and create a lean roadmap!
Continue readingWhat makes a good roadmap? More is always better! More milestones, more details, more predictions. That was my naive approach to creating roadmaps for a while. I didn’t realise how counterproductive most of that was.
A tweet from Janna Bastow last year inspired me to question my simplistic concepts.
Continue readingOver the last year I learned to recognise and work on my own anxiety. It also lead me to recognise anxiety in others.
Soon I realised this does not only affect other people but also organisations and processes. Let me introduce you to anxiety driven development.
Continue readingIn my years as a software engineer I was always drawn to the shiny new things. But time and time again I got confronted with code ridden with technical debt. If you are working in tech you probably heard of technical debt.
For product managers it is the sword of Damocles alluding delayed projects and rejected feature requests. For engineers it can be a tremendous source of frustration and reason to quit jobs and move on. Why is technical debt so widespread and why is it so hard to beat?
Continue readingProduct owners need a diverse skill set to be successful. Your past experience, your current organisation and the specific industry make the requirements to your job unique. Nevertheless there are some common pitfalls and anti-patterns which many product owners unwillingly fall into. This short list of product owner anti-patterns hopefully helps you to avoid these common errors.
Continue readingA sure way to improve your product is to involve the whole team in product ownership. This third and final part focuses on practical steps you can take to accomplish shared ownership in your daily work life.
Continue readingThis is a summary of my “Today I Learned” moments of the calendar week 13 and 14. Topics are product inceptions, the DIBB framework and audio editing.
Continue readingIn agile teams the use of both Scrum and Kanban is widespread. What is the difference between Scrum and Kanban? At what point does it make sense to use Kanban over Scrum?
This article helps you identify the limitations of Scrum and when it is time to break with the rules. It outlines how Kanban can be a natural evolution for Scrum teams.
Continue readingThis is a summary of my “Today I Learned” moments of the calendar week 12. Topics are working remotely, maturity models and a quick summary of the book Radical Focus.
Continue readingThe product owner role is overburdened with too many responsibilities. Therefore a product owner can become a bottle neck and knowledge silo. Both of these traits lead to a cascade of issues.
This second part focusses on the benefits of a more collaborative but unfortunately less common approach to product ownership. It will highlight the principles, advantages and risks of collaborative product ownership.
Continue readingThis is a summary of my “Today I Learned” moments of the calendar week 11. Topics are innovation games, schemaless databases and measuring output.
Continue readingThis is a summary of my “Today I Learned” moments of the calendar week 10. Topics are user interviews, technical debt and getting ready for being a podcast guest.
Continue readingThe product owner is a crucial role in every Scrum team. They are the interface between stakeholders and the development team. They stay in close contact with customers and listen to their wishes and needs. They organise the product backlog
Unfortunately this role is doomed to fail. Here is why and how we can fix it.
Continue readingThis is a summary of my “Today I Learned” moments of the calendar week 9. From chess to excel and pair programming.
Continue readingUnclear stories make unpredictable, inefficient sprints. They demotivate the developers. It spawns an environment of “them versus us” thinking.
You want to ensure that you document your user stories, have meaningful discussions around them and confirm that everyone has the same understanding. Easier said than done. How can we achieve this?
Continue reading