Why Team Self-Design through volunteering matters?
--
Hello everyone,
I’m finally getting back to you after a few years of slacking with this blog. This period gave me plenty of experiences and stuff to share, and I’ll try to keep it valuable for you.
One of your Scrum Teams is close to getting too big? Your company experiences the need to re-organise its R&D or Engineering department? You identified the new opportunity area or compliance threat within your Product and would like to create a “SpecOps team” to work on it?
I am pretty sure many of you have experienced at least one of these situations in your career, and let me guess how your management addressed it:
“Take Aly, Tania, James and Nancy and put them together to work on it.”
or
“We (Management team) have spent quite some time to prepare the new teams structure — you can find it in the Google Spreadsheet. Next Monday we’ll announce it during the Townhall event.”
or
“We made a decision to outsource this problem. Starting next month we’ll have Team A from Company B work on it full-time.”
All these responses could’ve successfully served as a catch-phrase for yet another Dilbert comics. If any or all of them are not part of your organisational culture, I can only congratulate you — it seems like you are a part of a friendly company that trusts its employees to be professionals. Though, you may still benefit from reading the rest of this article.
If you recognise any of these patterns in your daily work life — keep reading.
“Why?” behind the Team Self-Design
Let’s start with the very basics. Specifically, with a few of principles behind the Agile Manifesto:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
One reason for that is the fact that:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Feel free to revisit one of my early articles (available in Russian only, sorry) to get my viewpoint on self-organisation and how…
