The Product Owner role for a software product in an industry where the core business is not IT is a business enabler, a business transformation agent and an innovation partner. Someone who his success depends on the success of the business he supports. Sometimes it reminds me a marriage, an alliance. In this post I would like to approach the skills set I recommend for hire one if you are considering it. Continue reading If you are out of software industries and you are planning to hire and IT Product Owner, you must read this post!
Once you go Agile is a personal blog, my personal project started in the beginning of May. I’m very happy to communicate: we turned 150 followers only in Instagram last week! Additionally around other 100 followers in other social networks.
(Berlin, Memorial to the Murdered Jews of Europe) – Some weeks ago, when I visited the Memorial, the feeling of loneliness and lack of direction invaded me. I think this is the main achievement of the architect (Peter Eisenman)… bring this feeling to the visitors. And from the position in the picture I asked to myself “What have we learned from this horror?”. Inspired by a continuous learning for a continuous improvement, I would like to make the question applied to bugs and change requirements (CR), but particularly in this post: what can we learn from bugs? We should take them all as improvement opportunities.
In my last post I didn’t have room to explore other backlog issues, which become more important once it starts the implementation phase: bugs (or defects) and change requirements (or change requests – CR). Bugs must be included in the backlog, they will take capacity to be solved and they bring user dissatisfaction. In this post we will touch different questions: which type of bugs and CRs we can face, in which contexts we will face them, who normally will report them into the backlog and the product owner dilemma between occupy capacity with new feature or fixing bugs or improving/ adapting product details (CR).
(Berlin, Germany) Sometimes the most obvious Agile concepts are not so easy to be applied when we need to make a practical usage of them. Specially if we need to bring into a consistent and common understanding a product or portfolio vision for later implementation. My goal with this post is to share a very personal opinion about how and whom should fulfill those Agile requirements levels.
A backlog is such an important asset for each Agile Team and even more important for a company who understands the value to demand for high quality content and well organized backlogs. What I would like to share with you today is a set learnings I did since I’m working in Agile.
A release plan is an extremely important negotiation process. It should be factual, considering dependencies, anticipating risks and sharing with your Product Owner concerns, plans to improve the product in non functional requirements (e.g. QA, Security, Performance, etc.). You are managing expectations, challenging how reliable is the predictability of your dev team. But should you only consider your MPP? How can you avoid emotions in the release planning process?