| Prakash's profilePrakash's - Online Repos...PhotosBlogLists | Help |
|
Prakash's - Online RepositoryAgile Project Management, Scrum/XP, Software Architecture, Design and Managing People June 18 Notes from the Book: Eat That Frog. 21 Great Ways to Stop Procrastinating and Get More Done in Less Time.I am currently reading Brian Tracy's Eat That Frog. 21 Great Ways to Stop Procrastinating and Get More Done in Less Time.
Notes from the Book
If you are like most people today, you are overwhelmed with too much to do and too little time. As you struggle to get caught up, new tasks and responsibilities just keep rolling in, like the tides. Because of this, you will never be able to do everything you have to do. You will never be caught up. You will always be behind in some of your tasks and responsibilities, and probably in many of them.
For this reason, and perhaps more than ever before, your ability to select your most important task at each moment, and then to get started on that task and to get it done both quickly and well, will probably have more of an impact on your success than any other quality or skill you can develop.
An average person who develops the habit of setting clear priorities and getting important tasks completed quickly will run circles around a genius who talks a lot and makes wonderful plans but who gets very little done. It has been said for many years that if the first thing you do each morning is to eat a live frog, you can go through the day with the satisfaction of knowing that that is probably the worst thing that is going to happen to you all day long.
Your "frog" is your biggest, most important task, the one you are most likely to procrastinate on if you don't do something about it. It is also the one task that can have the greatest positive impact on your life and results at the moment. It is also been said that, "If you have to eat two frogs, eat the ugliest one first."
This is another way of saying that, if you have two important tasks before you, start with the biggest, hardest and most important task first. Discipline yourself to begin immediately and then to persist until the task is complete before you go on to something else. Think of it as a “test.” Treat it like a personal challenge. Resist the temptation to start with the easier task. Continually remind yourself that one of the most important decisions you make each day is your choice of what you will do immediately and what you will do later, if you do it at all.
There is one final observation. "If you have to eat a live frog, it doesn't pay to sit and look at it for very long."
The key to reaching high levels of performance and productivity is for you to develop the lifelong habit of tackling your major task first thing each morning. You must develop the routine of "Eating your frog" before you do anything else, and without taking too much time to think about it. If you read the above, Its all about Common Sense. :) I also found an interesting post named "You're Only as Busy as You Want Yourself to Be" on similar lines.
Happy Reading !!!
May 13 Three Dimensions of High PerformanceI found this interesting blog post in Leading Answers blog.
To be truly effective you need ability and passion.
Some people use the formula: ü Performance = Ability * Passion
However, you also need time to dedicate to the work at hand; and so Availability factors in also.
In the volunteer world we often say we are looking for 3 key attributes:
ü Talent (Ability in some useful skill) ü Passion (motivation to do it) ü Availability (time to commit to it)
In other words you need to have skills, enthusiasm, and time to dedicate to something in order to be effective. (This also applies to paid work too, but because we get paid for things it is easy to mix-up motivation with payment and forget about considering if we are passionate/motivated about the work.)
Original URL http://leadinganswers.typepad.com/leading_answers/2008/10/three-dimensions-of-high-performance.html
May 06 BlogmarksMarch 31 Ego States in Transactional AnalysisTransactional Analysis is the method for studying interactions between individuals. In addition to the analysis of the interactions between individuals, Transactional Analysis also involves the identification of the ego states behind each and every transaction.
Berne defined an ego state as "a consistent pattern of feeling and experience directly related to a corresponding consistent pattern of behavior."
At any given time, a person experiences and manifests their personality through a mixture of behaviors, thoughts and feelings.
Typically, according to Transactional Analysis, there are three ego-states that people consistently use:
Parent ("exteropsyche"): A taught concept of life. Parent is a state in which people behave, feel, and think in response to an unconscious mimicking of how their parents (or other parental figures) acted, or how they interpreted their parent's actions. For example, a person may shout at someone out of frustration because they learned from an influential figure in childhood the lesson that this seemed to be a way of relating that worked.
Adult ("neopsyche"): A thought concept of life. Adult is a state of the ego which is most like a computer processing information and making predictions absent of major emotions that cloud its operation. Learning to strengthen the Adult is a goal of Transactional Analysis. While a person is in the Adult ego state, he/she is directed towards an objective appraisal of reality.
Child ("archaeopsyche"): A Felt Concept of life. Child is a state in which people behave, feel and think similarly to how they did in childhood. For example, a person who receives a poor evaluation at work may respond by looking at the floor, and crying or pouting, as they used to when scolded as a child. Conversely, a person who receives a good evaluation may respond with a broad smile and a joyful gesture of thanks. The Child is the source of emotions, creation, recreation, spontaneity and intimacy.
Summary: Parent - taught concept Child - felt concept Adult - learned concept
http://www.ericberne.com/transactional_analysis_description.htm http://transaction-analysis.blogspot.com/
March 30 The Power of StrokesThis is the second part of my notes from the book Born to Win: Transactional Analysis with Gestalt Experiments
Human hunger for Strokes
Stroking is defined as any act of recognition, verbal or nonverbal, for another. The term comes from the physical contact which is essential to the survival of the infant child.
Stroking Hunger Beginning from childhood and throughout their lives people needs affection, recognition and praise.
Infants will not grow normally without the touch of others. This need is usually met in the everyday intimate transactions of diapering, feeding, burping, powdering, fondling and caressing that nurturing parents give their babies. Something about being touched simulates an infant’s chemistry for mental and physical growth. Infants, who are neglected, ignored or for any reason do not experience enough touch, suffer mental and physical deterioration event to the point of death.
As a child grows older, the early primary hunger for physical touch is modified and becomes recognition hunger. A Smile, a nod, a frown, a gesture eventually replace some touch strokes. Like touch, these forms of recognition whether positive or negative, simulate the brain of the one receiving them…
Strokes may be positive, negative or mixed.
Discounting If a parent discounts an infant’s feelings and needs, healthy development is thwarted. A discount is either the lack of attention or negative attention that hurts emotionally or physically.
A Person, who is ignored, tested, diminished, humiliated, physically degraded, laughed at, called names, or ridiculed is in some way being treated as insignificant. The individual is being discounted. Discounts always carry on ulterior put-down.
Being discounted is always painful. It leads to unhappy human relationships or feeds into destructive or going nowhere scripts.
Ignoring and isolating people are well-known forms of punishment. It deprives persons of even minimal stroking and leads to intellectual, emotional and physical deterioration.
If a discount is delivered through negative stroking, the not-OK message is sent either openly or by implication.
Giving and Receiving Strokes
March 29 What is Transactional Analysis?
Transactional analysis is concerned with four kinds of analysis
Transactional Analysis can help in
Reference Born to win: Transactional analysis with Gestalt experiments http://en.wikipedia.org/wiki/Transactional_analysis
March 22 What makes us tick?From the Agile in Action Blog. http://www.think-box.co.uk/blog/2009/03/what-makes-us-tick.html March 08 You R Who You HireGood leaders (managers) hire people smarter than themselves and don’t feel threatened by people who are better at given tasks. The people you hire tell more about who you are than just your leadership style; they are a reflection of your MAP (mindset, attitude, philosophy) and your confidence. Originial URL: http://www.leadershipturn.com/you-r-who-you-hire/ March 01 What do i need to understand about Emotional Intelligence as a Manager?Improving Self-Knowledge and awareness of others' reactions is the foundation of most leadership and management development programmes. Managers and Leaders must see themselves as others see them to be effective influencers to make work happen (the right work and right first time, on time).
From the Book: Emotional Intelligence by Jill Dann February 22 Sunday BlogmarksTop 10 Activities of the Product Owner The Product Owner differs from that of the traditional Product Manager role in many ways. Additionally, the role the Agile PM plays may vary depending on the environment and situation at hand, but for certain there are key activities the Agile PM must perform. http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner
Prioritizing Requirements – 3 Techniques: Prioritize based upon the value that a set of features will bring to the business. When we’re writing the specs for multi-customer software, the business whose value we prioritize is ours. This abstraction can be harder to address. But a given capability will be expected to have an impact on our ability to sell the software (or raise the price of the software). And it will come with an inherent cost. Leverage strategic marketing expertise to pick the right capabilities (more importantly - solve the right problems), and properly value them. By changing the customer from them to us, we can apply the same principals for value-based prioritization. http://tynerblain.com/blog/2006/01/18/prioritizing-requirements-three-techniques/
Essential Vs Non-Essential Features: When you build an application always look out for the non-essential features. Make sure they don’t make it into your v1.0. They slow down your release, they dilute your focus, they require resources that pull you away from perfecting the core of your application, and they open the door to more bugs at launch. http://37signals.com/svn/archives2/essential_vs_nonessential.php
Retrospectives go beyond the Report: In short, retrospectives are agents for change, yet ultimately it comes down to the empowered team to make sure the changes really happen. Managers should give teams responsibility and, with that, the decision making authority, to help them make the changes they need to. http://www.thekua.com/atwork/2008/05/retrospectives-go-beyond-the-report/
How to Handle Multiple Customers: Balancing work for multiple customers is a tough problem. You will have optimal results by optimizing resource allocation in such a way that all customers are just a little bit happy. And it is true that you should minimize the amount of task-switching between projects. If you can consolidate all maintenance work in one week per month, instead of one day per week, then do it! Likewise, aftercare in 2, 5 days of 8 hours would be much better than 10 days of 2 hours. I’m sure you get the picture. http://www.noop.nl/2009/01/how-to-handle-multiple-customers.html
Target Cost Contracts: 1. Share risk fairly between Customer and Supplier 2. Give the Supplier the peace of mind of being protected from significant cost overruns 3. Offer enough flexibility to get the best out of an agile development process 4. Align goals by giving both parties an incentive to minimize scope Hitler's nightly build failsA Very Funny Video: Hitler's nightly build fails
Original URL:
February 21 Dysfunctional Attitudes: Processes are more important than people.I landed in this interesting post while googling today and thought of blogmarking. This post was written taking an IT Scenario as example. But as mentioned in this post, this also applies to development projects and teams.
Summary from the Post Implementation of processes based on frameworks and methodologies (ITIL, CMM) help standardize the way corporate IT carries out its functions. This, in most cases, is a good thing. Yet, processes aren’t the be all and end all of IT.
This holds not just for operational IT (like the service desk), but also for development work (i.e. projects). Trouble is, processes trump people more often than not. When that happens, things aren’t working the way they should- processes are intended to help people, not to hinder them. This is something folks who work in corporate IT would do well to keep in mind.
All too often, IT management thinks of processes as a panacea for all IT ills. The way I look at it is a little different: processes are fine and good, and even necessary; but the people who are served by IT must come first. If that means making the occasional exception to a mandated process, then so be it.
Original URL: http://eight2late.wordpress.com/2009/02/15/people-are-more-important-than-processes/
On the role of Processes in Project Management http://eight2late.wordpress.com/2008/09/06/on-the-role-of-processes-in-project-management/ February 16 The product owner and the product-shaped holeWhat the product owner needs to worry about isn’t in the product backlog?
In this post, Jeff Patton has the described the problem (most difficult roles in an agile process is the product owner or agile customer) and provided a sketch on what he sees as a mental model and some practices that product owners can use to begin to fill that skills vacuum.
Blogmarking it
December 19 Retrospectives - What is it and how to get started?In his famous book "Project Retrospectives", Norman Kerth has defined retrospective as an opportunity for the participants to learn how to improve. The focus is on learning—not fault-finding. Retrospective rituals are more than a review of the past. They also provide a chance to look forward, to plot the next project, and to plan explicitly what will be approached differently next time
In their book "Agile Retrospectives, Making Good Teams great", Esther Derby and Diana Larsen has defined Retrospective as "It's a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and generate action. Retrospectives go beyond checklist project audits or perfunctory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so."
What a Retrospective isn't? It is not a postmortem. Why we call it as a retrospective and do not call it as a Post mortem? Post Mortem is something, which is done on something dead. We are working on projects which are live. This has to be done at regular intervals. It is not a Ceremony Do not do it for the sake of doing it. Identify techniques which can make it fun, so that everyone participates and the team identifies areas of improvement. It is not a secret Its not a meeting where you can point fingers/blame others. The purpose is to identify where the team is lacking and how we can improve as a team. The meeting can include all kinds of stakeholders (provided understands the purpose of the meeting) It is not session to Whine. It is definitely not a place to Crib. Emphasis is on being constructive. It is not a place to blame others Emphasis is on "I/We". Its not a meeting where you blast your customer side representative or the customer takes it as an opportunity to blast the team.
How to run/facilitate retrospectives?
Before the Meeting Setup a Meeting with Team members and all the stakeholders. Its very important that the stakeholders also attend the meeting. Have a meeting room setup for the discussion. If your customers are in a different location, setup WebEx/LiveMeeting, Conference (Video Conferencing will be really great. Depends on the availability and Budget :))
Identify a template where you will capture the events and share it with all stakeholders (It will really help if your customers are in a different place).
In his book "Agile Project Management with Scrum", Ken Schwaber says the meeting should be time boxed to 3 hours. My interpretation to it is defined based on 30 Days iteration.
In my experience, for a 2 weeks sprint with a team size of 10, the retrospective could take anywhere between 1.5 to 2.5 hours.
Get some Snacks/Cookies for the team. Because my customers are in a different time zone, we will do it in our evening/their morning hours. If there is a need to stay late, cookies/snacks will help the team to be energized.
During the Meeting Step 1: Start with Norm Kerth's Prime Directive for Retrospective. In our meetings, the whole team (here team includes the customer side architect and other stakeholders) reading the Prime Directive loudly once.
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand"
Step 2: Define the Ground Rules: Our Team ground rules are something like this 1. Do not finger point or blame others 2. We all are responsible for the success or failure of this 3. Try to attack the problem and not the person 4. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgment used to embarrass.
Step 3: Decide the facilitator.
Step 4: Appreciations: Team members to appreciate/recognize other team members who have helped them in 2 weeks. It helps in bonding. Make sure, the appreciations are captured and shared with stakeholders. Team members will definitely feel happy to see their name in that. May be it’s a collection of "Whale done" or good things everyone has noticed for 2 weeks.
Step 5: Once you are done with appreciations, move to the actual questions section.
Answer the 3 questions. Purpose is to inspect how things are and adapt ourselves accordingly.
1. What worked well? 2. What needs to be improved? 3. What should we do differently?
You can change the format. We call it as "Mad (Crazy), Sad (Needs improvement) and Glad (Did Well)".
Step 6: Identify Lessons Learnt. We try to gather this from the GLAD, SAD and MAD sections.
Step 7: Identify Top 1 or 2 Actions items which the team is going to work in the next 2 weeks. Identify the Theme for the Area of improvement and the Action Superstars for the Theme.
After the Meeting Share the Retrospective meeting notes with all the stakeholders. Share the progress the team has made with the action items identified in the previous sprint with all the stakeholders. Sharing the Retrospective notes could be in email, wiki, posters or any other format. Our team sends the report in email and keeps the copy in SVN. The Scrum Master will follow up on the Action Items Identified.
Challenges 1. Making the team participate. 2. Everyone focusing on "I/We" 3. Continuously identify area of improvements and working on them 4. Creating a Learning Organization/Environment. Making it as a part of the organization culture.
Summary The purpose is to create a learning environment, where everyone in the team and as a team learns and improves continuously. If retrospectives are conducted to its true spirit, the team will identify the recurring mistakes (patterns) and will work on improving. It helps in identifying the best practices and sharing the knowledge across the organization. It helps the team to prepare for the future. Underlying theme: What can we do better next time?
References Project Retrospectives: A Handbook for Team Reviews Agile Retrospectives: Making Good Teams Great Sustainable Software Development: An Agile Perspective
http://pragmaticintegration.blogspot.com/2007/01/first-scrum-sprint-retrospective.html http://www.cs.unca.edu/~manns/RetrospectivesPresentationatOOPSLA03.ppt What's a Manager to Do? Manager's role in self-organizing teamsMoving toward self-organizing teams--whether driven by adopting agile methods or not--doesn't mean that all the managers are out the door. There's still plenty of management work to do; it's just different work. And, for many managers, it is also more satisfying work.
In this article Esther Derby describes how self-organizing teams are different from manager-led teams and lay out how that changes the manager’s role.
Manager-led teams are often like ski teams. Each person is selected for her individual skills and abilities as a skier. Each excels as an individual. All the members of a ski team are working for a common goal--winning the competition. Each contributes to success by making it down the hill as fast as she can, while passing through all the gates on the course. The coach's job is to improve individual performance skills. A ski team trains together, but when the meet comes, each team member is on their own. They don’t win by working together; it's the sum of the individual scores that wins the meet.
Original URL: http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea December 16 Program Management - What is it all about?I was talking to a friend of mine (who is a project manager). He was asking me how my current role is different from a project manager's role. I discussed with him about the differences.
I have consolidated my notes from readings and my thoughts.
PMI's Standard for Program management defines it as Program: "A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually". Program Management: "It is the centralized management of a program to achieve the program's strategic benefits and objectives".
Enterprise Programme Management: Delivering Value defines it as "We define enterprise program management as the capability to lead and manage resources, knowledge and skills in the effective deployment of multiple projects designed collectively to deliver enhanced value"
Program management provides assistance to: 1. Ensure alignment of activities across multiple projects 2. Optimize the use of resources 3. Communicate with and involve people, both within and outside the program 4. Drive the achievement of strategic objectives, and the delivery of benefits.
Program Management System 1. Assists in the coordination of resources, timescales and scope across project teams 2. Facilitates the effective deployment and sharing of skills and knowledge across the program 3. Tracks and manages issues, risks, delivery of benefits and alignment to program objectives 4. Provides executive management with a ‘dashboard’ on programme progress 5. Provides programme management with the information and levers that they need to effectively manage program's.
The Handbook of Program management defines the Role of a Program Manager as Program manager's role varies from managing multiple projects to managing multiple projects with operational responsibilities. Typically, a program manager is subjected to all the complexities and stresses of a project manager, plus is required to manage ongoing operations while meeting business goal targets for the month, quarter, or year. The program manager often has to strike a balance between the amount of resources spent on operations and the amount of resources spent on development and new projects. A program manager needs to have an ingrained sense of organizational mission, must lead and have the presence of a leader, must have a vision and strategy for long-term organizational improvement, must be a relationship builder, and must have the experience and ability to assess people and situations beyond their appearances.
Program manager is · Ultimately accountable for delivery of the business objectives. · Accountable for profit or cost targets linked to business strategy. · Accountable for policies that defines how the work is accomplished as it will have an impact on the business and cost targets. · Accountable for establishing a culture that allows his or her project managers to be successful. The program manager must create, manage, and continually improve the culture that enables successful projects. · Accountable for providing clarity and clearing chaos. Program management decisions are both tactical and strategic in nature. The strategy aspects of these decisions must consider multidimensional impacts beyond the near-term delivery dates of the project.
Attributes of the Effective Program Manager · Being a program manager requires a greater skill set and more diverse background than being a project manager. · The most significant difference between project manager responsibility and program manager responsibility is the requirement for the program manager to establish a culture of success. · Self-regulation takes time to create, but it is the ultimate definition of presence. With self-regulation, the organization acts and performs just like the program manager would want it to even if he or she is not present. · Leadership is based on a relationship of trust, and program managers must consistently develop and use relationship capital. · The ability to accomplish objectives through others is directly correlated to the strength of the relationships or the relationship capital the program manager has developed. · Consistency in style, management techniques, and leadership traits are important anchors for any organization and contribute to a stable work environment. · Effective questioning starts with being perceptive and in touch with the organization—having a feel for the organization above and beyond what charts and graphs provide. · As program manager you want to establish a “self-regulating” culture where your team answers your questions before you ask them. · Decisions should be made quickly and at the appropriate level through the establishment of clear lines of accountability and escalation processes. · Long-term program success is dependent on the continued growth and development of program personnel.
Summary: A program manager is a Business Owner who owns the profit and loss of the group/program which he/she manages. It is more of a mindset transformation from a project manager's role. He / She is responsible for the overall accountability of the management of multiple projects, deliverables and budgets
As a Project manager, it is very important to solve people problems. Even as a Program manager it is very important, but the responsibilities are more than that. It is very important to empower the project managers in the program/group to handle such issues so that as a program manager one can handle the prime responsibilities of a program manager.
The success of a project manager is defined by how one executes the project and delivers the project within the triple constraints. The program manager also is judged on these three elements but at a level that is cumulative for all the projects and operations within the program. This aggregation of responsibilities for a variety of projects and operations means the program manager must make frequent trade-offs between business targets and project/operational performance.
As a Program manager, one will be responsible for the successful delivery of the Projects, creating a culture which enables project managers to deliver successfully, customer satisfaction, resource management (managing resources, recruitment, retaining employees, attrition, and employee satisfaction), risk management at a program/group level, responsible for the profit and loss, business development, meeting business and cost targets.
Books Referenced: · Enterprise Programme Management—Delivering Value · The Standard for Program Management
Does your behavior damage trust?A great article that asks the question “Does your behavior damage trust?” How might you be contributing to mistrust on your team? Here are 25 behaviors that contribute to creating mistrust within your team: 1. You fail to keep your promises, agreements and commitments. 2. You serve yourself first and others only when it is convenient. 3. You micromanage and resist delegating. 4. You demonstrate an inconsistency between what you say and how you behave. 5. You fail to share critical information with your colleagues. 6. You choose to not tell the truth. 7. You resort to blaming and scape-goating others rather than own your mistakes. 8. You judge, and criticize rather than offer constructive feedback. 9. You betray confidences, gossip and talk about others behind their backs. 10. You choose to not allow others to contribute or make decisions. 11. You downplay others' talents, knowledge and skills. 12. You refuse to support others with their professional development. 13. You resist creating shared values, expectations and intentions in favor of your own agenda; you refuse to compromise and foster win-lose arguments. 14. You refuse to be held accountable by your colleagues. 15. You resist discussing your personal life, allowing your vulnerability, disclosing your weaknesses and admitting your relationship challenges. 16. You rationalize sarcasm, put-down humor and off-putting remarks as "good for the group". 17. You fail to admit you need support and don't ask colleagues for help. 18. You take others' suggestions and critiques as personal attacks. 19. You fail to speak up in team meetings and avoid contributing constructively. 20. You refuse to consider the idea of constructive conflict and avoid conflict at all costs. 21. You consistently hijack team meetings and move them off topic. 22. You refuse to follow through on decisions agreed upon at team meetings. 23. You secretly engage in back-door negotiations with other team members to create your own alliances. 24. You refuse to give others the benefit of the doubt and prefer to judge them without asking them to explain their position or actions. 25. You refuse to apologize for mistakes, misunderstandings and inappropriate behavior and dig your heels in to defend yourself and protect your reputation.
When you show up in integrity, authentically and allow your vulnerability, others will see you as genuine, warts and all. As such, your teammates will begin to trust you and gravitate towards you as you have created a personal container of safety in which others feel they can relate to you in an equally genuine fashion. Communication and true teamwork is a function of trust, not technique. When trust is high, communication is easy and effortless. Communicating and relating are instantaneous. But, when trust is low, communicating and relating are efforting, exhausting, and time and energy consuming. Finally, no one wants to give 100% to someone they can't trust.
Original URL: http://www.management-issues.com/2008/10/27/blog/does-your-behavior-damage-trust.asp
Via: http://www.thepracticeofleadership.net/2008/11/24/is-your-behaviour-damaging-trust/
November 26 91 Surefire Ways to Become an Even Greater DeveloperFantastic list of resources to become an even greater developer. URL: http://effectize.com/become-coolest-programmer Via: http://www.codesqueeze.com/squeezed-links-november-2009/ November 23 Emotional Intelligence TrainingI attended a training on Emotional intelligence recently. It was a 2 day session conducted by Dr. Smita Fernandez from Navgati. Emotional intelligence is not an easy subject to understand and i have tried reading the book by Dale Goleman before, but never succeeded. I was very curious how this training will be. Dr. Smita facilitated the session very well and we (audience) never felt that we are attending training for 2 days. She made it so interesting and i really enjoyed the session. Some of the key learning’s. a. broken record b. fogging, c. negative inquiry, d. negative assertion, e. free information and f. workable compromise 6. Empathy. 7. Strokes - Positive and Negative. Importance of strokes in the work place 8. Goleman's Model: a. Knowing your emotions - Self Awareness b. Managing your own emotions - Self Regulation c. Motivating yourself d. Recognizing and understanding other people's emotions – Empathy e. Managing relationships, ie., managing the emotions of others - Relationship Management
November 08 Estimating Software Projects I found this useful link from Deepak's Blog. Blogmarking it. Original URL: http://www.bmeacham.com/Estimating/Estimating.pdf October 23 BlogmarkProject Management Personality & Skill Types: Find out about your personality and use it wisely.
Original URL: http://www.alexsbrown.com/pmpersskilltypes.html
September 25 BlogmarksRelease Planning - Predicting Team's Velocity: Talks about the Yesterday's Weather Method
Software Development Diseases and Agile Medicine
September 07 As a Man thinketh - Book ReviewA Classic. Its about Positive thinking. Great motivational book. I could not read much recently. I thought of reading something which i could complete it over the weekend. This book is a quick read and insightful Book.
Thanks to Venkat Krishnamachari (Microsoft) for suggesting and lending me this book. I found some good reviews about this book in the web. http://blog.lifestyletransformations.com/as-a-man-thinketh-james-allen-book-review/ http://www.goodreads.com/book/show/81959.As_a_Man_Thinketh September 05 BlogmarksPM Talks http://blog.brodzinski.com/2008/09/pm-talks.html
Leading One-on-One http://svprojectmanagement.com/2008/08/20/leading-one-on-one/
The Big Development Project: How much should it cost? http://agilesoftwaredevelopment.com/blog/peterstev/big-development-project-how-much-does-it-cost Nurturing the self-organizing team http://agilesoftwaredevelopment.com/blog/artem/nurturing-self-organizing-team
Strategies for Scaling Agile Software Development http://www.ibm.com/developerworks/blogs/page/ambler?entry=large_agile_teams
Effective Status Reports http://tynerblain.com/blog/2008/09/03/effective-status-reports/
How to Measure the Impact of “Soft Skills” http://greatleadershipbydan.blogspot.com/2008/09/how-to-measure-impact-of-soft-skills.html
The 10 Commandments Of Goal Setting http://www.ravensbrain.com/2008/09/10-commandments-of-goal-setting.html |
||||
|
|