Hi John - I found this really eye-opening - I really hadn't considered this from the point of the underlying beliefs before. This finally make sense of some of my past experience, and helps enormously with my current situation :-)
I've twice had the experience of moving to a backlog-centric team after being part of a highly successful mis…
Hi John - I found this really eye-opening - I really hadn't considered this from the point of the underlying beliefs before. This finally make sense of some of my past experience, and helps enormously with my current situation :-)
I've twice had the experience of moving to a backlog-centric team after being part of a highly successful mission-centric team, and struggled both times. The first time I had to (re)learn the backlog-centric ways of working, and they felt like a big step backwards, but I had to adopt them to become an effective member of the team. The second time, I was coming in as an engineering manager trying to introduce mission-centric practices to backlog-centric teams, and causing a lot of trouble and pain in the process!
With this new insight about beliefs, I can now make sense of this...
In particular the belief that developers should only take on well-vetted and validated work (and this usually goes hand-in-hand with a belief that work should be prepared such that any developer can pick up the next ticket) - once you've worked in a mission-centric team, these beliefs feel like anti-patterns - but they are fundamental to making the backlog-centric team work, and so you mess with them at your peril! The level of stress and the reaction can be intense - for example if you do anything that prevents the slick functioning of the grooming process, some of the team may almost think you are out to kill them.
With time, you can replace this pair of beliefs with a preference for working x-amigos style for collaborative understanding of the problem and generation of possible solutions - and once everyone is on board with that, no one wants a whole-team grooming session or tasks that are ready for any developer ever again - but it can take a few months to get there!
(I had one question also - at the end of the backlog centric team, did you mean that developers' responsibility is to "build the right thing right", or just to "build the thing right"? In my experience, the backlog-centric team's processes aren't optimised for identifying the right thing to build - they kind of assume someone else has done that for them...)
Hi John - I found this really eye-opening - I really hadn't considered this from the point of the underlying beliefs before. This finally make sense of some of my past experience, and helps enormously with my current situation :-)
I've twice had the experience of moving to a backlog-centric team after being part of a highly successful mission-centric team, and struggled both times. The first time I had to (re)learn the backlog-centric ways of working, and they felt like a big step backwards, but I had to adopt them to become an effective member of the team. The second time, I was coming in as an engineering manager trying to introduce mission-centric practices to backlog-centric teams, and causing a lot of trouble and pain in the process!
With this new insight about beliefs, I can now make sense of this...
In particular the belief that developers should only take on well-vetted and validated work (and this usually goes hand-in-hand with a belief that work should be prepared such that any developer can pick up the next ticket) - once you've worked in a mission-centric team, these beliefs feel like anti-patterns - but they are fundamental to making the backlog-centric team work, and so you mess with them at your peril! The level of stress and the reaction can be intense - for example if you do anything that prevents the slick functioning of the grooming process, some of the team may almost think you are out to kill them.
With time, you can replace this pair of beliefs with a preference for working x-amigos style for collaborative understanding of the problem and generation of possible solutions - and once everyone is on board with that, no one wants a whole-team grooming session or tasks that are ready for any developer ever again - but it can take a few months to get there!
(I had one question also - at the end of the backlog centric team, did you mean that developers' responsibility is to "build the right thing right", or just to "build the thing right"? In my experience, the backlog-centric team's processes aren't optimised for identifying the right thing to build - they kind of assume someone else has done that for them...)