The Prime Directive reminds me of a story Oscar Wilde told. He had been touring America. He visited a saloon in a rough mining town with a placard over the piano that read something along the lines of: "Please don't shoot the piano player. He's doing the best he can."
Great interview! I hope Anio will also read comments here:) I have a question - does "experiment" come from psychology? I think it's the same concept. Do you have any good sources (book, website) with such experiments?
Thank you :-) I don't know where the concept originates from. For me it originates from my years at the university. When I was doing doing research I would make experiments to test a hypothesis. It gave me a lot of freedom to be able to learn from both successful and unsuccessful experiments. It is that freedom that I try to introduce in the teams that I work with. It is not always easy, though, since some see it as a waste of time to do experiments to learn, they think you should just plan the work and get on with it! But a lot of IT systems are complex (see Cynefin en.wikipedia.org/wiki/Cynefin_framework) and one has to learn _while_ building them. Maybe Hypothesis-driven development would be interesting for you to look at? barryoreilly.com/explore/blog/how-to-implement-hypothesis-driven-development/
As well as Barry O'Reilly's stuff, several of my videos talk about this topic, not necessarily about how to apply that to 'people' but certainly for some of the more technical aspects of development, here are a few suggestions, but there are many more on the channel. Experimenting at SpaceX drives 'Engineering' th-cam.com/video/v8f6q4ruvds/w-d-xo.html (These are amongst my first videos, the sound has got a lot better since then!) Experimenting with releases th-cam.com/video/r_E3OyOCvV8/w-d-xo.html Experimenting with product design th-cam.com/video/iV81CHby3r0/w-d-xo.html
- There’s no silver bullet for Software Development but fast high quality feedback is as close as we get. - Soup Exercise (@19:00 in video) - Closing the feedback loop on all aspects of our work is essential to learning and Software Development is always an exercise in Learning. We can use Continuous Delivery Deployment pipelines to close the technical loops - we can release changes into production more frequently - giving us an opportunity to gather information from our customers and so close the feedback loops on the design of our products we create. We can use retrospectives to close the feedback loops on “us” and the way in which we approach our work.
I have huge problem with retrospectives. If a team is speaking about code then we can easily point all bugs or problems related to it and later fix it. But retrospective is about people and we cannot blame each other so indeed points mentioned in the meeting like that are not essential, not very honest and the most important are even not mentioned. Is it proven somehow that retrospectives are profitable and beneficial? Wouldn’t be better to find better alternatives? Like better involvement of more experienced people to teaching less experienced? More trusted and private conversations? Retrospectives seem to go to the target around of real problems.
I think that it is a failed retrospective if it is used to assign blame to people. The object of a retro is to identify common problems, or current blocks to progress and agree how to fix them. It should be much more "what lessons can we learn" than "who can we blame". I agree with you that there is an important place for "trusted private conversations", but they serve a different role I think.
It sounds like a badly facilitated retrospective, if the result is blame an no concrete actions. Things like "better involvement of more experienced people to teaching less experienced" could very well be the one of the things you decided to try out in a retrospective.
Good question. The soup model is simple because it is meant as a quick way of giving an overview of the problems. The red wine thing was mostly a joke. In the Soup activity, the problems are divided into things the team can "do" something about, things the team can "influence", and things that they cannot alter, that are "in the soup". If they choose to put all their problems in the soup I use it to talk about responsibility. Can they take responsibility for their problems or are they deferring, that could be a thing to work in itself. Sometimes, when talking about it, things move from the soup to something they can influence or even do something about. Did that explain it better?
Ignoring the purjorative comment "failed programmers", and reading it rather as "former programmers", my real answer is that I don't know. I am a current programmer, and I guess, sometimes a coach, though I probably do less programming than I would prefer. Many coaches do come to coaching from programming, finding that they enjoy the coaching more, or that they can contribute more through coaching than through programming. I know many coaches that also came from other routes though, so no idea which route is more common. I guess that it is pretty obvious that a reasonable proportion of coaches started off as programminers, in the same way that a reasonable proportion of football coaches started off as footballers. Playing the game gives you a different kind of insight into the game.
Who else would you like to see featured on the channel? 🤔👇
Chris Matts!
Nigel Poulton
Jez Humble. I'd like to hear both of your impressions of Continuous Delivery in our industry since the publication of your book about 10 years ago.
James Bach or Michael Bolton.
Kent Beck!
Thank you to Aino for being such a great guest!
Great session, really key lessons from that
@@l_combo Thank you, I am glad if it could help you :-)
Brilliant!!! I should use more "The soup!" not in retrospectives alone but also in real life.
Thank you :-) I try to use it in my real life as well to not get overwhelmed :-)
The soup exercise is a great model of determining when to find a new job instead of just complaining that you're too restricted :)
I couldn't agree more:-)
The Prime Directive reminds me of a story Oscar Wilde told. He had been touring America. He visited a saloon in a rough mining town with a placard over the piano that read something along the lines of: "Please don't shoot the piano player. He's doing the best he can."
Yes, I think it is the same idea 🤣
I loved the interview. Very interesting! I'll take a chance with the book
We had fun recording it, thanks.
Thank you, and good luck with the book :-)
Great interview! I hope Anio will also read comments here:) I have a question - does "experiment" come from psychology? I think it's the same concept. Do you have any good sources (book, website) with such experiments?
Thank you :-) I don't know where the concept originates from. For me it originates from my years at the university. When I was doing doing research I would make experiments to test a hypothesis. It gave me a lot of freedom to be able to learn from both successful and unsuccessful experiments. It is that freedom that I try to introduce in the teams that I work with. It is not always easy, though, since some see it as a waste of time to do experiments to learn, they think you should just plan the work and get on with it! But a lot of IT systems are complex (see Cynefin en.wikipedia.org/wiki/Cynefin_framework) and one has to learn _while_ building them. Maybe Hypothesis-driven development would be interesting for you to look at? barryoreilly.com/explore/blog/how-to-implement-hypothesis-driven-development/
As well as Barry O'Reilly's stuff, several of my videos talk about this topic, not necessarily about how to apply that to 'people' but certainly for some of the more technical aspects of development, here are a few suggestions, but there are many more on the channel.
Experimenting at SpaceX drives 'Engineering' th-cam.com/video/v8f6q4ruvds/w-d-xo.html
(These are amongst my first videos, the sound has got a lot better since then!)
Experimenting with releases th-cam.com/video/r_E3OyOCvV8/w-d-xo.html
Experimenting with product design th-cam.com/video/iV81CHby3r0/w-d-xo.html
- There’s no silver bullet for Software Development but fast high quality feedback is as close as we get.
- Soup Exercise (@19:00 in video)
- Closing the feedback loop on all aspects of our work is essential to learning and Software Development is always an exercise in Learning.
We can use Continuous Delivery Deployment pipelines to close the technical loops - we can release changes into production more frequently - giving us an opportunity to gather information from our customers and so close the feedback loops on the design of our products we create.
We can use retrospectives to close the feedback loops on “us” and the way in which we approach our work.
I have huge problem with retrospectives. If a team is speaking about code then we can easily point all bugs or problems related to it and later fix it. But retrospective is about people and we cannot blame each other so indeed points mentioned in the meeting like that are not essential, not very honest and the most important are even not mentioned. Is it proven somehow that retrospectives are profitable and beneficial? Wouldn’t be better to find better alternatives? Like better involvement of more experienced people to teaching less experienced? More trusted and private conversations? Retrospectives seem to go to the target around of real problems.
I think that it is a failed retrospective if it is used to assign blame to people. The object of a retro is to identify common problems, or current blocks to progress and agree how to fix them. It should be much more "what lessons can we learn" than "who can we blame".
I agree with you that there is an important place for "trusted private conversations", but they serve a different role I think.
It sounds like a badly facilitated retrospective, if the result is blame an no concrete actions. Things like "better involvement of more experienced people to teaching less experienced" could very well be the one of the things you decided to try out in a retrospective.
I think the soup model may be too easy. If every team just says it's a soup or red wine problem - who will fix it?
Good question. The soup model is simple because it is meant as a quick way of giving an overview of the problems. The red wine thing was mostly a joke. In the Soup activity, the problems are divided into things the team can "do" something about, things the team can "influence", and things that they cannot alter, that are "in the soup". If they choose to put all their problems in the soup I use it to talk about responsibility. Can they take responsibility for their problems or are they deferring, that could be a thing to work in itself. Sometimes, when talking about it, things move from the soup to something they can influence or even do something about. Did that explain it better?
@@ainocorry3004 Yes, thanks for clearifying that :-)
You have mixed together 2 separate concepts. There was no either soup or red wine. There was 1) Soup excercise and 2) Coffee vs Red wine separation.
coffee problems... red wine problems... and "Jagermeister problems" ?
Hmmm, and I thought that Jagermeister was its own problem 🤔 😁
I can totally relate to that.
I hear a hint of Danish in that accent
Det er helt korrekt :-)
@@ainocorry3004 ;^)
Are the majority of Agile "coaches" failed programmers?
Ignoring the purjorative comment "failed programmers", and reading it rather as "former programmers", my real answer is that I don't know.
I am a current programmer, and I guess, sometimes a coach, though I probably do less programming than I would prefer.
Many coaches do come to coaching from programming, finding that they enjoy the coaching more, or that they can contribute more through coaching than through programming. I know many coaches that also came from other routes though, so no idea which route is more common.
I guess that it is pretty obvious that a reasonable proportion of coaches started off as programminers, in the same way that a reasonable proportion of football coaches started off as footballers. Playing the game gives you a different kind of insight into the game.