Archive for the Category ◊ Organization Culture ◊

Author:
Saturday, March 23rd, 2013

Writing email is a part of our day to day activities. If you are work at office you write email to your colleagues,clients. There are few rules of email etiquette help us communicate better via email.

1) Use appropriate Subject Lines

emailsubject

 

 

 

 

Do not keep the subject line blank. Keep the subject line simple and more appropriate to the content of the email. The recipient will decide to read the email reading the subject line of the email.

2) Always use “Reply to All”

reply to all

 

 

 

 

 

 

3) Be simple and to the Point.

Email is harder to read then the printed messages. The email that goes on and on is less likely to be read . If the email is just 2 or 3 sentences then may be you should just pick up the phone and talk to the person.

4) Use proper grammar, punctuation and spelling.

Poorly written email with bad grammar reflects on you and your company.Almost every email tool has speller and grammar checker program. So use it.

5) The 24 Hour Rule

Always reply to your email within 24 hours . This tells your customer that you are focused on prompt service .

6) Do not write in All Caps.

capsimages

 

 

 

 

 

Writing in all caps makes it difficult to read the email.Its also sends another unintended message that you are shouting .

 

7) Read you email before sending it .

Taking your time and read your email before sending it .

8) Use disclaimer at the bottom of the email .

The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission  dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

Most of you might think that this will take more space in email . But these words will save a lot of money for your company whenever there are any legal issues.

 

Author:
Tuesday, January 22nd, 2013

Yes, that’s right. Agile teams don’t need software programmers, they need software developers. I don’t mean this as some English vocabulary usage. I think the key difference is, if you ask a programmer to build some code, you will get code. If that programmer is good, you might get good, reasonably commented and reasonably efficient code which works.

If you ask a software developer to build some code, you will first get questions :) before you get a solution.

  • How does it fit in the business process? Are the requirements thought out?
  • Are you sure you understand what it will cost?
  • Who will support it? What about diagnostics and instrumentation?
  • What kind of documentation will it need?
  • How might it interact with other code?
  • What platform will it run on. Are the scalability issues?
  • How might it impact future development? How might it be enhanced in the future?

Another key difference is, programmers focus on languages, software developers focus on language characteristics. A programmer might see himself/herself as a Java programmer, C# programmer or a Ruby programmer. But a developer focuses on language characteristics such as strong or loosely typed? Object oriented or functional? Interpreted or compiled? Etc. This allows developers to quickly adapt and pick up new languages and technologies.

So, the key mantra for agile teams is to deliver high business value software with high quality. This cannot happen with programmers whose focus is just to code and ignore everything else.

Code is not always ‘THE’ solution but its ‘a’ solution.

Credit: This blog is inspired by a talk from Dan Appleman

Author:
Tuesday, August 21st, 2012

One of the biggest challenges for agile teams or for that matter lot of organizations is fear of conflict. This fear of conflict is a major reason why organizations fail to call right shots. In a survey conducted among US and Europe executives, 85% have acknowledged that they had issues/concerns at work that they were afraid to raise. They were afraid of conflict that would provoke, afraid that it would lead to arguments that they won’t know how to manage and loose.

Arguments are necessary; disagreements are required to drive creative solutions to problems. Well, easier said than done. How can we have these conversations more easily and more often? Organizations culture should reflect and encourage the attitude of questing, willingness to start an argument. Imagine in an agile team, if individuals are hesitant to prove others wrong, it will ultimately do bad to the team.

Developing “Prove me wrong” attitude doesn’t mean that team/organization loses team sprint. In fact, the opposite would happen; there is even more team collaboration, very little room for wrong decisions or judgments. The reason why Phd theses have such a high quality is because they have to pass “Prove me wrong” phase.

It is not enough to make things transparent and open, but as I mentioned above, the discussions and arguments around it is what makes it effective.

Openness isn’t the end; it’s the beginning.

Credit: This blog is inspired by the TED talk give by Margaret Heffernan – Dare to disagree