Tobias Fors

Tag: selforganization

  • Learning About S3

    Learning About S3

    Sociocracy 3.0, or S3 for short, is a collection of principle-backed patterns for more effective collaboration. It can be seen as an attempt to reduce hierarchy while at the same time providing an alternative type of structure.

    This week I’m attending a three day workshop about sociocracy 3.0, or just S3 for short. The idea of sociocracy has apparently been around for a very long time. The class I’m attending is focused on “S3”, created by James Priest and others as a continuation of the idea of sociocracy.

    Patterns, here, can be explained as previously observed behaviors that have been collected and described for future use. They are linked together in various ways, so that they can complement each other.

    I find sociocracy and S3 interesting because it might hold some clues for how to answer some currently important questions, like:

    • “We like self-organizing teams – but how could we get self-organization on a larger, organizational, scale?”
    • “If we remove the traditional organizational power pyramid, what should we replace it with?”
    • “I like the principle of self organization, but I can’t see how.”
    • “How can we be more agile outside of software development – maybe in the whole organization?”

    I like the idea of a collection of patterns backed by principles. This is how Scrum started out, and while too many have only experienced Scrum in it’s most ossified form (blindly following a subset of the practices, with none or little focus on the principles) – Scrum is still most interesting when seen as patterns on top of princples. I would actually be very happy if the official description of Scrum could evolve more in the direction of more open patterns, building on the same principles as now – but more about that in a future post, maybe.

    In general, I would love to see less discussion about which framework a given organization is using, and more about which patterns they have chosen to adopt and how they are tying them together. S3 fits perfectly into this desired reality, and I look forward to learning more over the coming months and years.

    What are you doing to spread the principle of self-organization in your organization?

    Learn More About S3

  • Why Task Assignment Sucks

    You may be like me. Some things at work suck the life out of me. I can’t always explain why. Most of the time I can learn to live with it, and therein lies the crux. I accommodate things that I really should refuse outright. Here’s one such thing: task assignment. See if you agree.

    Assigning tasks. Also known as the age old habit of telling others what to do. Try to go a day without doing it. It’s pretty hard, especially if you have kids. Probably also hard if your title includes the word manager.

    SO what’s so bad about assigning someone a task? After all, it can’t be that bad – there’s even support built in for doing it our planning software. Assign to person X, that’s what the buttons say.

    Here’s why this bothers me. I’d much rather pick my own tasks. After all, I was hired to do what I do. Or at least I haven’t been fired yet. However it is: I’ve come to trust myself (at least some of the time) to choose which tasks will best take me towards the goals we’ve agreed upon. If we haven’t agreed on goals yet, I definitely can’t see why you would tell what to do. We should talk about goals before we do anything else.

    Being assigned or picking. It might seem like a meaningless play with words, but I believe that the words we choose reveal something about our world view.

    In one world view, people are resources to which we assign tasks. Worker threads that waste cycles when idling.

    In another world view, people are people. Fully capable of filling their own work day with the right stuff, given a little bit of wise guidance.

    You might think: ”sure, letting people pick their tasks would work with an experienced and motivated team – but you haven’t met my team. If I don’t tell them what to do, nothing at all gets done”.

    To this I could reply: ”OK, your team sounds like it’s struggling. Have you tried giving them a juicy goal, and then letting them figure out how to reach it?”.

    You in turn might just reply that you have indeed tried that, and that it didn’t work at all. Nothing did get done, as you knew it wouldn’t. Or maybe the wrong things were done.

    Then I’ll ask you what you did next. If you now say that you stepped in and assigned tasks to people, then you might be able to see where the problem is.

    Assigning tasks robs people of the ability to learn how to figure out the way to the goal themselves. It’s a learning stopper, and if there’s something we need more of in today’s organizations it’s learning.

    In the end I don’t care if your buttons in JIRA still say ”Assign”. JIRA is a tool. You’re not. You know better.