Musings

Musings by Gemba Coaches

Self: All Solutions Begin with You

Written by Amr Elssamadisy

Previously...

In the previous article I made the argument that human dynamics are fundamental to the success of any software development team because they directly affect our individual and group abilities to learn from upsets.

I also shared a story illustrating how a seemingly technical issue could be undermined by the human dynamics context in which it resides. Finally, I shared a set of skills that directly affect our ability to leverage a problem for learning:

Self. By far, the easiest person to change is ourself. This is our greatest point of leverage in solving a problem. Instead of blaming the architect and starting down the road of either working out of obligation or doing my own thing, I should look at myself first. If I take ownership of the problem and see the architect as a team member and not stereotype him as an ivory tower architect I can prevent a vicious cycle.
Clarity. When facing a problem we are often very aware of what we don’t like about it. We are aware of the problem. But are we aware of what we want? I was very aware of what I did not want – I did not want the architect dismissing my ideas or looking down at me. But what did I want? It was clearly more than just presenting my solution. Feeling disrespected and undervalued had a large part in my upset and my actions moving forward.
Asking. Once we are clear on what we want, chances are we haven’t asked for it. The next step is to ask for what we want from others explicitly. I did not ask the architect for respect I just assumed he did not respect or value me and subsequently I lost respect for him.
Agreement. Asking for something does not mean you will get it. Have we reached explicit agreement? If we let problems be, the best we can expect is that they will linger and many times they will fester and grow as they did with the example above.
Calling. Once we have asked and agreed upon something then it is appropriate to call someone on a missed agreement. Many of us are extremely uncomfortable with confrontation and are not skilled in doing so in a constructive manner. This means that many of us either shy away from confronting others or are so uncomfortable with confrontation that when we finally get the courage to do something we do so under great pressure.

In this article I will dig into the details of the first of these human dynamics categories - self - and how it can be applied to our everyday software development situations.

Avoiding Mediocrity in Agile Adoption

Written by Amr Elssamadisy

Have you ever been on a team of aces – the best of the best – and failed? Have you ever been on a team that consisted of average people, found your rhythm and exceeded expectations? Have you ever been on a highly successful agile team and the later used the exact same practices with another group of people, but failed to get the desired results? Why do the same practices work really well with one team and not another? What is behind this?

Interpersonal Debt

Written by Amr Elssamadisy

If you are in the Agile community, you probably know what technical debt is: the accumulation of work to do when you choose to patch/band-aid/short-cut your design and coding to save time and effort now. Technical debt accumulates with interest, every time you choose to take a short-cut you make it a little harder to read, understand, maintain, and modify your code. Eventually, if untreated, technical debt can bring the progress of a team to a standstill. What is the solution? Do the right thing, slow down to speed up, leave code a little better than you found it - always, and refactor mercilessly. Otherwise, pay the consequences.

So, what is interpersonal debt? It is the price we pay in our relationships when we don’t address issues right away. We tell ourselves that we don’t want to hurt the other person, or right now is not the right time because he’s in the middle of something and this will affect his performance, or I don’t want to deal with the headache now - I’ve got more important things to do, and so on and so forth.

Gossip and self-organizing teams

Written by Amr Elssamadisy

Gossip.... Boy! What does that have to do with software development? Well here’s the thing.... Gossip is the spread of words and ideas about a person that they would not appreciate - usually behind their back. This action seriously impedes the ability of team members to work together effectively, and here’s why....

The importance of sincerity in software development

Written by Amr Elssamadisy

Being sincere is something that I learned as a child to be a good thing, just like telling the truth, and sharing with others. Somehow, as I grew up the world stops being a world of black and white and became a world of grays. I have observed that many of us continue to be sincere, and many of us do not and it seems that it is an optional attribute, one that we may use at home but not at work. In many ways I found myself characterizing others as flat characters, inflating their faults or virtues as the context called for. At work, if someone did not agree with me an internal switch would flip and I would start to see their faults and find ways that I was right and they were wrong. I never really felt there was anything wrong with that; it became an adversarial relationship (sometimes for only that specific context) that was for the greater good because the person with the best argument would win over and that was good for the company. Survival of the fittest.

Evocative Documents - An Example Agile Adoption Pattern

Written by Amr Elssamadisy

Here is an example pattern from Agile Adoption Patterns: A Roadmap for Organizational Success

Definition: Documents are created that evoke memories, conversations, and situations that are shared by those who wrote the document. They are more meaningful and representative of a team’s understanding of the system than traditional documents.