Being Agile: It’s A Matter Of Perspective

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

A young couple moves into a new neighborhood. The next morning while they are eating breakfast, the young woman sees her neighbor hanging the wash outside. "That laundry is not very clean", she said. "She doesn't know how to wash correctly. Perhaps she needs better laundry soap.” Her husband looked on, but remained silent. Every time her neighbor would hang her wash to dry, The young woman would make the same comments. About one month later, the woman was surprised to see a nice clean wash on the line and said to her husband: "Look, she has learned how to wash correctly. I wonder who taught her this.” The husband nonchalantly said, "I got up early this morning and cleaned our windows."

Its been more than 15 years since Agile Manifesto is formulated but still there are strong voices heard for and against adoption of Agile. Its interesting to hear the arguments of why ‘Agile’ does not work and these arguments are not very different from when traditional SDLC & project management practices were employed. If you analyze Standish Group 2015 Chaos Report, its interesting to align some of the common concerns about Agile with what is shared in the report. 

Some of common concerns about Agile include

#1. Agile just works for smaller projects: 

Larger the goals, larger the chances of its failure irrespective of how you execute your strategy. As I had shared in my previous post Being Agile: Identifying Right Opportunities To Act, one of the Agile principles is "If You Have to Fail, Fail Fast”. Whether we take the approach of Waterfall, Spiral, RUP or Agile SDLC methodology, success is more certain when we break our larger goal(s) into smaller milestones and frequently measure our execution results with the plan. According to the report, 18% large scale projects are successful when adapting to Agile compared with Waterfall’s 3% success so notion of Agile not working for large projects is not necessarily a fact. 

#2. Agile does not work in some native cultures: 

There are few articles stating Agile does not work in places like Asia or Germany. Its the most generalized statement without acknowledging that we are more global than ever before and emotional maturity in an Organization is changing faster than ever before. Having lived and worked in countries including India, Japan, USA and Argentina, I have experienced various cultures and my learnings have been that its not as much about the culture of the native country as its about the culture of the Organization. In an earlier post Be Too Agile To Be Governed By Fear Of Change, I shared that Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the culture of Organization must be ready to adapt for it to be successful.

#3. Agile is getting more done in less: 

Agile is more about being focused on delivering value and ability to respond to changes. While practicing the principles of Agile, it does feel that we are improving productivity but thats a result of applying the right principles. Motivation of adopting to Agile with the expectation that more can be expected to get delivered from the same team, is not the right thought process. In my earlier post An Agilist Needs More Than Training To Succeed, I shared that implementing Agile in any Organization requires more than just knowing the terms or ceremonies.

#4. Agile works only with co-located teams: 

Its not as much about whether team is co-located or not but its more about how much the project team is involved in decision-making and information-gathering process. A remote team can be as successful provided the team is actively involved enough with more robust communication channel established. Communication channel is key, which would include transparent user feedback, requirements review, R &D effort, prototyping and other consensus-building tools. In one of my previous post Everyone's Perspective Is Key In Retrospectives, I shared that people with a different perspective can come up with some incredible ideas and its about the right feedback channels in place whether with resect to co-located or remote teams. 

#5. Agile works only with strong performers in the team: 

No team member comes to work to do a bad job and its usually the culture of an Organization or project team that usually fails performers. So it does not matter whether you are employing Agile or not, performance of project team is dependent on collective success more than individual heroics. Agile encourages cross functional teams to bring down silos and when the silos are rid of, collective performance improves as there is better sense of common goal(s). In my previous post 5 Tips on Strategizing Your Key Project Resources, I shared 5 tips on how to strategize your key project resources. 

Summary

IMHO its not about which SDLC methodology or Project Management practices you follow for successfully delivering quality services but its about the principles you embrace to achieve goals. ‘Being Agile’ is not about some practices or set of rules, its about how disciplined principles are applied to achieve strategic objectives. 

“There are no facts, only interpretations.” ― Friedrich Nietzsche

Share your thoughts in the comments section on the common concerns you have encountered while practicing Agile. 

Previous posts you might be interested in

• Are You Providing 'Right' Status To Stakeholders?
• 7 Questions To Ask Before Establishing A PMO
• You Already Have ‘NO', Go For ‘YES'

Being Agile: Identifying Right Opportunities To Act

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

A police officer found a perfect hiding place for watching for speeding motorists. One day, the officer was amazed when everyone was under the speed limit, so he investigated and found the problem. A 10 years old boy was standing on the side of the road with a huge hand painted sign which said “Radar Trap Ahead.” A little more investigative work led the officer to the boy’s accomplice: another boy about 100 yards beyond the radar trap with a sign reading “TIPS” and a bucket at his feet full of change.

All problems are opportunities in disguise. Having said that, not all problems are well understood and therefore not all right opportunities are identified to act upon. One of the main incentives seen of Agile adoption across Organizations is in identifying & acting upon the opportunities in a disruptive & fast changing new World. 

Below are few tips in identifying the right opportunities to act upon and successfully delivering the results using the Agile philosophy 

#1. Define Clear Problem Statement(s) Mapped With Customer(s): 

Define clearly problem statement(s) mapped with customer(s) and what matters to them the most. This can be accomplished by engaging, observing and working closely with your key customers in identifying the opportunities with their changing demands. It seems very obvious but if the upfront effort is not put in defining customer needs and if they are not aligned on the key problem statements, which needs to be solved, there will be an immense waste of time, effort and Organization resources. 

#2. For Defining Goals Iterate Enough To Identify MileStones: 

While identifying the problem statements, its important to clearly define the criteria for success. Plan to break down the success into a journey and not necessarily a destination. This should be achieved by identifying the milestones and iterating through the milestones in achieving the goals. In my earlier post Be Too Agile To Be Governed By Fear Of Change, I had shared how Agile processes harness change for the customer's competitive advantage. 

#3. Design Org. Strategy For Maximizing Learning To Manage Risks : 

Design your Organization strategy in identifying and defining Internal processes, tools & technologies, which creates an environment that maximizes learning to manage risks. Its important to anticipate changes, which may affect achieving your goals but with right environment, problems can be converted into opportunities. Encourage experimenting and then reinforcing & building on what works. Enlist and inspire your Org. around a compelling purpose and grant Project team(s) the autonomy and resources to continuously adapt and adjust course.  

#4. Start Small, Think Big & Scale Fast: 

Its important to focus on developing a minimum viable product (MVP) for early validation of the product. Formulate the philosophy of starting small, thinking big and scaling fast. In my earlier post Minimum Marketable Features: An Agile Essential, I had shared how the product innovation is tied to change and often the need for change appears midstream in a project so decomposing the requirements into Minimum Marketable Features (MMF) is key for successful execution of solutions for right opportunities 

#5. If You Have to Fail, Fail Fast: 

In the fast paced changing trends, ideas for product innovation needs constant nourishing. For the success of pursuing right opportunities, its important to generate alternatives and make fast, fact-based decisions about which to pursue. So if you have to fail, fail fast. Iterate to build new capabilities, shed what doesn't fit and take the first steps in a new direction as needed. In my earlier post Every (Failed) Project Has ‘Success' Story To Tell, I had shared how its important to identify & share the ‘success’ value of a project even if it failed to meet its main strategic goals.

Summary

In the past, Organizations very diligently used to spend quality time in formulating a strategy and then sticking with it through the thick & thin. Today we are in Fourth Industrial Revolution in which we are talking about Cyber-Physical systems and in these interesting times, Organizations rapidly surge ahead, rapidly fall behind, or even rapidly disappear. So in these interesting times for an Organization to survive, it needs to continuously evolve, change and stay a step ahead of its competition. And for that survival, Organizations need to be in an advantageous position of identifying the right opportunities to act upon. 

Share your thoughts in the comments section on how do you normally ensure identifying rights opportunities to act upon while practicing Agile. 

Previous posts you might be interested in

• Are You Providing 'Right' Status To Stakeholders?
• 7 Questions To Ask Before Establishing A PMO
• Top 20 Tips for Project Managers

Be Too Agile To Be Governed By Fear Of Change

#SridharPeddisetty #Agile #Scrum #Strategy #Change #Management #ChangeManagement #AgileBestPractices 

Your success in life isn't based on your ability to simply change. It is based on your ability to change faster than your competition, customers, and business.

-Mark Sanborn

One of the Agile principle states “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”. Apparently the name "Agile" was chosen because its founders viewed "adaptiveness and response to change" as the most essential concept of the methodology. Agile based SDLC methodology of building potentially shippable products incrementally in short periods of time is one of the most tangible changes and benefits, which an Agile process provides. Change is the only constant factor in a SDLC and we should plan enough to be receptive to change. Agile creates an opportunity for increased customer satisfaction and return on investment by handling change effectively with more robust feedback loops, which accommodates changing requirements to generate higher-value products.

Below are the 5 tips on managing change successfully 

In my earlier post Change Management Is Not Everyone's Cup Of Tea, I had shared how presently all Organizations are growing through a disruptive phase whether its technology transformation, changing customer demographics, challenging economic times, etc. In this disruptive phase, It is an Organization's ability to learn and translate that learning into action rapidly, which gives it the ultimate competitive advantage. 

Summary

Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the project teams must be ready to adapt. 

Previous posts you might be interested in

• Minimum Marketable Features: An Agile Essential
• Looking At An Impediment From A Value Perspective
• 5 Tips Delivering Quality Services To Your Client

How Osmotic Communication Works For NearShore Team

#SridharPeddisetty #Agile #Scrum #Strategy #Osmotic #Communication #Strategy #AgileTraining #AgileBestPractices #NearShore 

To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others  -Tony Robbins

What is Osmotic Communication?

Osmotic Communication is a term coined by Alistair Cockburn and the definition is: "Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work"

What is a NearShore Team?

A NearShore team provides services to the client from a country, which is having proximity in terms of time zone and geographic location to client's country. Its a virtual team providing quality services to the client by overlapping for more time with the client by working in similar time zone, collaborating in realtime. 

How Osmotic Communication Works For NearShore Team?

In my earlier post Active Listening Is Key For A Successful Delivery, I had shared how in Agile, requirements and solutions evolve through communication and collaboration between self-organizing and cross-functional teams. Also in another post Everyone's Perspective Is Key In Retrospectives, I had shared how 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.

Looking at the above illustration, its understandable that NearShore team cannot have the benefits of a face-face white boarding or in person conversations, but now with robust communication mediums including tools available, the communication gaps are shortened. Below are examples of few collaboration tools, which bridges the communication gaps working with virtual teams. 

1. Skype
2. RealTimeBoard
3. Jira
4. Confluence
5. MindMeister

Using the advantages of NearShore time zone proximity, virtual team works realtime with onsite team and using collaboration tools like Skype for communication. For instance, group chats in Skype provides the perfect opportunity for the onsite teams and virtual teams to have a real time discussion and Osmotic communication is possible with the inputs shared by random team members instead of relying on 1:1 communication. It does not work in all situations but group chats go a long way in facilitating Osmotic communication in which a Scrum Master or a Product Owner operating from onsite could be seeking an answer from a remote developer but the remote QA member could chip in, if the person has same or better understanding. In another example, say a remote developer has a question on specific feature and posts the question to PO or stakeholder in group chat. Response of which could not only benefit the developer but also the remote QA, who in turn use the information in creating more specific test scenarios or automation scripts. Another major advantage of tool group chat is archiving of the communication for future reference, which is something that is not possible for a collocated team when having in person communication instead.  

Summary

Osmotic communication keeps the cost of communications low while keeping the feedback rate high. This in turn, helps keep the overall cost of quality low as while working with NearShore team, its evident for the client that the requirements are disseminated faster and errors are corrected quickly. With strong delivery management best practices, frequent face time with client, NearShore virtual teams can take the advantages of Osmotic communication. 

Previous posts you might be interested in

• Everyone's Perspective Is Key In Retrospectives
• Empower Your Team To Own Responsibilities
• Active Listening Is Key For A Successful Delivery

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

DevOps Is Essential For Faster To Market Services

#SridharPeddisetty #DevOps #Kanban #Strategy #Organizational Strategy #DevOpsStrategy #Agile

“If you can’t out-experiment and beat your competitors in time to market and agility, you are sunk. Features are always a gamble. If you’re lucky, ten percent will get the desired benefits. So the faster you can get those features to market and test them, the better off you’ll be. Incidentally, you also pay back the business faster for the use of capital, which means the business starts making money faster, too.” 

― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

It is no longer enough for organizations to merely build and release a better product to stay ahead of competition but in today’s disruptive era, the need of the hour is to build and ship faster than everyone else. In order to meet the demands of time to market features, organizations have realized the necessity to be Agile and are having a paradigm shift in the way they build and ship software. Agile SDLC with continuous integration and rapid deployment have now become a de-facto standard. In my earlier post Kanban & DevOps - Forming A Perfect Alliance, I had shared how Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. 

Former Cisco CEO, John Chambers in his last keynote strongly put it forward that 1/3rd of today’s businesses would not survive next 10 years. Startup companies are already disrupting long established business models and they are succeeding mainly because of their ability to faster to market services. 

How DevOps Is Essential For Faster To Market Services?

DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle. In my earlier post DevOps Need Collaboration To Succeed As A Practice, I had shared how by adapting to the culture of DevOps, an organization is not only focusing on agility but also on reliability by eliminating waste, identifying repeatable steps and automating those steps. DevOps is not just about technology disruption but is about transformative Organization and its ability to deliver value to the end consumer. Technology has become core for most businesses and is now an essential for their survival in a highly competitive space. Large enterprises have to be more nimble and the need of the hour is to move away from their large & complex interrelated legacy systems to a more Agile based environment with DevOps fueling the collaboration delivery setup.  

Summary

Early adopters of DevOps have seen a significant increase in their revenue, faster time-to-market and improved customer experience with their success depending on their ability to deliver a continuous flow of value from APIs, new mobile apps and software innovations.

Previous posts you might be interested in

• Kanban & DevOps - Forming A Perfect Alliance
• Minimum Marketable Features: An Agile Essential
• DevOps Need Collaboration To Succeed As A Practice

DevOps Need Collaboration To Succeed As A Practice

#SridharPeddisetty #DevOps #Kanban #Culture #Collaboration #SchneiderCultureModel #DevOpsStrategy #Agile 

“A great team doesn’t mean that they had the smartest people. What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists.” ― Gene Kim, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

DevOps formulates collaboration of Operations and Engineering teams to achieve continuous delivery by participating together in the entire service delivery lifecycle. DevOps is NOT a role but it is a shift in culture of an organization, which encourages greater communication and collaboration to foster building better quality software more quickly and with better reliability. There are good number of people who agree that DevOps is not a new phenomena and some organizations have been formulating collaboration of Operations and Engineering teams to achieve continuous delivery by participating together for releasing new product or service. However there are good number of organizations who are either warming up to the idea of DevOps and ready to adopt it or going through initial phase of DevOps adoption. It is important for the organizations to understand that "collaboration culture” is key for them to successfully adapt to DevOps. In my earlier post Kanban & DevOps - Forming A Perfect Alliance, I shared how Kanban and DevOps combine together to help bring down the silos between Engineering and Operations teams. 

Why DevOps need collaboration to succeed?

To understand why DevOps need collaboration to succeed, let's understand Schneider Culture Model, which defines four distinct cultures:

1. Collaboration culture is about working together
2. Control culture is about getting and keeping control
3. Competence culture is about being the best
4. Cultivation culture is about learning and growing with a sense of purpose

In the diagram below, Michael Sahota shared his thoughts on understanding the culture of an organization using Schneider Culture Model. Each of the four cultures are depicted – one in each quadrant with each having a name, descriptive quote, a picture, and some words that characterize that quadrant. 

As can be seen in the diagram, collaboration quadrant includes the words affiliation, synergy, partnership, interaction, trust, diversity and egalitarian to characterize itself while the descriptive quote is “we succeed by working together”. These are the exact characteristics that are needed for DevOps to succeed as a practice in an Organization in which Engineering and Operations teams come together to work with affiliation, synergy, trust as partners by closely interacting with egalitarian philosophy. 

Note that according to Schneider model, no one culture type is considered better than another and same is applicable to DevOps, in which possibly cultural elements from other quadrants (control, cultivation and competence) are applicable to DevOps. Depending on the organization but for DevOps to succeed, definitely the organization needs to have ‘Collaboration’ as the single dominant culture with elements from the other three culture quadrants.

By adapting to the culture of DevOps, an organization is not only focusing on agility but also on reliability by eliminating waste, identifying repeatable steps and automating those steps. Organizations will fail in adapting DevOps if the culture is not breaking down the organizational silos and in which everyone shares the accountability for delivery.

Summary

DevOps represents both a technology and a culture change in the organization and the objective of DevOps can be achieved only if the culture of the organization is more collaborative. In other words, DevOps need more of a "collaboration culture” in the organization to succeed as a practice. 

In the comments section, please share your thoughts on what do you think an Organization must do for DevOps to succeed and make a positive impact. 

Previous posts you might be interested in

• Kanban & DevOps - Forming A Perfect Alliance
• Value Stream Mapping As A Process Improvement Tool
• Metrics For Maximizing Productivity In Kanban SDLC

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

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