Archive for category Self-organized
“Make everything as simple as possible, but not simpler.”
– Albert Einstein
I am going to tell you a story of continuous improvement and how we have enabled those recently in our team of teams… I have picked this story up because situation at many companies is often quite similar:
Although many of them understand need for continuous improvement it gets hard to plan those together with features… and in practice implementations are often missing or poor:
- There is an increasing demand to deliver..
- Development teams are treated as “feature factories”,
- And no time to improve, no time to “sharpen tools” to be more efficient
- More pressure… risking improvements
And all this creates: feeling we are stuck, frustration, demotivates, affects efficiency and quality in longer run… and gets more complicated in multi-team environments… as it also includes agreements and collaboration factors between several teams…
We have tried many things and eventually were inspired by Jeff Sutherland’s Cycle of Scrum Master from Scrum@Scale …and here is what we have done …
But let us understand circumstances first… and how does process look from a single team perspective:
- Development team plans and runs their 2 week sprint…
- That ends up with DONE product increment
- And a delivery of it together with other 5 teams
- These 6 teams are sharing codebase, decisions, tooling and environments together + they deliver in the same cadence
- They talk regularly as Team-of-Teams to Inspect & Adapt their delivery process aka Team of Teams Retrospectives
- In the past they were trying to implement findings of those retrospectives, immedeattely but only few were really managed…
Sprint 1: so this made us thought how we can Scrum those improvements back in sprints…..
- We have obtained an agreement with Product Owner team to let each team pull at least 1 SMALL Task from that backlog per team / sprint and that this task shall be prioritized as a part of the default sprint goal
- We have also agreed within teams to file their improvements as tasks marked accordingly that comprise so called Kaizen Backlog
We have put these decisions into actions and felt results almost after a sprint…
Sprint 2: why we must wait to come up with improvements?…
- Apart from those any team at any moment can propose an improvement and for that thy can use SoS to share their ideas with peer teams
- Those ideas after acknowledged by other teams are also parked in the same backlog
Sprint 3: how to make sure Task is READY? Development of that lead to…
- Distribution of tasks happens latest 1st Scrum-of-Scrum of the sprint for the sprint after current. This we have done for creating enough pace for the teams to refine / groom those and size them so that they are SMALL.
Sprint 4: after a while we have noticed that it would be good to prioritize that backlog…
- Besides regular intervals ToT also joins forces in validating this backlog, checking prioritization, etc. This we call “Kaizen Triage Meeting”. After a while we have looked together at this backlog and understood that we have there 4 types of improvements:
- ProdQuality – Quality of Production (Live Product) is ensured, i.e.Monitoring, Logs, Live Tests
- DevQuality – Quality of Development (or soon to be released) is ensured…
- Efficiency – Saving Time for Development, …
- ProdPerformance – Performance of the product for end users
On top: We have also thought about some symbolic celebration …
- After team implements an improvement task, they get a STAR
- Default expectation 1 star per team per sprint, but in practice some try and did more…
- After each sprint we acknowledge how many STARS we have produced all together!
- Many small practical improvements fast
- Feeling of continuously “steering” our technology
- Increased motivation and feeling of ownership in teams
- Was measured by tickets inflow / outflow + happiness
This worked because:
- improvements were small, easier to plan, implement and deploy them
- therefore, they are also less risky to do
- process is simple lightweight, easy to follow
- shorter improvement cycle allows faster response
- queue of the backlog is short and manageable
To keep the body in good health is a duty,
otherwise we shall not be able to keep our mind strong and clear.
Every self-organized team requires periodic “healthchecks”. With this idea I have started to surf web in search of the best tooling that could help me with the agenda for my team’s Teambuilding retrospective….
At the same time team was “storming” and needed help to get into Solution-centric thinking …
My search resulted in making mix of two techniques and I would like to offer ready retrospective script to Scrum Masters. So, “retrospective-cocktail” I am coming up with here “mixes” “Team Barometer” & “Scaledance of an Aspect” techniques serving team to imprive key aspects of Teamwork.
This is survey-workshop format excerscize adressing 16 team characteristics, packaged as a deck of cards. Download the cards, print them, and cut them out. You want one deck for each participant. Click here to download the cards.
You also need voting cards. Original script reccomends one green, one yellow and one red card but I have used 3,2,1 and 0 planning poker cards (yes, I’ve intentionally modified and introduced the 4th state not to result into “let us take golden middle everywhere”).
Each card has a headline naming a characteristic of a team, and a green and a red statement. Excerscize is to read them out loud one by one, give people a couple of seconds to think and ask them to “poker” this aspect, collecting sum of all votes and NOT discussing estimates like in classical planning poker. Attached you can find list of aspects with an example estimates Team_Healthcheck_Aspects
Scaledance of an Aspect Approach
Idea is as simple as 0-to-10 scale with 10 representing the desired goal and 0 representing its opposite. It provides three focal states for the conversation:
- NOW: Where we are now? (value=N, current state) – an account of all that is currently contributing to that future, including past successes
- GOAL: Where we want to be in the end? (value=10) – description of a best possible future
- STEP: Where we would like to move to? (value = N + 1) – exploration of possible progress in the immediate future
Powerful questions and methaphors for those 3 states are:
NOW (methaphor: let us look back):
- Where do we stand at this moment?
- What works already so that you are already at N rather than lower?
- And how it is now?
- What is happening now?
- How did we manage to be at N?
- What was our contribution?
GOAL (methaphor: let us look back from the future position):
- What will be different, when we reached 10?
- How will others notice that we reached it?
- Suppose we reachedit, what will we do differently?
- How does the “bright” future looks now?
STEP (methaphor: imagine we are already at N+1):
- On this scale, where do we want to be, for example, in 1 month?
- Imagine we are at N+1 now. What is different?
- And what else our collegues, management, etc. might notice?
Key here to first talk about states (and not immedeately jump to actions). In Scaledance exscerscize states seen as “goal setting” tool.
- Introduction & Agenda – 5 min
- Checkin / Warmup – 5 min
- Healthcheck: aspects estimation – 15 min
- Write aspects on the board / wiki/confluence page and record sum of estimates
- Make sure you do not record individual estimates, rather how many 3,2,1 and 0s we have
- Make sure you do NOT ask “whys?” to the estimates
- All that counts is the sum of estimates of all team members
- Healthcheck: prioritisation – 5 min
- Here you can ask each team member to come up with the “backlog” of their desired top 3-5 aspects they would think team would benefit most discussing
- Then you can ask team to collaboratevly produce joint backlog of top 3-5 aspects
- This is important step as lowest estimate of an aspect does not mean this is the most important one, some of them are in realtion to one another and this relation totally unique for each team, so only team members can choose what would they benefit from the best.
- Scaledance of an aspect – 30 min per topic
- Running Scaledance for desired aspect: Now, Step
- As aspect – card already represents 0-state and 10-Goal-state you do not have to specify them
- Ask team to Describe NOW, e.g. by giving them 3 minutes for producing sticky notes
- Brainstorm together to define how N+1 looks like
- Derive Actions to make N+1 happen
- Proceed with the next Aspect
- Closure & Feedback – 5 min
Resources / Techniques / Copyrights / Thanks:
Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.
Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.
I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.
Let us discover some sick stand-up/self-organization symptoms first…
1. Refraining from exposing problems (ignorance of reality):
- Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
- Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
- It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
- Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
2. Intolerance to critical feedback:
- Team member pushes back heavily when someone tries to rise a problem related to his/her task;
- Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
- Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…
Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?
If yes then…
Try out following cures ….
- Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
- Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
- Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
- Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
- Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
- Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
- If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
- Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
- Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);
To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.
“People like talking about people. Makes us feel superior. Makes us feel in control.
And sometimes, for some people, knowing some things makes them care.” [HouseMD #113]
As described in earlier post in “TEAM: 7 indispensable ingredients for Together Everyone Accomplishes More” one of the key elements of a strong team is Brand.
An idea to apply known brand-building practice to team management seemed to me interesting and made me write this blog post.
So I would like to cover a useful tool that can be applied to build up your team brand…
Team Brand is essential team motivator that cannot be given to the team (by company, management, money, etc.), it needs to be build inside, owned and maintained by the team. Actually this is type of “achievement” and “idea”-motivator for a Team (here cross-functional, self-organizing teams are meant, although practice is applicable for any team of small size).
In other words, Team Brand serves as an alignment on its core values/ways to achieve, inspires team by having strong and challenging core set, while distinguishes team among others.
Team brand may be built as any corporate brand starting from key cause or a purpose, moving from core through the benefits (qualities, values) to attributes (tools, norms) supporting and transmitting them.
Well, but an agile self-organizing team needs a hint to start thinking of themselves as a “company”, having a “brand”. A hint that envisions this mind shift would sound like: think of your TEAM as of an entrepreneurship and your collaboration as of an inspiring challenge! Imagine you’re running business with your peers (which is not that far away from reality, considering self-organized development team doing SCRUM).
- WHY are we here, what we want to achieve together, what is our core, our strongest believe and our purpose? Why do we exist as a TEAM? Which core value we all share?
- HOW we can make this happen? What principles (benefits, qualities) support this?
- WHAT we exactly will do (and will NOT tolerate) to support each of the key principles we’ve agreed upon that contribute to our purpose?
A tool I recommend to use at this step to create and maintain team DNA is known “Team Radar” retrospective facilitation activity (see “Agile Retrospectives: Making Good Teams Great” by Esther Derby and Diana Larsen for detailed explanation).
It simply suits best this exercise. Here it is used to gather data on team itself and perform self-assessment in the future.
An outcome applying this practice to an Agile self-organizing team may look like this:
As soon as agreed Team DNA is documented, printed out and placed in visible area (ideally at the team scrum board and/or also very usefull in retrospective room). This will serve as a point to refer/remind when choosing for right decision/action and will keep team motivated to comply everything they think, decide and do with their core.
But this “artifact” shall not be “curved in stone”. It’s living, since team is also living. So on and on reviewing it, team curves itself, making their brand stronger and more unique, by finding out deeper levels of their own common values, purposes, beliefs and means, achieving them.
The more team does so, the more it finds it’s own distinctive way doing things and becomes more distinguished (“branded”) and valued by managers, stakeholders, POs, etc…
Good teams that value the way they perform and look, care about this and move further finding out more challenging cores, supporting principles and norms.
Besides that it’s a funny collaborative action that contributes to team building.
Brand up your Team, guys 🙂
- “How to Build and Manage Your Brand (in sickness and in health)” ebook
- “Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))” by Lyssa Adkins
- “Branding Governance: A Participatory Approach to the Brand Building Process” by Nicholas Ind and Rune Bjerke.
There are thousands of articles and blogposts about what makes a strong team. Here’s my view on what makes bunch of people being a TEAM and what qualities strong team should have. It is based on observation of all successful (and therefore strong) teams I’ve ever met, experience working with and/or built.
Assumption: it would be necessary to assume that group of people shall have common Goal as key motive and prerequisite to become a TEAM.
1. Self-commitment: this is key important characteristic of a strong team. Commitment to the team, putting the team interests first—and commitment to each individual on the team in helping him or her become everything he or she can.
2. Brand: this is aligned vision, strategy, purpose and values of the team. Team identity, both internally spoken/unspoken and transported inside and outside. These are the things every team member believes in and those that are “reflected” in team norms and via way team perceived from outside, that determines unique team behavior, team distinctiveness. This is team motivator first place and only second place team “label”.
3. Trust and care: mutual trust and value of each other, expressed in giving positiveness to each other regularly and helping out just if someone feels bad for whatever reason. Not being afraid to be/look vulnerable to each other. Standing for each other in hard times! All for one and one for all!
4. Peer-pressure: to be able to move, team should have a mechanism that keeps “wheels rotating” daily. Either a team lead (or a peer-pressure in self-organized teams). That is managerial ability of a team to put constructive pressure and spread sense of urgency and accountability around peers that makes team doing whatever is needed to achieve the Goal.
5. “Short Distance” for continuous improvement: having time together creates a good context where “distance” becomes “shorter”, leading to being more comfortable and open with non-comfortable questions, – key for state known as “storming” (see Tuckman’s stages of group development) that is indefensible for team to change (self-improve). Strong teams embrace change when they need to.
6. Transparently communicating: to understand each other, a team has to be willing to invest the time necessary to share their states, feelings and opinions openly. Without talking and listening to each other on a daily basis, team may fall apart. And it’s very important to happen also informally, not just during status meetings or stand-ups.
7. One Boat in to win-win: there is no my/your work to be done or my/your goals to be met or “I’m done, now it’s your turn while I’ll slack around…”. Responsibility and accountability for everything team does and is shared among team members. Successes and failures, happiness and disappointment, praise and blame is a shared pie to eat.
There are many other specific traits that different teams have, however those mentioned, are common pattern for almost all strong ones, regardless of what they are up to, what business they are working for, etc.
Recently I observed an interesting trap one team fall into. When asked how confident guys feel about hitting the target, they was almost jointly saying they’re absolutely confident, however burndown chart trend told me they won’t make it.
Well, I am absolutely sure that this is what we all want to have – 100% confidence, however here’s the dangerous trap.
We may stay satisfied and oversee problems (or pretend that tomorow the problems will be gone). Or try not to rise them. Or feel uncomfortable rising them. Or think that others will feel uncomfortable if we raise them, etc…
But, they will NOT disappear. Problems usually have tendency to pile up… And when such a team recognizes that, it’s already too late…. and painful.
Kaizen mindset and “Toyota way of Lean Leadership” cultivate culture of “continuous crisis” that requires continuous improvement . Only having daily cultivated feeling of urgency and need, maintains the rhythm of tense and productive environment that reduces risk of facing a FAILURE.
As Toyota management team stated in 2010:
“We realized we need to develop a grater sense of urgency, in our business. Success is good, but without urgency serious weakness sets in, customer focus declines, creative ideas dry up and before you know it, you’re in trouble”.
So here is the trick to recognize: before you know it, you’re in trouble.
But the word and concept has negative tone and may have de-motivating impact on a team. How to make it distinct and positive?
Here is an advice…
Unlike panic or hysteria, urgency is a constructive, ordered and focused sense, therefore it should not de-motivate. Simply because it results in targeted and the only correct decision and action. Deffer commitment + deliver fast, guys!
To illustrate this imagine fighter aircraft pilot that needs to make the only correct decision and act accordingly within 10 seconds left before he may crash. And here is the difference that also proven by multiple real-life cases:
- Panic: an ordinary pilot most likely starts to hit all buttons around (maximizes focus and work-in-progress) or worse, thinks about death (we will fail…), not believing that this happens to him (we will not fail, I do not see problem, it’s not about us/me…);
- Urgency: trained pilot usually freezes for 7 seconds (analysis, defer commitment), makes decision, then within 3 remaining seconds quickly does (focused, fast) the only correct action to stabilize aircraft;
Feel the difference?
A takeaway is simple: stay open-eyed with reality, constantly challenge your confidence, do not fall into trap of satisfied optimism, distinguish among your will and reality, spread urgency around and stay hungry © for constant improvement.