Being Agile: Team Got To Know Its Limitations

#SridharPeddisetty #Agile #BeingAgile #Scrum #Motivational #ProjectManagement #Management #AgileBestPractices #Team

"A man's got to know his limitations”, a quote made immortal by Clint Eastwood in the 1973 movie Magnum Force. I am not a movie buff but do like to rewatch classics once in a while and the inspiration to write this blog came right after watching Clint deliver his famous one liner. While adopting Agile development practices, its often seen that Organizations have a great deal of passion and good intentions. But unfortunately the intent alone is not enough if the attempt involved either the adoption scope to be too large or at a pace too fast for the organization, whose culture is not ready. 

For successful adoption of Agile across Organization, its important to start with one or two pilot teams. For the team to be successful in adopting Agile practices, its important to get to know its limitations. Intimately knowing and addressing team limits, a lot could be truly accomplished. Below are my tips in identifying team limitations and playing to their strength for successful adoption of 'Being Agile'. 

#1. Deep philosophical understanding of Agile: In my earlier post An Agilist Needs More Than Training To Succeed, I had shared that getting trained in Agile does not necessarily mean that we have started thinking ‘Agile’. After training, it is important to work in your Org towards bringing in changes including predictable delivery by taking small steps in developing an environment, which fosters a collaboration culture with a shared vision across the Org. 

#2. Get familiar with individual team skills: Agile encourages team to consist of self performing & cross functional team members. Its important to understand the skills of each team member including front end, back end and other needed skills in the sprint (or) project. While grooming or planning, its essential to identify and play to the strengths of individual team members.  While finalizing the team, one needs to be very clear what the objectives are and what they need to deliver individually as a member and collectively as a team.

#3. Set clear goals for the team: Its vital for each member to understand how their individual goal fits into the overall objective. For a team to be highly productive, its vital for them to understand what they are delivering as a team and how the deliverables are going to be measured. A team, which understands the importance of what they are delivering will always be highly productive and will adhere to much higher standards than one with no clear purpose. 

#4. Provide team the necessary tools: Performance of any project team is only as successful as the weakest link in the team. So we need to constantly nurture the individual team members while providing the necessary tools to be productive. For instance, once we have identified the weakling, its necessary to plan the mitigation either by pair programming or mentoring by cross training or guiding. Keep in mind that a happy team would automatically take care of keeping your client(s) happy so its important for the team to be equipped with right & necessary tools.

#5. Build in culture of continuous improvement: Its essential to create a robust environment where feedback is encouraged, appreciated and taken (or) given on a standard basis. Without proper guidelines, measurements and feedback, it is very easy for team to fall into a spiral trap of stress, demotivation and rapid disintegration. When the right culture of continuous improvement is put in place, it always guarantees a well-functioning, highly motivated and goal-driven team. 

Summary

While the practitioners of Agile are still divided into teams that are highly productive ‘Being Agile' and teams that are not. In my experience, team is successful in adopting Agile when it understands well its limitations and plays to its strength within the known constraints while continuously striving to improve. Teams that usually fail in adopting Agile successfully or struggle in their adoption are the ones that are usually leaning towards why something will not work rather than working on finding solutions to the constraints. 

Share your thoughts in the comments sections to the best team management practices you employ while practicing Agile. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery 
• Kanban & DevOps - Forming A Perfect Alliance
• An Agilist Needs More Than Training To Succeed

Being Agile: Best Practices For A Retrospection

#SridharPeddisetty #Agile #BeingAgile #Scrum #Motivational #ProjectManagement #Management #AgileBestPractices #Retrospection

"While some of us learn from the mistakes of others; the rest of us have to be the others!"

Being Agile is not just about processes, tools, bunch of smart technical people coming together & figuring it out all by themselves on what business value to deliver. Being Agile is about aligning the core Agile principles with the Org strategic goals and then enforcing the following of those core principles in delivering business value in an iteratively incremental manner. 

What is Retrospection?

By definition, retrospection is the action of looking back on or reviewing past events or situations. In the context of Agile, retrospective meetings are held at the end of an iteration or sprint. During the retrospective, the team reflects on what went well in the iteration or sprint and identifies lessons learned & actionable items for improvement moving forward.

Why Retrospection?

If you cannot measure, you cannot improve. Retrospection helps you provide a platform to measure your current status with the goal(s) and an opportunity to do course correction. In my earlier post Everyone's Perspective Is Key In Retrospectives, I had shared why its very important for everyone’s inputs to be considered during the retrospection. 

Best Practices for Retrospection

While working on any project there are 4 major components

1. People
2. Process
3. Technology & 
4. Tools

For having a productive retrospection, my recommendation would be for retrospection meeting participants to come prepared with some specifics in terms of above components. Keeping above components in mind, team can be specific about what went well in sprint or project, things that can improve for next sprint or project. For instance, some discussion points could be around following 

                   

                    People

• Did we identify all the right skills needed? 
• Did we mentor the team members as required?
• Did we follow RACI matrix as agreed upon?
• Did we manage stakeholder's expectations as per Backlog/SOW?
• Did we address team’s or individual impediments in a timely fashion? 

Process

• Did we use follow best practices in delivery process?
• Did we implement identified improvements in past retrospection? 
• Did we standardize our meetings to measure progress & concerns? 
• Did we practice continuous improvements? 
• Did we address any redundant process(es) that can be discarded or improved upon? 

Technology 

• Did we align technology solutions for optimally delivering business value? 
• Did we use coding best practices? 
• Did we follow technology best practices?
• Did we use good DevOps, build, deployment & automation best practices?
• Did we employ engineering practices like pair programing, peer code review, etc.?

Tools

• Did we make the best use of relevant tool for managing requirements & measuring progress?
• Did we make the best use of relevant tool to efficiently measure quality of our code?
• Did we make the best use of relevant tool to measure our testing to ensure quality alignment? 
• Did we make the best use of relevant tool to provide communication transparency on status, quality, etc.?
• Did we make the best use of relevant tool to optimize collaboration among team(s)? 

Summary

Its important for us to celebrate our successes & failures and retrospectives provide us an opportunity to do the same. 

“You can never make the same mistake twice. The second time you make it, its no longer a mistake, its a choice.”

Share your thoughts in the comments section on the best retrospection practices you employ while practicing Agile. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery 
• You Already Have ‘NO', Go For ‘YES'
• Every (Failed) Project Has ‘Success' Story To Tell 

Silence The Mind To Think Clearly & Deliver Results

#SridharPeddisetty #Agile #Scrum #Motivational #ProjectManagement #Management #AgileBestPractices #Inspirational  

Once there was a farmer who discovered that he had lost his watch in the farm. It was not an ordinary watch because it had sentimental value for him. After searching the hay for a long while, he gave up and sought help of a group of children playing outside the barn. He promised that the person who finds it would be rewarded. Hearing this, the children hurried inside the barn, went through and around the hay but still could not find the watch. Just when the farmer was about to give up looking for his watch, a little boy went up to him and asked to be given another chance.The farmer looked at him and thought, “Why not? After all this kid looks sincere enough.” So the farmer sent the little boy back in the barn. After a while the little boy came out with the watch in his hand. The farmer was happy and surprised and so he asked the boy how he succeeded where the rest had failed. The boy replied, “I did nothing but sit on the ground and listen. In the silence, I heard the ticking of the watch and just looked for it in that direction.”

A peaceful mind can think better than a worked up mind. Using the metaphor, a focused project team more often than not, delivers a project successfully. Project team must remain focused on managing value based project goals and stakeholders instead of simply concentrating on budget and scheduling. Below 5 tips can be used for a project team to remain focused 

#1. Be clear on the project value: Project delivery is not just about achieving agreed scope, schedule or cost but its about delivering value. Its often seen that project team while remaining focused on current work tasks sometimes remain oblivious of the value project is going to achieve at the end. In most cases, statement of work (sow) or proposal is authored by individual(s) who would likely not be responsible for actual execution of the project. So its important for the project team to be always aligned with what would be the end value of project. Project team needs to have a complete ‘buy-in’ into the value for them to appreciate their current work tasks. 

#2. Break plan into achievable milestones: We all understand that for every journey we embark, milestones helps us remain focused. Milestones are the small steps, which leads project team to the ultimate project goal whether it be developing of new product or service. Measurable milestones help the project team remain focused and celebrate their achievements along the journey, which goes a long way for a motivated team. Milestones also help team in executing, checking, planning and acting while keeping tab on quality to ensure alignment with the overall project goal. 

#3. Prioritize impediments mapped with value: In my earlier post Looking At An Impediment From A Value Perspective, I had shared  how when faced with an impediment, enlarge your vision of looking at the impediment from the perspective of delivering value. Matured project teams view the impediments as tasks, which needs to be completed for respective user stories and the tasks could be updated and prioritized for the value. As a Scrum Master or Project Manager, one needs to know how things get done in the organisation and who to speak to when faced with an impediment. 

#4. Separate people from the problem: It is very easy to get overwhelmed with frequent pressures of delivering value and thats when things can get defensive for the team. In my earlier post You Already Have ‘NO', Go For ‘YES’, I had shared how its important to keep emotions under check while delivering and always keeping in mind to respond and not to react.’My side of the boat is not leaking’ attitude does not help so its important to separate people from the problem and be rational in identifying solutions for the impediments or dependencies. 

#5. Look for continuous improvements: In my earlier post Value Stream Mapping As A Process Improvement Tool, I had shared how "Value Stream Mapping” can be applied as a tool for identifying inefficiencies in the processes. Retrospections are also key in identifying opportunities for continuous improvements. Note that singular way of doing retrospections does not necessarily fit culture of all organizations so its very important to customize how the feedback is taken and loop for the continuous improvement is applied.

Summary

Similar to how important it is to allow yourself a few minutes of silence to think sharply, project team needs to be focused for successful delivery of project value. 

Please share your thoughts on how you manage to keep yourself focused. 

Previous posts you might be interested in

• 5 Tips Delivering Quality Services To Your Client
• 7 Tips Having Good Times In A Client Relationship
• Are You Providing 'Right' Status of Your Project, Program or Portfolio?

Looking At An Impediment From A Value Perspective

#SridharPeddisetty #Agile #Scrum #Strategy #Organizational Strategy #Impediment #AgileBestPractices

The old Master instructed the unhappy young man to put a handful of salt in a glass of water and then asked him to drink it. "How does it taste?" the Master asked. "Awful," spat the apprentice. The Master chuckled and then asked the young man to take another handful of salt and put it in the lake. The two walked in silence to the nearby lake and when the apprentice swirled his handful of salt into the lake, the old man said, "Now drink from the lake." As the water dripped down the young man's chin, the Master asked, "How does it taste?" "Good!" remarked the apprentice. "Do you taste the salt?" asked the Master. "No," said the young man. The Master sat beside this troubled young man, took his hands, and said, "The pain of life is pure salt; no more, no less. The amount of pain in life remains the same, exactly the same. But the amount we taste the 'pain' depends on the container we put it into. So when you are in pain, the only thing you can do is to enlarge your sense of things..... Stop being a glass. Become a lake!"

By definition an impediment is a hindrance or obstruction in doing something. From an Agile perspective, an impediment is anything that keeps a team from being productive or reduces the progress of a well functioning team to achieve its goals. Some root causes of an impediment include

1. Lack of team cohesiveness 
2. Lack of domain knowledge 
3. Lack of technical skills
4. Limitations to environment 
5. Lack of tools  
6. Lack of well defined processes or
7. Lack of managerial or organizational buy-in  

More often, an Agile team spends a lot of time in trying to categorize the impediment, be it trying to classify it as a feature, epic, user story, user task, bug or technical debt. Not undermining the importance of classifying an impediment but while looking at an impediment, its important to view the impediment in the context of delivering value rather than spending too much of an effort in categorizing it. Just to reiterate, categorization of an impediment sometimes helps to discover new impediments so its important but remember that it is in the solutions to those impediments where you find innovative ideas for your team to provide more value. In other words, remind yourself that impediments could be viewed as the tasks that need to be completed for user stories and then the tasks could be prioritized for the value. If needed, impediments can be managed in an impediment register where they can be prioritized as needed. 

Summary

To summarize, focus more effort on solutions rather than categorization of impediments. So when faced with an impediment, enlarge your vision of looking at the impediment from the perspective of delivering value. 

Previous posts you might be interested in

• Everyone's Perspective Is Key In Retrospectives
• Active Listening Is Key For A Successful Delivery
• Minimum Marketable Features: An Agile Essential

You Already Have ‘NO', Go For ‘YES'

#SridharPeddisetty #PreSales #Negotiation #Project #BestPractices #Agile #ProjectManagement 

"You already have NO, go for YES!" is possibly the best advise shared by my colleague to sum up a hectic 10 days PreSales trip. In the last ten days, we travelled extensively across North America meeting with various clients, which worked out to be an enriching experience for both of us. Coming from a delivery background, this PreSales trip was a learning experience in many ways for me. More often than not, when you are selling your services, its the preconceived perception that is normally challenging to change. By definition, perception is the way in which something is regarded, understood, or interpreted. So when my wise colleague shared with me the wisdom he got from his mother, it truly reflected the challenge we mostly overcome during our PreSales meetings. The challenge of going for ‘Yes’ when we already have a ‘No’. 

In my earlier blog posts, 5 Tips Delivering Quality Services To Your Client and 7 Tips Having Good Times In A Client Relationship, I had shared tips on maintaining robust client relationships and how to ensure providing quality services to your client. This post is more applicable for PreSales phase, which precedes before starting work with a new client or on a new project. In the book "Getting to Yes, Negotiating Agreement Without Giving In", based on the work of the Harvard Negotiation Project, authors Roger Fisher and William Ury outline four parameters for principled negotiation:

1. Separate the people from the problem
2. Focus on interests, not positions
3. Generate a variety of possibilities before making a decision and 
4. Define objective standards as the criteria for making the decision

All of above four parameters are applicable when transforming the perception of people into a positive outlook. Below I am sharing five tips on how you can go for ‘Yes’ when you have already have a ‘No’.

Tip#1: Identify the people for whom you would want to change perception - Its an important first step to identify the people and their positioning of strength. Have a clear understanding on who are the influencers whose change of opinion would matter the most. Its more on focusing on their respective needs rather than their positions. 

Tip#2: Identify the reasoning of perception - Understand the background to get some context behind the perception. Its important to understand whether the perception is a direct result of personal experience or its an opinion formed by hearing other’s experience. This would help while devising the plan on transforming.  

Tip#3: Plan to transform the perception - Identify and establish some common grounds while planning the transformation. There is a reason why a perception is formed so plan to be assertive without being argumentative. Prepare yourself with ideas, logics and rational reasoning to counter the perception.  

Tip#4: Execute on the plan - Its important to keep emotions under check while executing the transformation. Keep in mind to respond and not to react. Always keep me in mind that you build relationships and connect with others by listening to understand and not listening to respond. 

Tip#5: Have Follow Ups - Its important to have regular follow ups with the individuals you are trying to change the perception. Closing the loop is very critical in ensuring a trustworthy relationship. 

Summary

To summarize, going after ‘Yes’ is more about knowing what you want, going after it and in the process respecting the person on other end of the deal. Go after ‘Yes’ to build long lasting relationships rather than burning bridges on your way out of the meeting room.

“Place a higher priority on discovering what a win looks like for the other person.” – Harvey Robbins

Previous posts you might be interested in 

• 5 Tips Delivering Quality Services To Your Client
• 7 Tips Having Good Times In A Client Relationship
• Active Listening Is Key For A Successful Delivery 

Every (Failed) Project Has ‘Success' Story To Tell

#SridharPeddisetty #LessonsLearned #Management #Project #BestPractices #Agile #ProjectManagement 

A 24 year old boy seeing out from the train’s window shouted…
“Dad, look the trees are going behind!”
Dad smiled and a young couple sitting nearby, looked at the 24 year old’s childish behavior with pity,
suddenly he again exclaimed…
“Dad, look the clouds are running with us!”
The couple couldn’t resist and said to the old man…
“Why don’t you take your son to a good doctor?”
The old man smiled and said…
“I did and we are just coming from the hospital, my son was blind from birth, he just got his eyes today.

We should not judge too soon before knowing all facts as at times the truth might surprise you. Every single person on the planet is unique and has a story to share. Similarly, every project is unique and has a ‘success’ story to tell even if it failed to meet its objectives in the eyes of stakeholders. By definition, project is a temporary unique endeavor having start-end timelines with a defined scope & resources with planned set of interrelated tasks executed to accomplish goal(s). 

There are many means to measure the success and failure of a project but there is no strict line dividing between the two. For instance, a ‘successful' project could have exceeded the planned budget or went over scheduled delivery date or could even not have provided all the planned functionalities upon completion. Whereas a ‘failed’ project could have a release with all planned features but missed the critical market launch or could not align with the direction of new leadership team. Brian K Willard in his Project Success and Failures article has shared examples, which strengthens the point that success or failure of a project are subjective. 

In my earlier post, Why Sharing Lessons Learned Is Key For Matured PMO, I discussed why sharing 'lessons learned' across teams is one of the key aspects of a matured PMO in an Organization. A well organized exercise to document 'Lessons learned’ would include identifying the ‘success’ factors of a project and understand how to repurpose it for future or existing projects. Success factors that could be salvaged from a ‘failed’ project could be

• An improvement to internal process(s) 
• An improvement in technical skill(s) of the resource(s) 
• An improvement to service(s) for the end customer 
• An improvement to save cost in utilizing key resource(s)

The exploitation of knowledge and experience gained from completed projects is very critical for a matured organization and application of the same for continuous improvements.  

Summary

To summarize, do not judge a ‘failed' project too soon without getting specific facts for learning lessons. It's important to identify and share the ‘success’ value of a project even if it failed to meet its main strategic goals.

Remember not to throw the baby out with the bathwater!

Previous posts you might be interested in:

• Why Sharing Lessons Learned Is Key For Matured PMO
• Top 20 Tips for Project Managers
• Are You Providing 'Right' Status To Stakeholders?

Change Management Is Not Everyone's Cup Of Tea

#SridharPeddisetty #ChangeManagement #Management #Project #BestPractices #Agile #ProjectManagement 

There's an old sea story about a ship's Captain who inspected his sailors, and afterward told the first mate that his men smelled bad. The Captain suggested perhaps it would help if the sailors would change underwear occasionally. The first mate responded, "Aye, aye sir, I'll see to it immediately!" and went straight to the sailors berth deck and announced, "The Captain thinks you guys smell bad and wants you to change your underwear." He continued, "Pittman, you change with Jones, McCarthy, you change with Witkowski, and Brown, you change with Schneider."

Moral of the story: 
Someone may come along and promise "Change", but don't count on things smelling any better.

Whether your Organization is using Agile or Iterative or Traditional methodology to deliver services to its customers, Change Management is a key component to ensure alignment of plan with strategic objectives. Change Management is a structured approach comprising of an approval process, which allows a change request to move through a series of approval stages to ensure that the lasting benefits of change are achieved. Organizations still struggle to implement a robust Change Management process vetting out the changes as they ought to be.

Common pitfalls seen in Change Management process include

1. People are not very receptive to expect change. Either there is not a good process to identify and report change or enough stakeholders are not involved early enough to vet out the change. 
2. More often than not, necessary ‘Change Impact Analysis’ is not performed to truly understand the impact of a ‘Change’ and how its aligned with the strategic objectives of an Organization. 
3. Project plans are not always changed to reflect the impact of a change, which could effect overall schedule, cost and likely result in scope creep. 
4. If the project plans are changed, they are not communicated to all project stakeholders to ensure everyone are aware of the change, its likely impact and seek approvals. 
5. Weigh the priorities of the change with the tasks in pipeline, aligning with strategic objectives of the Organization 

Below is a pictorial depiction of a simple 'Change Management' process

Summary

Presently all Organizations are growing through a disruptive phase whether its technology transformation, changing customer demographics, challenging economic times, etc. In this phase, It is an organization's ability to learn and translate that learning into action rapidly, which gives it the ultimate competitive advantage. In other words, sustaining success depends on an organization’s ability to adapt to a changing environment. Implementing a robust Change Management reduces disruptive aspects and emphasizes positive opportunities in the change process. 

In my future blog posts, I will be sharing how specifically to plan Change Management in an Enterprise Agile setup. 

Previous posts you might be interested in

• Value Stream Mapping As A Process Improvement Tool
• Are You Providing 'Right' Status To Stakeholders
• 10 Ground Rules On Right Metrics For Your Business

Everyone's Perspective Is Key In Retrospectives

#SridharPeddisetty #Agile #Scrum #Retrospection #Project #Retrospective #Management #BestPractices #ProcessImprovement  

In the early 20th century, an Architect and an Engineer entered a fancy hotel with a roll of blueprints to investigate how to add an elevator to the building. As they were measuring and planning where to knock holes in walls, the Janitor walked up and asked what they were doing. They told him that they would be installing a new elevator in the building. The Janitor quipped, "That's gonna make quite a mess."  Both the Architect and the Engineer assured the Janitor that he would get help cleaning up after they were finished. The Janitor scoffed: "I don't know why you want to go through all that trouble. If it were me I'd put the elevator on the outside of the building and save the fuss." The Engineer looked at the Architect and they were dumbstruck--and the elevator on the outside of a building was born.

Introduction

People with a different perspective can come up with some incredible ideas. Above is an example of an incredible idea, which goes to show that everyone’s inputs are equally important. Even though most of us understand this well, sometimes during retrospective meetings, the Scrum Master or Facilitator fails to have all participants share their thoughts. Not everyone in the team is an extrovert or feels secure enough to share individual opinions in front of others. So the onus lies on the Facilitator of the retrospective meeting to ensure everyone’s perspective is taken. 

Tips on taking everyone’s perspective in retrospectives

Below are 5 tips on how to take everyone’s perspective in a retrospective meeting

Tip#1: Ensure a comfortable setup

Whether doing retrospective with co-located team or a remote team, it’s important to have a meeting setup, which instills comfort for the participants. Personally, I have seen retrospectives done over video conference where some participants are not visible on the screen, which makes it uncomfortable for some to speak while not being visible. Ideally, retrospectives should not include anyone who is not going to contribute. Some members could possibly feel uncomfortable speaking in front of an audience who are not part of the team or does not have anything to contribute in the meeting. 

Tip#2: Share all relevant data ahead of time

Provide an opportunity for participants to be prepared for the retrospective meeting. Normally the tool provides visibility of the goals for a sprint or a release and the actual deliveries. It helps to summarize what was planned, what was achieved and other relevant details in the agenda so that the participants can come prepared with their thoughts to share. It also helps to share the status on action items ahead of time and what has been accomplishment in terms of continuous improvement from the lessons learned from the past retrospective meetings. 

Tip#3: Encourage participants to share thoughts without interruption 

We understand that not all technically skilled resources have good soft skills and some struggle to take time to explain their view point. It’s important to time box but at the same time a good Facilitator understands how to encourage participants to share their perspective. A Facilitator can ensure that someone is actively taking notes for future reference as needed. The Facilitator can also help in ensuring that technical details are understood by the non-technical participants. 

Tip#4: Facilitator should be unbiased  

The Facilitator should direct the conversations to encourage participants remain focused on the objective of the retrospective and ensuring that thoughts are challenged as needed and not the people. No side conversations or comments should be encouraged while a participant is sharing thoughts. The Facilitator should ensure that participants’ thoughts are respected and people can disagree without being disagreeable. 

Tip#5: Encourage consensus on action items

The Facilitator should ensure that there is a consensus on actionable items and identify the owner of the respective action item before wrapping up the meeting. Having a consensus encourages participants to think for themselves as a team. The Facilitator should also summarize main points discussed in the meeting and later follow up with an email or publish in a tool including meeting minutes. 

Summary

The best teamwork comes from the team members who are working independently but toward one goal in unison and working in an environment where everyone’s perspective is encouraged, heard and respected. 

Previous posts you might be interested in

• Active Listening Is Key For A Successful Delivery
• 5 Reasons To Let Your Team Struggle Today
• 20 Guidelines For A Productive Meeting

Everyone's Perspective Is Key In Retrospectives was originally published under Prokarma blog on Oct 26th 2015

5 Tips on Strategizing Your Key Project Resources

#SridharPeddisetty #Agile #PMO #Strategy #Project #Resources #Management #Tips #PMP #BestPractices #ProcessImprovement  

Once there was a company with a vast scrap yard that needed someone to guard it. So they created a night watchman position and hired a person for the job. Then someone thought, how would the watchman do the job without instructions? So the company decided to create a planning department and hired two people. One person was hired to write the instructions while the other person performed time studies. Later someone from the company thought, how would we know whether the night watchman is doing the tasks correctly…? So they created a quality control department and hired two people. One employee to do the studies and the other to write reports. After that, someone from the company thought, how are these people going to get paid…? So they created another set of positions, hiring two more people, a time keeper and a payroll officer. Again someone from the company said, who would be accountable for all of these people…? So they created an administrative section, hiring three more people, an administrative officer, an assistant administrative officer and a legal secretary. Finally, after one year, an executive in the company realized they were $18,000 over budget and must cut-back on overall costs. So the company laid off the night watchman.

Tip#1: Identify your key project resources

Firstly, it’s very important to identify who are the key resources for your project. Normally the key resources for a project are those with niche or advanced skills and knowledge or combination of skills and knowledge, which makes them indispensable. Once the key resources are identified, then it’s easier to follow the next tips in strategizing for them. 

Tip#2: Identify tasks for key project resources 

Identify tasks for key project resources and do resource leveling until no key resource is overloaded. In my earlier post Empower Your Team To Own Responsibilities, I had shared that the key to start empowering your team to own responsibilities is by making the list of tasks, which play to their strengths better and letting them own those tasks. Also in my earlier post Trust Your Team But Make Sure To Verify, I shared that it’s an important trait for the Scrum Master or Agile Project Manager to trust the self performing team to execute and deliver on business value but verifying the same with stage gates is essential.

Tip#3: Understand what motivates them

Robust communication, leadership and emotional intelligence are necessary to effectively communicate with key project resources in order to inspire and motivate them. It is important for the Project Manager to have the ability to strike a balance between knowing what motivates the key project resources and what they are working on. Work with the key resources to identify their goals and fitting them into the SMART (Specific, Measurable, Attainable, Realistic & Time bound) acronym.   

Tip#4: Encourage them to challenge status quo

Create a transparent, collaborative and productive environment in which project resources are encouraged to take calculative risks while challenging the status quo. If you want your key resources to take the risk of innovation then you have to give them freedom to fail. We understand that often your best people are the ones who make the worst mistakes, because your best people do the most complex work. In my earlier post 5 Reasons To Let Your Team Struggle Today, I had shared that in the face of adversity would emerge your next leaders, who emerge stronger and smarter.  

Tip#5: Plan a roadmap for their growth 

It’s important to invest in your key resources and train them in emerging skills or knowledge. Most organizations do not plan roadmaps for their key resources to grow, fearing the risk that they may leave. Experience teaches us that it’s better to train key resources and risk they leave, than not planning a growth roadmap and risk that they stay. 

If a drop of water falls in a lake, there is no identity. But if it falls on a leaf, it shines. So make sure to create an environment for your key project resources where their abilities and identity always shine.

Previous posts you might be interested in:

• Empower Your Team To Own Responsibilities 
• 5 Reasons To Let Your Team Struggle Today
• Trust Your Team But Make Sure To Verify

5 Tips on Strategizing Your Key Project Resources was originally published under Prokarma blog on Oct 23rd 2015

Why Sharing Lessons Learned Is Key For Matured PMO

#SridharPeddisetty #Agile #PMO #LessonsLearned #AgilePMO #ProjectManagementOffice #Project #PMI #BestPractices 

A farmer grew award-winning corn. Each year he entered his corn in the state fair where it won a blue ribbon. One year a newspaper reporter interviewed him and learned something interesting about how he grew it. The reporter discovered that the farmer shared his seed corn with his neighbors.
“How can you afford to share your best seed corn with your neighbors when they are entering corn in competition with yours each year?” the reporter asked.
“Why sir,” said the farmer, “didn’t you know? The wind picks up pollen from the ripening corn and swirls it from field to field. If my neighbors grow inferior corn, cross-pollination will steadily degrade the quality of my corn. If I am to grow good corn, I must help my neighbors grow good corn.”

Farmer is very much aware of the connectedness of life. His corn cannot improve unless his neighbor's corn also improves. So it is with our lives. Those who choose to succeed must help others to succeed. Those who want to live meaningfully and well must help enrich the lives of others, for the value of a life is measured by the lives it touches. And those who choose to be happy must help others to find happiness, for the welfare of each is bound up with the welfare of all. If we are to grow good corn, we must help our neighbors grow good corn. Call it mutualism. Call it a principle of success. Call it a law of life. The fact is, none of us truly win until we all win.

Albert Einstein famously said, "The only source of knowledge is experience" and what better way to gain wisdom from the lessons that we learn while executing projects, programs, portfolios or managing operations. Sharing 'lessons learned' across teams is one of the key aspects of a matured PMO in an Organization. Many of us have not personally experienced the pain of slipping, by stepping on a banana peel, but have learned those lessons through someone elses experiences. 

This is applicable for a matured Organization to have a functional PMO and create an environment of sharing lessons learned across projects, programs or portfolios. Note that 'lessons learned' is not only for documenting failures but also the success stories. The more knowledge shared, the more we gain and lessons learned from successes or failures helps an Organization to leverage on the successes and not repeat failures. For a matured PMO, its an important aspect to share 'lessons learned' on what went well and what did not go well so that an Organization does not repeat past mistakes while following patterns that are proved successful in the past. One template of documenting 'lessons learned' include

• Document the pre-condition(s) and condition(s) in which the negative (issue) or positive event (best practice) occurred 
• Describe how the issue arose and define the problem or positive event encountered, and
• Provide concrete, practical solutions or recommendations based on this experience.

and can be then tagged under 'Lessons Learned Knowledge Base’, which could be managed by PMO. 

"Those people who develop the ability to continuously acquire new and better forms of knowledge that they can apply to their work and to their lives will be the movers and shakers in our society for the indefinite future.” -Brian Tracy

Why Sharing Lessons Learned Is Key For Matured PMO was originally posted under Prokarma Blog on Oct 5th 2015

Is there a rope holding you in managing a Project, Program or PMO?

As a man was passing the elephants, he suddenly stopped, confused by the fact that these huge creatures were being held by only a small rope tied to their front leg. No chains, no cages. It was obvious that the elephants could, at anytime, break away from their bonds but for some reason, they did not.

He saw a trainer nearby and asked why these animals just stood there and made no attempt to get away. “Well,” trainer said, “when they are very young and much smaller we use the same size rope to tie them and, at that age, it’s enough to hold them. As they grow up, they are conditioned to believe they cannot break away. They believe the rope can still hold them, so they never try to break free.”The man was amazed. These animals could at any time break free from their bonds but because they believed they couldn’t, they were stuck right where they were.

As a project manager, program manager, portfolio manager or someone managing PMO, we all have our cycles of uncertainty and a fear of failure when a belief overcomes us that we cannot possibly do something, simply because we have failed at it before. During those uncertain times, its very important to remind us that failure is part of learning and we should never give up the ability to believe in ourselves. Personally, the best managers with whom i have crossed paths are those who have been fearless in going after goals without carrying the overhead thought of failure because in their mind there is nothing as failure. If a project has not delivered desired output or a program has not delivered planned outcome or a portfolio or PMO has not delivered laid out strategic objectives, we always end up learning how to manage it better the next time.

Always remind yourself that people judge us by what we have done till date and we judge ourselves by what we are capable of doing. Even though we all get it but seldom practice the art and science of learning from our past failures and making the most use of the lessons learned or retrospections for future success. With social media becoming a big part and parcel of our daily life, networking with professionals while sharing lessons learned and learning from each other’s experience, does go a long way to always challenge the status quo and help you keep raising your bar. As Charles Darwin famously quoted, "It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change."

Is there a rope that is holding you back today? Please share your thoughts.

Is there a rope holding you in managing a Project, Program or PMO? was originally published in LinkedIn