Dependencies in Software Development have been an issue since decades and lots of practices have been built to “manage” them, creating an environment that becomes more complicated with longer time-to-market times as dependencies grow (or the product/solution grows).
This is creating an illusion and no dependency management is alwys the only answer! Coordination to remove dependencies is usually a more sustainable outcome with less management.
One of my biggest hobbies is participating in Live Action Roleplay events, larp in short.
For years I've also been organising such events for a couple of non-profit organisations.
Last year I finally took the plunge and used some agile techniques for running of the event.
It should not really have surprised me that this was successfull, but still it did.
This is the second article about Kanban Metrics. The first article was about the Cumulative Flow Diagram, used to measure the throughput time for items in your backlog. The time it takes to go from “In Progress” to “Done” and then projected over a period of time.
But what are the ways you can use a Control Chart?
The end of the year is nearby, time for some New Year’s resolutions! As I experienced a lot of stress within the role of Scrum Product Owner, and as I know you’re busy, I’m going to help you get started…
Here are 20 New Year’s resolutions to get you started:
Wether you do a lessons learned, retrospective or kaizen event, the actions from there should be executed as soon as possible by the team. But sometimes problems that arise from these events are beyond the team's circle of influence.
If you have read the article of Annelies de Meyere about detailed metrics are not always the answer, you must think why this article? Well some metrics are good!!! It’s the best way to see how you're doing with your team. But as described in the article of Annelies over-metric is bad, it’s not a weapon to use against your team or one member. It’s not a weapon for your KPI’s. In this way you’re doing something wrong.