Posts Tagged entropy
“To shape it, destroy it” Lao Tzu.
Recently I had a Scrum introduction for a small team of developers at my friend’s office. There were huge amount of questions I dealt with. However one looked more challenging to handle: “How team of developers can work without team lead? How group of 5-7 people can be equally responsible for success?” Followed by “It simply will not work. You suggest to destroy everything. One needs to tell them what to do” statement.
Well my immediate answer was: “Team needs to be formed and as soon as “one boat in ” unavoidable storming starts that makes team glue and self-manage in most natural way, so that no specific role needed to tell them what to do”.
Afterwards this question lead to insights on how it would be easier to explain self-organization and steps to get there to Agile newbies…
Old style symptoms
- What if group of people that just starts to work together does not want to glue, or it takes much time for them to form and come to storm?
- How to make them storm earlier and faster?
- What if you observe stand-ups when no one interested in what others did/up to and everyone report to Scrum Master?
- Silent (or 100% happy) retrospectives?
- People avoiding conflicts?
- Or you see how people with old-style mindset wait that someone will tell them what to do?
- Poor or no peer-management?
All these are the symptoms of no teamwork. These teams will unlikely deliver on time, having quality in.
As Ester Derby states: “Groups that avoid conflict won’t be able to face tough issues or handle the creative conflict that generates new ideas”.
Well, self-organization requires definite mind-shift, time and efforts. If that does not happen, team facilitators (coaches, scrum-masters) need to make them storm. Sometimes “throwing” team into storming helps here. Here is how.
“Throwing” team into storming
Here is simple, fast (and a bit harsh) way of doing it. Usually applicable when there is not much time to hit the deadline:
- Take (or invent) the deadline. A bit less than realistic is fine. Needs to be challenging. That is easy, ‘cos business usually has them.
- Make it clear when achievement considered as success and when it’s considered as failure, based on outcome.
- Communicate the deadline and cultivate sense of urgency within team. Tell the team that business needs predictability;
- Point out that all this matters if the outcome (product) is releasable;
- Bind team objective with result (and eventually a paycheck);
Look what happens with forming stage team when it goes under pressure like this. It immediately starts storming. It simply has to storm, otherwise it will be unable to realize their potential as a team and eventually will be closed down (I intentionally worsen things here).
This is pretty much like in physics. You increase “pressure” and the measure of disorder of the closed system, called entropy increases as well. Storming is kind of disorder. The outcome of it however is the order.
That’s just beginning. Observe what happens further. Some people will start to manage peers. Some will invent norms. Others will start to call for those. Some will start to follow. Not all. Some. Some may become “Mavericks”. Others, resisting “bad guys”.
Team starts storming. It’s hard, harsh, emotional, but normal and needed. It’s unavoidable step for team to really glue together, fit best way and become a TEAM. It’s the price to pay to get team on their path towards being truly self-organized and hyper productive.
As an Agile leader (or Scrum master) you need to observe this stage very closely and take care of conflicts to resolve them in the way to lessen distressing impact on team members. In short, – take care of people!
After a while you will figure out that storming goes down (although it never ends, just becomes more “constructive” and less hard to do) as your team starts to balance each other and having some “roles”. It depends on individuals managerial skills, characters and combination of people in the team.
“The end” of Storming
I’ve seen team that ended up storming phase having several “team leads” (almost entire team) that managed each other. But compared to one formal team lead, they’re deserved and recognized leaders rather than formal authorities. Therefore, such a team is way stronger as managerial unit than a team having single and given team lead.
Let me explain that differently….
Several managerial roles in such a team are mutually complementing, since everyone manages some parts/aspects, focuses on different areas, sees picture from different angles that fits together naturally and keeps right balance between chaos and “autocracy”. Among other benefits of working together, self-organized team has an ability to compensate each other’s negative sides that allows them to become way better. Rare person can compete with such a “balanced mix”.
That makes self-managed team stronger.
And my answer to the question in the beginning would be “YES”. At some point you need to destroy things to re-shape them.
June 2020 M T W T F S S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
- Learning LeSS with @scaleagile day2... looking forward:) 10 months ago
- Some simple tool for coaches of multi-team Agile environments... lnkd.in/d6uXaB2 #kaizen #scrum #scaledscrum #coaching 1 year ago
- Radical transparency is essential for Scrum to function optimally, but it is only possible in an organization that… twitter.com/i/web/status/1… 1 year ago
- Emergent Improvements over managed changes rsastories.wordpress.com/2018/08/01/nat… #agile #kaizen #changemanagement 1 year ago
- Success and Failure by @management30 #behavior #experiments slideshare.net/management30/s… via @SlideShare 2 years ago
- account management Agile Agile Development Agile software development Benjamin Franklin Brain rules burndown chart Business Business Services client management Clients Commitment Confidence Context-switch CSM Customer Management Customer service Decision making entropy Epic Ester Derby Expert sales Focus HR management Human resources INVEST (mnemonic) IT Management IT services sales Jeff Sutherland Kaizen KANBAN Leadership Management Marketing and Advertising Mike Cohn Motivation Planning poker PO Product Management product owner Product Roadmap Rate of return Sales Sales management Salesmanship SCRUM scrum master Scrum Tools Self-organization Self-organized Servant Leadership Service quality Social group sprint planning Storm Storming storymap Team team balance Team building Team DNA Team dynamics teamlead Teamwork toolbox User story user story points WIP