After the "Giving and Taking Feedback" training, I wanted to find out more information on giving negative feedback and found some useful links thru google.

I found an interesting 6 step process from one of techrepublic articles

1.       Plan. This helps you develop a framework for providing effective feedback. You should think ahead of time about the behavior that should be highlighted and how you can help the employee improve.

2.       Provide examples. Vague criticism fosters anxiety. Tangible examples are required to highlight the feedback. You do not need to provide dozens of examples. Hopefully, you can make the point with a couple representative observations. If you don't have examples, you cannot provide the feedback.

3.       Motivate. Use motivational techniques in the discussion. The employee is bound to be disappointed by the feedback. Look for opportunities to build the morale of the team member as well, so that he or she will be eager to improve.

4.       Sandwich. The project manager should start the session with positive comments, then get to the feedback and finish with positive, motivating comments. Many people think this is trite and perhaps obvious. However, it is still a valid way to proceed. If you can find some positive things to say, open and close the discussion by mentioning them.

5.       Allow time for feedback. The process needs to be a dialogue between the project manager and the team member. So, seek feedback from the team member and allow him or her to agree, disagree or provide his/her perspective. It is possible that he or she may have mitigating factors that you were not previously aware of.

6.       Set a timeframe for action and follow-up. The project manager should document any action items, circulate them to the team member and ensure that they are completed. Before the meeting is over, the project manager and team member should also agree on a follow-up timeframe to check progress

I totally agree with the sandwich approach. Approach is to start with the Positive feedback first and give negative feedback and then wrap up the session with a positive feedback. In the training, the trainer mentioned an interesting reason why this approach works well and I feel it makes sense.

·         Negative feedback will drain the energy. To make someone listen, start with something supportive. Point out where you agree with him/ her. Do not fake it, but you can always find something positive about another person, particularly if you are not judging.

·         People will listen, when something is interesting to them. Then put the negative feedback in a constructive way and then wrap up the feedback with a positive comment so that the other person will still feel better.

From the link Giving Feedback for Team members http://www.foundationcoalition.org/home/keycomponents/teams/communication7c.html

“State your opinion using “I” statements. “I” statements are always carefully phrased so that you are acknowledging your point of view with no hint of negativity toward the opinion of the recipient. An example of an “I” statement is, “When you interrupt (specific behavior), I feel you do not value my input to the group (expression of your thoughts or feelings), and I would like for you to not interrupt me when I am talking (behavior-change request).” A person is less defensive when you use a specific example and identify your thoughts and feelings (versus saying, “You made me…”). Remember that you are making a behavior-change request of the person—you cannot make the other person change her/his behavior.”

·         If you want to communicate someone point blank and if you feel them that they should go back with the impact, and then do not wrap it up with a positive feedback.

Some Useful Links

o    http://articles.techrepublic.com.com/5100-10878-6102736.html

o    http://www.businessperform.com/html/constructive_feedback.html

o    http://www.coachingnetwork.org.uk/resourcecentre/WhatAreCoachingAndMentoring.htm\

o    http://www.impactfactory.com/gate/coaching_mentoring_skills_training/freegate_1825-1104-1118.html

o    http://www.foundationcoalition.org/home/keycomponents/teams/communication7.html 

A page dedicated to great and memorable projects of the past.

What is a Great Project?

A project that is successful beyond all expectations, a ground breaker, a catalyst for change, and for other projects to follow in its footsteps. It is recognized as a great achievement, or a clear first in achieving a specific objective.

Criteria used for Determining a Great Project

A project has to be discernable as a project with a clear objective upfront, predefined by a degree of planning, and led by a recognized leader (project manager). It has to be brought in a specific time frame, or is just faced with many challenges along the way like the lack of key resources, or physical obstacles.

\Original URL

http://www.lessons-from-history.com/Home%20page%20left%20margin%20offshoot/Greatest%20Project%20Successes.html

I was reading the SPRING.NET Q&A session in the InfoQ Website and found a Simple  explaination for Dependency Injection.

What is Dependency Injection and Why should .NET Developers care about it?

Dependency Injection is actually a very simple concept. When you look at a typical application, you will see there are many dependencies between objects. Presentation layer objects will depend on service layer objects, which will themselves depend on other service objects and data access objects, etc. Within a running application there are many interdependent objects that are "wired" together.

The naïve way to obtain a dependency is to create it directly by calling its constructor. This works, but it has a number of problems:

·         Classes become difficult to test in isolation,

·         It is impossible to change which dependent class to use without modifying the code that created it, etc.

Most of these problems can be solved by using some kind of a configurable Factory, Service Locator or Registry to create or look up an object. This approach, which we could call Dependency Lookup, can work very well if implemented correctly, but it introduces a dependency on the Factory, Service Locator or Registry itself, which is often not desirable. It also requires more work than Dependency Injection.

On the other hand, Dependency Injection implies that an object's dependencies will be "injected" by external means. There is no need for an object to look up anything - it simply declares private fields for its dependencies and allows for them to be provided externally, either via a constructor argument or via a property setter. This makes objects very clean and reusable, and if dependencies are declared in terms of interfaces instead of specific classes, it also makes them very easy to unit test.

If you think about it, there is nothing new about Dependency Injection per se. Whenever you set a Connection property of an IDbCommand instance, or a Menu property of a Form instance, or when you pass a Socket instance as an argument to a NetworkStream constructor, you are manually injecting dependencies. I could find similar examples in older technologies as well, such as VB6 or COM.

However, what made Dependency Injection so popular in the recent years is the rise of lightweight containers such as Spring, Pico and HiveMind in Java, and Spring.NET, Castle, and more recently Microsoft's ObjectBuilder in .NET. These containers allow you to configure object-wiring rules within your application and based on those rules they will create and wire your application's objects together, providing you with automatic dependency injection. The ways in which different containers allow you to specify object-wiring rules are different, but the ultimate goal and the end result are usually the same.

There are other benefits which containers have to offer as well. Because they know about all the objects they are managing, it is very easy to manage objects in a running application. I'm not sure about other containers, but Spring and Spring.NET also offer hooks that allow you to execute custom logic in different states of an object's lifecycle, which is very useful at times.

Original URL:

http://www.infoq.com/articles/SpringDotNET-QnA

Fred George has a very interesting post in his blog “You have the wrong team”.

You have a wrong team because:

• You are missing the experience you need in some key areas, and
• The team members don't necessarily work well together.

He explains how agile helps in this situation. Collocation and pairing helps in when somebody doesn’t have the expertise and it explains how knowledge transfer can be quite rapid in this environment.

If somebody still have difficulty working together, your being in the room provides insights to the solution. Is it a matter of tone (challenging, dismissive, personal rather than business)? Then coach on interaction style. Is it disagreement on technical matters? Ensure swift resolution before it becomes personal.

He talks about Net-Negative Producing Programmers (NNPP) and I could not agree to more than what he has mentioned.

A single individual typically can negatively impact other team members numbering in double digits! So indeed, one bad apple can spoil the whole bunch.

There are several ways to identify such individuals:

• Observe. Being in the room, you can see the behavior. Even more important, you can see the impact on overall team. The situation can be corrected by coaching, or ultimately, removal.
• Ask the team. The team knows who is acting incorrectly. Borrow a lesson from Survivor, and let the team vote someone off the island.
• Who gets picked last? If pairing is practiced, who is the person no one wants to pair with?

If you fail as a project manager to act quickly on identified NNPP, morale issues will quickly ensue. Your inaction, in particular, will be glaringly obvious to the team. Your leadership, dedication, and even competence will come under question.

Once more for emphasis: Failure to address an NNPP problem will rapidly destroy team productivity.

The next thing he discusses why does staffing need to be adjusted throughout a project? It is for several reasons beyond staff quitting and needing to be replaced:

• The needs of the project change throughout the project. DB tuning will be important at some stage, but not others. Knowledge of systems with which the project much integrates will be needed at some time. The general load of analysis, development, and testing will drift during the project.
• Team members will grow during the project, particularly on projects lasting more than six months. Exploiting this growth is part of good team management.
• An inbred team will cease innovating. Studies of innovation reveal a significant drop in innovation in a team that has been together for as little as six months. New blood is needed, even if only to challenge the patterns of current thinking.

As a project manager, you must constantly be alert to tweaking the team. Bring in a specialist when the need arises; exploit collocation and pair programming to harvest the knowledge and release the specialist. Perhaps that resource you really needed was not available at the start of the project. Bring them on board when they are available.

Application development is chaos; react or face corresponding chaos in your team.

Worth Reading it

http://processpeoplepods.blogspot.com/2007/08/you-have-wrong-team.html 

How do you build a great successful team? Here are the 7 critical steps.

·         Find the right players/people. Talent helps, of course, because you can’t make a donkey win the Kentucky Derby.

·        Give each player/person a valued role. Everybody is important. In acting, the supporting actor is just as important as the lead actor. In Baseball, the pitcher may get all the glory, but someone has to play right field to make a team of 9. Heck, even I played right field!

·         Create a unique identity to the team. Give your team a nickname, or better yet, let them decide one. It will help in their bonding and give them something to be proud of. Mind you, your front line of football linebackers may call themselves the “Crazy Dogs”, but it worked. Sometimes that mental edge is all the confidence they’ll need.

·         Commit to winning/excellence. The people on your team must have the drive to succeed. In sports, winning is just the end result of a numerical score. You can win a game statistically, but really lose the game in reality and execution. Thus I prefer to use the term excellence. If you’re a janitor, then you set out to be the best janitor out there.

·         Give them a vision. Easy one… Super Bowl? Stanley Cup? Going IPO for a start-up? Releasing version 1.0 for your software development team? At work, if you have someone on your team who is there just for the money, punching in at 9 am and punching out a 5 pm, that person isn’t going to help your team succeed.

·         Play/work with passion. Every person on your team must like love what they are doing. And I mean love. Passion.

·         Get out of the way. Hey Teacher, leave the kids alone! Stay off the field and let them execute! Of course, you wouldn’t want to get your nice Armani suit sweaty, would you?

Original URL:

http://speedendurance.com/2007/05/07/how-to-build-a-winning-team/