Many Agile coaches are former software developers, some are not. But when technology moves on, well known Agile approaches can be challenged. Applying the Agile approach of vertical story slicing on microservices is one such example. This talk explains on how as Agile coaches we can coach in technical areas where technology may have moved on, thus challenging the perceived coaching approaches to helping teams become self-organising.
This talks discusses 7 deadly sins of software development, specifically relevant for Agile teams. It’s pretty clear when you fail as a start-up, where you and your friend invested last savings. The product is not ready or just doesn’t get sold, the money’s gone, you open LinkedIn to search for a job suitable for an “experienced software engineer with entrepreneurial background”. It is way more tricky in a big company with a well-established product.
If some consider Scrum as an Agile project management framework, many people consider that is is more a product management approach. Anyway, Scrum is about understanding the need of the customers to deliver value. In this context, the concept of “personas” can be used to support user-centered design throughout a product development cycle by focusing on the characteristics of key user segments.
The product owner role is responsible that the production of the Scrum team meets the requirements of the customers and deliver value for the organization. This is an important role that requires specific skills. But how do you know that your are doing well? The Growing Agile team as created a self-assessment for product owners.
In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions: What do Product Owners really do? Do we even need Product Owners?
This is a talk about how shifting the focus from craft to product has affected my company. Our delivery teams are required everyday to make trade offs between what would the best technical solution and the one that is right for the product they are delivering. Ultimately, we get paid to solve business problems, not to be perfectionists.