Whenever I work with teams in product development, I have two main goals: create value for the user and make sure the team is happy. Though there are many more, I honestly believe that a happy team and value for the user are by far the most important. Everything else is downstream from those two.
The daily stand-up, daily scrum or simply the daily is the shortest of the Scrum ceremonies. If done right, the daily scrum is a very effective ceremony for removing issues, sharing information, team-building, and improving communication.
Along with the refinement, I find the sprint retrospective to be the most important ceremony within the Scrum Framework. It embodies one of the main features of agile product development, iterative improvements. This is, in my view, at the heart of agile product development. Iteratively improving not only applies to the product itself but also to the developmental process, the method of collaboration, and used frameworks.
Creating a product vision is not overly complicated, if you keep three things in mind. Start with users, involve others, and write it down.
To me, there seem to be six characteristics that describe any well crafted product vision. Many more exist but the following stand out to me in describing what a compelling vision is.
A product vision is of paramount importance. This seems to be a given. You can find a lot of material that simply states this as fact without explaining why this is the case. Many write about what a vision is and plenty of folks provide frameworks or methods for creating a product vision. However, rarely do they explain why the product vision is needed, what the reasons are for creating one. It seems to simply be assumed that everybody already knows. Why is it so important?
All companies know their What. It is what they are offering, the services and products they are selling. Some companies know their How. It is how they are building and offering their products and services, their values, their culture. The how is often also called Unique Value Proposition (USP). Only the rarest of companies are able to actually say Why they are doing what they are doing, what the real motivation is, what their purpose is
Agile is not Scrum, Lean, Kanban, DevOps, Extreme Programming, or any other agile method used in modern product development. Don´t get me wrong, all of these frameworks have a reason for being. I am working as a Scrum Product Owner (PO). We are successful and I thoroughly enjoy using this method. Scrum is one way (of many) to manifest and formalize agile principles. It is not equal to Agile. Agile development is a mindset centered on principles.
I recently wrote about the core competencies of a Product Owner (PO). Within that text I didn´t address technical skills. This topic is large enough to warrant a dedicated post. Well, here it is. Does a Product Owner (PO) need deep technical understanding to be successful?
In my view, the short answer is a clear NO for the vast majority of products. The long answer is a bit more nuanced: it depends. Overall, I do believe that technical understanding for a PO is a net positive. However, it can also lead to some negative outcomes.
I will dive into the pros and cons first before addressing some general points.
Besides Scrum, Kanban is probably the most prevalent system for managing workflow in agile product development. It is a very flexible system, with little overhead. As such, Kanban is very easy to implement. Many enjoy the feeling of flow that results from using a Kanban system.