Developer notes

Team trust is something we need but something we just don´t build.

Key points to consider to build professional trust (from Esther Derby)

Address Issues Directly

Building trust depends on team members having the courage to speak directly to the person “bugging them”, rather than going through a manager to communicate these concernes. This can be done also through a feedback (or “feelbad” as a friend says )

Share Relevant Information

Speak your mind. If you don´t agree, say it! Don´t wait until the disuccion has over and then came back saying you disagree. Also consider doing it in a constructive way.

Follow Through on Commitments or Give Early Notice When You Can’t.

Just do your best to be honest with your progress and be proactive when things are not going as planned for you. This is related to point #4.

Say No When You Mean No.

I guess in my case, I almost say always yes to everything related to work and then I have to say No because I just can´t with all the tasks assigned to me.

So, you don´t have to say “yes” to every request in order to look like a “team player”. Saying Yes to everything can lead others to doubt your word. If you can´t say No, your Yes won´t mean anything.

Admit you don´t have all the answers.

Show What You Know and What You Don´t Know

Share the information you have, the things you know, but also be aware and open about the things that you don´t know.

I read this article and I would like to share:

Ivan Jacobson, author of the original work on Use Cases said in the Software Education SDC conference in Melbourne, Australia that the Agile development needs to “Get Smart”.

He stated that the information technology industry is very fashion conscious, having a tendency to latch onto silver bullets, and listed the following examples:

• Fifteen years ago it was all about OO
• Ten years ago it was about components, UML, Unified Process
• Five years ago it was about RUP and CMMi
• Two years ago it was about XP
• Today it is about Scrum

All have good elements – but none is what we need, what we need to do is to Work Smarter. He says “Being Smart is an evolution of being Agile”:

• Agile means being flexible and adaptable
• Agile provides simple/lightweight starting points
• Being Smart is knowing when to go beyond agile
• Knowing when to follow the rules and when to break them
• Knowing when to be consistent and when to change
• Knowing when to grow and when to shrink

Smart is Agile++

• Unsmart with People – viewing processes and tools as more important than people
• Smart with People – recognizing and understanding that software is built by people, not with processes and tools!

• Unsmart with Projects – Trying to follow a waterfall approach
• Smart with Projects – Build a “skinny system” to demonstrate that you have eliminated all the critical risks, then add more capabilities on top of that skinny system as needed.

• Unsmart with Process – continuously latching on to the latest fad, and trying to change everything you do in response to the newest rule book
• Smart with Process – Don’t throw out the baby with the bathwater:
  1. Start with your existing way of working
  2. Find the pain points
  3. Change one practice at a time

The key element to becoming Smart is to focus on the people, as Jacobson says, and “it all comes down to you”.