Language can sometimes prove to be a barrier to ideas. We sometimes get caught up in arguing about the language rather than evaluating the ideas presented. The spirit of the message here is spot on, which isn't really that "autonomy" doesn't mean "do whatever" (in fact, that's pretty much the definition), but rather that agile teams often (but not always) need a measure of boundaries and constraints to best achieve a larger goal. That is really to say, agile teams can't always be 100% autonomous. We can redefine what it means to be autonomous to fit our idea of the perfect combination of freedom and constraints for a particular scenario we envision in our mind (e.g. multiple scrum teams working toward placing a probe on Mars), but in doing so we risk shifting the focus toward defining/re-defining language rather than communicating ideas. Being agile is ultimately about efficiently adapting to change. In the first part of the presentation, the statement is made "Being agile doesn't mean not doing documentation." We might make a similar statement: "Being productive does not mean laying more bricks". Both statements are true: the core definition of being agile isn't to not do documentation as the core definition of being productive is not laying bricks. Both of these are contextual examples of being agile and productive respectively and both can be examples of the concept or examples of negating the concept based on the given situation. To a customer, using a new system or a new version of an existing system is a change. How do we equip our customers to adapt to such change? One good way is documentation! Additionally, source code often changes too rapidly to reap a return on investment in attempting to document it and it actually can serve as an obstacle to development. How do we adapt to a rapidly changing codebase? We decide to not do documentation! The point, the solutions we use to adapt to change are contextual to each situation just as is the issue of what level of autonomy to afford an agile team. The trick is to find the balance: continuously tune the level of autonomy and boundaries to best achieve the objective. Generally, this should mean leaning toward autonomy, placing the burden of proof on boundaries, and then evaluating ways to increase autonomy. For example, if you reason that multiple teams should all be forced to use the same programming language (e.g. Java), those presuming such constraints should justify the need of the constraint (e.g. "Teams need to use each other's code!") and if true, ways to eliminate the need for the boundary should be sought (e.g. "Event-driven architecture decouples the need for disparate services to be written in the same language!"). Anyway, good ideas. Sometimes the right level of "autonomy" isn't 100% and sometimes being agile doesn't mean not doing documentation.
I really liked this explanation of autonomy! I work a lot right now with stuff that agile anarchists does not like, constrains, boundaries, processes etc. I think a big challenge and why team don’t prioritize these areas are that the responsibilities are put on the teams but they do not have the knowledge to take on the responsibility, meaning these teams will never prioritizes these important areas among the long list you mentioned that they should divide their time on. Meaning they will not be owning it, they own only what they know of and within stuff they can master!
Well done! Who would not want to create one’s own destiny! Great summary of a deeper understanding of autonomy. Clarity is a great driver of comprehension.
This is a WONDERFUL video that I just shared in one of my corp chat channels. I really like the way you navigated the "middle path" between top-down micromanagement nonsense and "agile anarchy" (the latter term really really cracked me up, thank you for that one).
This video series is WONDERFUL, thank you so much Jimmy, I'm trying to learn how to better engage my team, especially during the pandemic when everyone is so burnt out and the boundaries between work and home are really starting to blur (lots of work from home). I'll probably watch many of your videos today, thank you!
This had some great ideas about autonomy. One thing though... you don't seem to understand *anarchy*. Anarchy is not chaos. Anarchy means "*without rulers*". All the ideas about ownership, boundaries, expectations apply to true anarchy where people learn to interact with each other without coercion or violence.
Language can sometimes prove to be a barrier to ideas. We sometimes get caught up in arguing about the language rather than evaluating the ideas presented. The spirit of the message here is spot on, which isn't really that "autonomy" doesn't mean "do whatever" (in fact, that's pretty much the definition), but rather that agile teams often (but not always) need a measure of boundaries and constraints to best achieve a larger goal. That is really to say, agile teams can't always be 100% autonomous. We can redefine what it means to be autonomous to fit our idea of the perfect combination of freedom and constraints for a particular scenario we envision in our mind (e.g. multiple scrum teams working toward placing a probe on Mars), but in doing so we risk shifting the focus toward defining/re-defining language rather than communicating ideas. Being agile is ultimately about efficiently adapting to change. In the first part of the presentation, the statement is made "Being agile doesn't mean not doing documentation." We might make a similar statement: "Being productive does not mean laying more bricks". Both statements are true: the core definition of being agile isn't to not do documentation as the core definition of being productive is not laying bricks. Both of these are contextual examples of being agile and productive respectively and both can be examples of the concept or examples of negating the concept based on the given situation. To a customer, using a new system or a new version of an existing system is a change. How do we equip our customers to adapt to such change? One good way is documentation! Additionally, source code often changes too rapidly to reap a return on investment in attempting to document it and it actually can serve as an obstacle to development. How do we adapt to a rapidly changing codebase? We decide to not do documentation! The point, the solutions we use to adapt to change are contextual to each situation just as is the issue of what level of autonomy to afford an agile team. The trick is to find the balance: continuously tune the level of autonomy and boundaries to best achieve the objective. Generally, this should mean leaning toward autonomy, placing the burden of proof on boundaries, and then evaluating ways to increase autonomy. For example, if you reason that multiple teams should all be forced to use the same programming language (e.g. Java), those presuming such constraints should justify the need of the constraint (e.g. "Teams need to use each other's code!") and if true, ways to eliminate the need for the boundary should be sought (e.g. "Event-driven architecture decouples the need for disparate services to be written in the same language!"). Anyway, good ideas. Sometimes the right level of "autonomy" isn't 100% and sometimes being agile doesn't mean not doing documentation.
I really liked this explanation of autonomy! I work a lot right now with stuff that agile anarchists does not like, constrains, boundaries, processes etc. I think a big challenge and why team don’t prioritize these areas are that the responsibilities are put on the teams but they do not have the knowledge to take on the responsibility, meaning these teams will never prioritizes these important areas among the long list you mentioned that they should divide their time on. Meaning they will not be owning it, they own only what they know of and within stuff they can master!
Jimmy you are a star! That was clear and concise and engaging. Well done 👏
Well done! Who would not want to create one’s own destiny!
Great summary of a deeper understanding of autonomy. Clarity is a great driver of comprehension.
Very concise ❤ I've never seen such good explanation on this topic.
Thank you for more explanation and clarity on autonomy.
This is a WONDERFUL video that I just shared in one of my corp chat channels. I really like the way you navigated the "middle path" between top-down micromanagement nonsense and "agile anarchy" (the latter term really really cracked me up, thank you for that one).
Thank you so much Sandra for your kind words :-) And for sharing the video!
Great explanation of what happens when you give up your autonomy.
Thank for this! I was discussing this topic with a friend the other day. Will share this video. 😊
Thank you Unn! Happy to hear you liked it ☺
This video series is WONDERFUL, thank you so much Jimmy, I'm trying to learn how to better engage my team, especially during the pandemic when everyone is so burnt out and the boundaries between work and home are really starting to blur (lots of work from home). I'll probably watch many of your videos today, thank you!
Thank you Vanessa! 😄🙏 I hope you find more videos that you enjoy.
This had some great ideas about autonomy.
One thing though... you don't seem to understand *anarchy*.
Anarchy is not chaos. Anarchy means "*without rulers*".
All the ideas about ownership, boundaries, expectations apply to true anarchy where people learn to interact with each other without coercion or violence.
Awesome work, Jimmy!
Thank you Sandy 🙏
Awesome as always Jimmy
Thank you carnub!
thanks for the video
Brilliant!!
Thank sir as always.
SIR Do you recommend a agile book or ebooks that i can read? I am a psm1 scrum practitioner but wanted to become an agile coach soon.
I've listed some books I recommend on this page agilewithjimmy.com/agile/
Hopefully some of them sparks your curiosity.
We need a more concise model of autonomic employees