Jason Gorman"We tried Agile and it didn't work?" Did you try the part where empowered, self-organising teams rapidly iterate production-quality software based on direct feedback from end users and continuously reflect on and improve how they work?
Florian@jasongorman … where self-organized teams own a business metric and iterate on that.
@Rafa The problem with metrics is they usually need to be balanced against other metrics. Otherwise we can end up with teams effectively pulling against each other.
@jasongorman fair point. However, without relevant metrics, teams have no guardrails for the things they do and lack accountability.
@Rafa Businesses have to be very careful what they wish for. Most orgs design measures so naively that teams can destroy the enterprise trying to meet their targets.
@jasongorman Absolutely. Metrics is a very complex matter (gaming them, are they really measuring success, …). On the other hand, if you want top management to trust the engineering teams and grant autonomy, you need to find a way to give them direction and to hold them responsible for what they are doing.
Daniel Barlow@jasongorman @Rafa anecdote time: I worked on a team which had responsibility for the second half of the customer purchase journey, another team looked after the first half. We both had metrics for user dropoff rate and we both tried to improve those metrics by moving journey steps (e.g. “ask the user for their correspondence address”) into the other half of the journey.
@dan @Rafa My party trick back in my contracting days was performance measures design. As with all design, it needs to take into account multiple stakeholder perspectives (balanced, basically), it needs to take into account gaming (give a man a target and he'll destroy the business to meet it), and it needs to iterate.
@dan @jasongorman Yes, two teams with the same metric might cause so many conflicts (blame game, etc.).