Interesting Post which talks about the qualities that differentiate good leaders.

"Teams of all natures - agile software development or otherwise - need inspirational leadership to perform their best.That leadership may, or may not, come from the organisation's appointed leaders. But all teams need it, nevertheless."

1. Strong communication – storytelling and listening
2. Passion for learning and intense curiosity
3. Focus on developing people
4. Having fun and very energized
5. Strong self-belief, coupled with humanity and humility
6. Committed to making a significant difference
7. Clarity of vision and ability to share it with others
8. Dogged determination and often relentlessness
9. Strong focus on priorities
10. Not afraid to show some vulnerability
11. Regular use of reflective periods to think and learn
12. Real passion and pride in what they do
13. Confidence and trust in their teams, giving them real empowerment
14. Respect for all (team members, temps, customers, suppliers and directors alike)
15. Clear standards of ethics and integrity; openness and honesty
16. Ability to drive, inspire and embrace change and continuous improvement
17. Positive attitude at all times and an innate ability to be diplomatic in any circumstances
18. Lateral thinking and ability to find innovative ideas and solutions to problems
19. Ability to inspire and motivate others
20. Willingness to take (calculated) risks

Original URL:

http://kw-agiledevelopment.blogspot.com/2007/07/20-qualities-of-agile-leader.html

Sendhil has shared his experience in implementing WCF.

Quote

WCF Woes

We started using WCF in our project recently.
The vision (read architecture) was good when people (the likes of Don Box) were speaking about WCF.
However after using it and getting my hands dirty, I really doubt if the implementation really lives up the expectation set by the vision.
There has been a quite a few issues with WCF, but the one I ran into yesterday was proof that Microsoft has compromised on people aspects (atleast at the developer level). The vision still seems to be good. People like myself are getting into Microsoft development teams (Core teams, I believe WCF is one of the core elements of the Framework). This is what I saw yesterday.
I wanted to write my own ServiceHost so as to apply the WCF configuration myself. I was rather wild when I learned that configSource attribute is not supported on any of the WCF configuration sections. And if I really had to load the configuration from an external source I had to reinvent the whole WCF configuration approach myself. Source: http://blogs.msdn.com/drnick/archive/2006/12/04/overriding-the-default-configuration-file.aspx. Well that's not what I wanted to blog about.
The ServiceHost class contructor (or one of it's base class's) call ApplyConfiguration which happens to be a virtual method. Oops, constructors calling virtual methods, I thought that was not encouraged. I decided to google on this and found that I was right. The good folks from Microsoft have written about this here and here. In fact they found it reasonable to include it as a FxCop rule as said here. But only for folks outside of Microsoft may be. They went ahead and violated their own rule. The irony is that it slipped out of the design, design reviews, development, development reviews and testing. ServiceHost happens to be one of the core classes of WCF.
The bottomline is that Microsoft is compromising on the process (the fact that this one slipped thru all the reviews and testing) for getting stuff out early, as well as people. Not so good news.

An interesting post on Agile Team Dynamics.

"Most of the challenges some of our projects teams face are generally not technical — they tend to be business (or political) issues; a new team getting to know one another and evolving their style as a team; or, the team getting to grips with the business domain they are operating in. This is mainly the case when the team is made up of our staff, client mgt, client developers, and other consultants. In these situations, the team dynamics seem to be the most common thing we have to help teams out with. Politics are another (but never-ending) story."

Some Team Rules from the post...

• Emails should be BANNED for inter-team communication. If you have a question, issues, problem with someone on the team or the way things are being done, SPEAK to the person or the team.
• Decisions made by the team UNANIMOUSLY should be communicated to the entire team - wikis, etc - emails ARE good for this. Examples, include decisions regarding designs, clarifications of ambiguities, development process, etc.
• The entire team must UPDATE ALL TASKS in the Sprint Backlog before they go home at night. No exceptions.
• The whole team is accountable for all tasks and estimates.
• If you don’t agree with something that a team member says or does, or if someone puts you on the defensive, SPEAK UP and stick up for yourself and let them know how you feel (really feel - “Honesty Is The Best Policy”). If the team is not making unanimous decisions it is not working together as a whole.
• If the team believes it has hit a barrier or estimates suddenly jump, such that THE TEAM thinks it will not deliver on time, then it is time to raise it to the Product Owner (for potential de-scoping). If the team still honestly believes that it can make the deadline, then that's OK – it just needs to agree collectively to get through the workload accordingly.
• If(or when!) there are issues, problems, etc it is very important that the whole team understand the issues clearly and the entire team understand the solution. This way a) you all know what happened without ambiguity and b) the team knows how to deal with it going forward, and c) reduces dependencies on individuals.
• There is no such thing as ‘lost time’ – either a task was not completed due to impediments or estimates are recalculated due to needing more time, or you put a task on hold and pick up a new one.
• There is only one PRIMARY metric – deliver or not deliver ….

Original URL:

http://newyorkscot.wordpress.com/2006/01/27/agile-team-dynamics/

We (I and Sendhil) conducted a 5 day Agile Software Development Session in our Organization last week. As part of the Agile design session, Sendhil had a slide "Empty your cup". Unless someone agrees to iterative design and development, Agile design is a very controversial topic and to make sure people are ready to listen, Sendhil talked about the Zen story.

Story:  "You cannot learn anything if you already feel that you know."

There was an American professor who had made a lifetime’s study of the Japanese tea ceremony. He was the western expert. He heard there was an old man living in Japan who was a master of the tea ceremony. So he made a special trip to Japan to see him. He found the master living in a small house on the outskirts of Tokyo and they sat down to have tea together. The professor immediately started talking about the tea ceremony, his study, all he knew about it and how he was looking forward to sharing his learning with the old man. The old man said nothing, but started to pour tea into the professor’s cup.

While the professor talked, the old man continued to pour the tea, the cup filled and the old man kept pouring. The tea split down the sides of the cup in a stream onto the floor, yet the old man did not stop. “Stop!” said the professor. “You are crazy. You can’t fit any more tea in that cup. It’s full.”

“I was just practicing,” replied the old man, “for the task of attempting to pass learning to a mind that is already full.”

Original URL:

http://www.lifepositive.com/Mind/Transformation/c_120_Stories_to_transform_your_life42004.asp

http://www.rider.edu/~suler/zenstory/emptycup.html