House of Cards: System Thinking issue around agile teams

I saw a bunch of things and had several experiences with agile and non-agile teams. This issue is something very usual for new teams or for people that are new with agile culture.  I'm calling this: House of Cards Anti-Pattern or metaphor is you prefer.

What you thing about building a house of cards in the top of sand? Sounds like a good idea? We'll that happens a lot - for several reasons. 

This metaphor is about people making solutions and decisions in sense of Design and Architecture with zero or poor idea about what the hack they are doing.



What i`m doing?

First of all people don't know what they don't know in this case. 

So you need a experienced coach to spot the team dysfunction and coach the team and the individuals in order to fix this issue. 

I build a house and now it fails down - why? That's the thing about the house of cards until they realize the whole house is at the ground. 

Why people don't realize this? Because design and architecture are trick and they bit you hard only when is too late, so people need better approaches to avoid get trapped by this. 

I will not show any issue!

That's the main property of the house of cards it's so fragile. What are the real impact of bad design / architecture decisions could lead to: 

* Coupling 
* Performance issues 
* Scalability Issues
* Re-work
* Side effects
* Break other people work 
* Delay business stories 
* Bugs for users 
* Poor User Experience

Some people could see and agree about the problem that's great - often is people just stay too much in silence... Could be something else...

Let`s make the manager or coach happy?

One of the classical dysfunctions is having people at the confort zone - this could be by the lack of trust it by the sense of invulnerability - lack of saying: I have no problems. 

Some people will try to fly out of the radar and avoid conflict - so they will be 100% am Complient about what the manager or the coach ask - beware of that - this attitudes need to be challenged otherwise this people might not grow - the team night not grow and the problems will be there sleeping just waiting to appear again :-)

When people do that they are fooling themselves, not the coach. Avoidance does not fix problems - facing problems fix problems.

Always Learning, Always Improving - One Step at the Time

That's the Kaizen / Lean way. We will apply Continuous Improvement to fix this problem systematically. We will attack the problem as a whole and FIX the whole system - how? 

* The Coach will explain the problem to the team
* The Coach will let the team think a bit about the issue
* If some people ask questions - the coach will clarify and be more specific otherwise as a coach you let the people suffer a little bit more - sometimes the failures teach us - don't save people all the time - it's not good at all. 
* You will share this experiences at the retrospectives and always give examples - always show what is not visible - make it visible to the whole team. 
* If you keep practice, day by day with your team you can fix it. 

Let's make a simple test - I'm sure you got it - or maybe not... :-) 

 Could you be a nuclear Chemistry? ok fine....


If people say yes ok. Don't ask any kind of question - this mean this is Bullshit. Why? Lets say as a coach I will give you some feedback: you need become a better Nuclear Chemistry. What's the problem if people just say ok and dont ask questions? 

1. Nothing will change 
2. They don't know the implications 
3. They don't what do differently
4. They don't know what change and what avoid or what keep doing.
5. What are the new attitudes required? What need be learned? What need be unlearned?
6. What i should stop doing? What are the new values and mindsets? What are the new beliefs? 

Now I'd you keep piling up this things - voila you have the house if cards. For a good coach is easy to know when people don't know a.k.a BULLSHIT.



Questions and more questions?


To be a good coach you need to have an arsenal of questions - simple questions that early cloud break  90% of developers: 

1. What is this? 
2. How it works? 
3. Why are you doing it at all? 
4. Do the customer really need this? 
5. What are the other options? 
6. Why this is better or worst? 
7. Could you compare X with Y ?
8. What's the side effects - impacts? 
9. It's this relevant? Why? 
10. Do you feel confident about it? Why? 

So that's the basics - coach could use this questions to assess the quality of work and the team can use this to improve his capability to make better decisions and be more consistent avoid to build a house of cards. 

Do not take anything for granted otherwise you might be build a house of cards on the top of the sand - try to make sure you have some background. 

Cheers, 
Diego Pacheco 

Popular posts from this blog

Telemetry and Microservices part2

Installing and Running ntop 2 on Amazon Linux OS

Fun with Apache Kafka