In today’s competitive job market, organizations are inundated with a deluge of resumes for every open position. To streamline the hiring process and manage this influx, many companies have turned to Applicant Tracking Systems (ATS) that rely heavily on keyword matching to screen potential candidates. However, this automated approach is not only inefficient but also unjustified, leading to significant drawbacks and missed opportunities in identifying the best talent for the job.
The Unjustified Reign of Keyword-Driven Screening
The use of ATS software has become ubiquitous in modern recruitment practices, with the promise of saving time and effort by quickly filtering through a large volume of resumes. These systems are programmed to scan resumes for specific keywords related to job requirements, skills, and qualifications set by the hiring team. Candidates whose resumes contain these keywords are then flagged for further review, while those lacking them are often discarded without human intervention.
However, this reliance on keywords overlooks the nuances of a candidate’s experience, achievements, and potential cultural fit within the organization. It fails to capture the full scope of a candidate’s capabilities beyond what is explicitly stated in their resume, leading to a narrow and incomplete view of potential candidates.
The Unintended Consequences of Keyword-Centric Screening
Keyword-driven screening can have severe consequences for the recruitment process and the future of the organization:
1. Ineffective Candidate Evaluation: Relying solely on keywords overlooks the nuances of a candidate’s experience, achievements, and potential cultural fit within the organization. It fails to capture the full scope of a candidate’s capabilities beyond what is explicitly stated in their resume.
2. Perpetuating Bias and Discrimination: Keyword matching can inadvertently perpetuate bias in hiring by favoring candidates who use specific industry buzzwords or have certain educational backgrounds. This can result in overlooking qualified candidates from diverse backgrounds or unconventional career paths.
3. Wasted Opportunities for Hidden Gems: Exceptional candidates who possess valuable skills or experiences not captured by standard keywords may be unfairly excluded from consideration. Creativity, adaptability, and potential for growth are often overlooked in favor of rigid keyword criteria.
4. Negative Candidate Experience: Candidates who feel their applications are being judged solely on keyword matches may perceive the hiring process as impersonal and dehumanizing. This can damage the employer brand and deter top talent from engaging with the organization in the future.
5. Identify incorrect candidates: This has been a recent experience, where in based on a few key words, the hiring team is short listing potential candidates, when reviewed / test evaluated / interview – these candidates are found lacking in their relevant skills as quoted on their problems.
The Need for a Holistic Approach
To address the shortcomings of keyword-driven screening and enhance the quality of candidate selection, organizations must adopt a more holistic approach to recruitment:
1. Define Clear Job Requirements: Instead of relying solely on keywords, hiring teams should clearly outline the essential skills, experiences, and qualities required for each role. This ensures that screening criteria are aligned with actual job needs.
2. Utilize Technology Wisely: While ATS systems can be valuable tools for managing high volumes of applications, they should be used as aids rather than substitutes for human judgment. Combining automated screening with manual review can help identify top talent more effectively.
3. Emphasize Soft Skills and Potential: Look beyond technical qualifications and prioritize soft skills such as communication, problem-solving, and adaptability. Assessing a candidate’s potential for growth and cultural fit can lead to more successful long-term hires.
4. Implement Diverse Hiring Practices: Actively seek out candidates from diverse backgrounds and experiences to foster innovation and inclusivity within the organization. Encourage hiring teams to look beyond traditional metrics and consider a wide range of perspectives.
Conclusion
In conclusion, the reign of keyword-driven candidate screening is not only inefficient but also unjustified. It leads to missed opportunities, bias, and subpar hiring decisions. By adopting a more balanced approach that combines technology with human judgment, organizations can improve their ability to identify top talent that aligns with their values and goals. Embracing diversity, emphasizing potential over checkboxes, and prioritizing candidate experience are key steps towards building a stronger workforce capable of driving innovation and success in today’s dynamic business landscape.
It is always known, observed, and seen that Project Managers use tradeoffs to provide decision-makers with data on the impact of a change on scope, time, cost, quality and risks (Though I mention this, I have never seen a proper and adequate level of impact analysis to the level as needed and required), then the sponsor understands the full impact whenever they have a variance or a change request.
Tradeoffs help maintain the project’s feasibility.
Check this fictional conversation:
Situation – Fixed Price, Fixed Scope, Quality Parameters have been agreed and Cost is Pre-agreed, The SoW is signed off. Contracts are in place. Planning is done and dusted, now the project is in execution phase.
And Bingo … we have an interesting request from the customer to the sponsor to change the dates of delivery and so the conversation happens somewhat like this:
The sponsor says to the project manager, “I want to move up the finish date from June 30 to May 30. Make it happen.” The sponsor starts to leave the meeting.
The project manager says, “Yes, I can shorten the duration of the project by four weeks. Your assistant told me about that, and I modeled it. To cut a month off the duration, I will need to have two additional developers and a tester for the month of April and the budget will increase by $10,000 for extra resources.”
A tradeoff has two sides. First, there’s the positive side where the PM shortens the duration of the project. Second, there’s the negative side where the project manager says they need an added budget for two additional engineers for the month and additional consultants.
The sponsor says,” No all I want is to cut the duration. No additional people or money.”
The PM says, “If I told you I could do that it would be lie. To shorten the date there will be other changes. It is not possible without consequences.”
The sponsor responds, “A good PM would be able to do whatever I want!”
Then the project manager replies, “But it would be a lie.”
Who wins this conversation / argument / decision making process, well it may seem that that the Sponsor would force the Project manager to agree to his / her ideas and thought process, but ultimately project drags on time and cost, has poor quality (a lot of defects, un-tested elements), team members have burnt out, the morale is low and customer is unhappy writing stinker of emails, there is a all-round loss and credibility issue, but who cares.
Did the sponsor review the impact of the new need / requirement where in the timelines / duration has been reduced?
Requirements for Trade offs
Tradeoffs are part of the toolset good project managers use. They must build the project plan with quantified measurable outcomes for every delivery. And the schedule must have work estimates and accurate precedence relationships. Then model every change with its compensating tradeoffs.
When project sponsors want to make a change, successful project managers never say, “Oh no, we can’t add that to the project.” What they say is, “Certainly I can add that to the project, but I will need three more people full time.” Other negative sides of the tradeoff could be, “We will have to increase the budget by $ XXX” or “We’ll have to reduce the savings in our scope by $ XXX.”
This is the language of tradeoffs. The project manager is not saying no. Instead, they are telling the sponsor or stakeholder what it will “cost” to bring about the change they want. Tradeoffs maintain the feasibility of the project. Merely shortening the duration does not.
There are no easy solutions and no easy decisions that one could make … Impact Analysis and Cost of Delay as a concept should be utilized for proper decision making.
Remember in any project, on one side we have the leadership / sponsors and others who at times have un-reasonable demands and the other end of the spectrum we have project manager who is trying to make the ends meet … Due to job constraints and lack of their ability to standup, the project manager looses the game and finally leadership and sponsors lose money, get poor quality and loss of face to the customers.
We have always tried to be penny-wise pound foolish
With all said and done, changes would occur and would be required to be managed. How should a tradeoff occur? What parameters should the Project manager be concerned about?
Juggling the 4 corners of the Project (Standing on 4 Pillars)
Any project would have to learn to live with these 4 corners of the game:
Project scope (including quality of deliverables)
Time / Duration
Risk
Cost (human resources and materials).
Which is more important? Given an option to make a choice, Let see a few permutation / combination to make a judgement call.
Let us say Scope is Changing, it is increasing … Then
Scope Change: Impact would be on: Quality, Cost, Time (atleast on one of them, but if you really think, it will impact all of them)
Where do we prioritize the approach, what should be the order of our decision making and relevant / related impact, Should it?
Order of Impact / Decision
Order of Impact / Decision
Order of Impact / Decision
Cost
Quality
Time
Time
Cost
Cost
Quality
Time
Quality
It is not an easy decision, but if quality is a thought, then as per me, it is a bad / poor idea. Spend more on Cost and try to minimize the impact on Quality and Time
The project is like a tube of toothpaste. When management / sponsors squeezes on a project’s duration corner by cutting the due date by a month, the toothpaste compensates by oozing out from one of the other corners. When the sponsor squeezes the duration, it will deliver less scope, cost more, or have a higher risk of failure and this is the kind of impact analysis that is required to be performed by the project and related stakeholders.
Changes in one parameter would always impact at least one other corner. That fact exists whether people recognize it or not. It’s not realistic to assume that making arbitrary changes to one corner of the project, like the duration, can happen without any compensating effects through the rest of the project.
Interestingly, the majority of the leadership and sponsors fail to recognize this impact. Because in most projects only one, or at most two, of these corners is measurable. The completion date is always measurable and is often rock solid. In some situations, the project budget is also measurable. But most internal projects have no other measurable dimensions. Even with the two measured dimensions of duration and budget, the business value of the project (the scope) and the risk of not delivering that scope on time are usually unmeasurable. So executives continue to make arbitrary changes to the duration and the budget and think that it will have no impact on the project’s scope, quality or risk.
What concerns me is that most of the leadership have no clue on this front, each of these leadership person must have risen through the ranks and would have faced these similar challenges in their project management days and now they behave very differently. Does change in position also impact the way a correct process should be adopted?
Is this science so difficult that we do not understand elements?
I recommend performing “What If” Analysis, where one can watch the impact of moving one parameter (or as we say one pillar) over others. This requires building some models (but once you do it, will serve the organization for its life), then performing different permutation and combinations can give all type of results, choose the lesser evil.
When doing such analysis, keep emotions out of the window and work on real and hard facts.
Do let me know your experiences on this front, would be an great discussion over coffee !!!
In today’s rapidly evolving business landscape with many disruptions, new technology changes, digitization’s, certifications, Customers becoming more demanding and , agility has become paramount for organizations seeking success.
As Agile frameworks continue to gain momentum, the role of a Business Analyst (BA) is also transforming. Many Business Analyst aspire to take on more strategic responsibilities and broaden their impact within the organization, many of them would like to be associated with Agile teams, but business analyst is not even a role as recognized by Agile world.
One such transition that often comes to mind is moving from a Business Analyst to a Product Owner (it seems a natural movement). Is it so simple to migrate to the new role in new ways of working?, If you are as confused as I was a few days ago, then continue to read and explore the thoughts that I have jotted down here.
In this blog, we will explore how a Business Analyst can upgrade / migrate to become a Product Owner in an Agile environment.
Before we delve into the transition process, it is essential to understand the key distinctions between a Business Analyst and a Product Owner. While both roles involve collaborating with stakeholders, their focus and scope vary.
A Business Analyst primarily acts as a bridge between business stakeholders and development teams. They gather and analyze requirements, identify business needs, and ensure alignment between stakeholders and the project team. BAs are skilled in eliciting, documenting, and managing requirements throughout the project lifecycle.
On the other hand, a Product Owner is a critical role within Agile frameworks such as Scrum. They represent the voice of the customer and are responsible for maximizing the value delivered by the team. Product Owners prioritize the backlog, work with the team and the stakeholders (including but not limited to End users) to define user stories, and ensure the team understands the product vision.
To transition from a Business Analyst to a Product Owner, it’s important to identify and address the skill gaps. While BAs possess valuable skills, they need to acquire additional competencies related to product management and Agile ways of working.
Product Management: Business Analyst should develop a deep understanding of product strategy, market analysis, user research, and product lifecycle management. They need to think strategically, define product vision, and make informed decisions to maximize product value. You need to master more tricks in the game to learn how to negotiate, prioritize and formulate the product backlog.
Agile Frameworks: BAs should familiarize themselves with Agile principles and frameworks such as Scrum, Kanban, and others. They must understand the iterative nature of Agile, embrace adaptive planning, and learn to collaborate effectively within cross-functional teams and not worry about ever evolving requirements, but learn how to manage the stakeholders, keep expectation management in scope and manage the risk of not meeting the commitments.
Stakeholder Management: As a Product Owner, relationship management becomes vital. Developing skills in stakeholder engagement, negotiation, and conflict resolution will enable smooth communication and alignment with stakeholders throughout the product development journey. Product owner needs to be decision maker. Understand the different stances of the product owner and know when to en-act which stand with stakeholders at the different durations and time intervals with the stakeholders / customers.
To upgrade to a Product Owner, Business Analysts should actively seek opportunities to acquire the knowledge and skills necessary for the role. Here are a few practical steps to consider:
Self-Study: Read books, articles, and blogs on Agile frameworks, product management, and the role of a Product Owner. Online platforms and communities offer a wealth of resources, webinars, and podcasts that can aid in self-learning, Participate in webinars, meetups, conferences, online sessions, review and listen to podcast – there is tons of data and information available in the industry – know the right source and the right place to acquire the available information. Again, a word of caution – do not read everything – follow some known Guru’s and experts from the market to get the right guidance.
Collaboration and Mentorship: Engage with experienced Product Owners, Agile practitioners, and industry professionals. Seek opportunities to shadow and collaborate with them, learning from their experiences and gaining practical insights. Try and seek a 1:1 session, exchange your queries and doubts, create situations and scenarios to gain insights into the thinking pattern of these experts – a lot of data to consume, filter the information for the right reasons.
On-the-Job Experience: Look for opportunities to take on Product Owner responsibilities within your current organization or in side projects. Start by actively participating in backlog refinement sessions, sprint planning, and user story development, at times participate (with permission) to only observe and see the whole flow getting worked out. – You may not be associated with the project, but by participating, observing one would gain tremendous thought process, which again should be harnessed by self-study and mentoring approaches
Training and Certification: Consider attending workshops, seminars, and certification programs that focus on Agile frameworks and product management. Certifications such as Certified Scrum Product Owner (CSPO) or Professional Scrum Product Owner (PSPO) can help validate your knowledge and enhance your marketability. Test your skills and knowledge via external validations, which can be easily done with different certifications from the industry, when you choose a training or workshop, evaluate the trainer, seek past feedback and references, do not evaluate over the cost.
Final element of this game should be to practice what we have gained, learnt or mastered, Transitioning to a Product Owner role requires effectively showcasing the skills and experiences gained as a Business Analyst. Highlighting these transferable skills will help demonstrate your readiness for the new role:
Requirement Analysis: As a BA, you have honed your ability to understand complex business processes and translate them into functional requirements. This analytical and problem-solving skill set is highly valuable for prioritizing features and defining user stories, Learn techniques such as Cost of Delay (CoD), MoSCoW, Force Field Analysis, Buy a Feature approach – these techniques would enable better management of the product backlog and meeting the needs and requirements of your customer.
Domain Knowledge: BAs often gain industry-specific knowledge through their projects. This domain expertise can be invaluable in understanding user needs, identifying market trends, and making informed product decisions. Understand the working of the industry, if the industry as you are associated with, is regulated, then learn about the issues, impact of decisions by the statutorily bodies on your product and services and how the requirements would evolve in the given situation and context.
Stakeholder Collaboration: BAs frequently interact with stakeholders, ensuring their needs are met throughout the project lifecycle. This experience in gathering and managing requirements and facilitating communication can be leveraged in the Product Owner role, this is no different for the Product Owner role, but learn to play the different stances of the product owner at different time to create the necessary impact on the product, its evolution.
Communication and Documentation: Business Analysts excel at clear and concise communication, as well as documenting requirements and user stories. These skills translate seamlessly into effective communication with development teams, stakeholders, and user groups as a Product Owner, Learn to communicate with minimum documentation, embrace the Agile manifesto and its principles – Interact with teams and stakeholders, have informal coffee chats. Get engaged with the people whom you work with or people who work with you.
Before you take the final call, be aware of these Anti Patterns when you move from Business Analyst role to a Product Owner one
Difficulty in prioritization: BAs often deal with multiple projects and requirements simultaneously, which can lead to difficulties in prioritizing features effectively. As a Product Owner, having a clear understanding of the product vision & strategy and the ability to prioritize based on user value, business impact, and market needs is crucial. Failure to prioritize effectively may result in a product that lacks focus or fails to deliver the most important features first. Remember Product Owner is a decision making role.
Lack of ownership and accountability: BAs typically operate within a structured framework and may not be accustomed to taking full ownership and accountability for the product’s success. As a PO, it is essential to take responsibility for the product, make tough decisions, and drive its overall direction. Without a strong sense of ownership, the product may suffer from indecisiveness or lack of direction. Remember in Nutshell PO = CEO of the product
Insufficient collaboration with development teams: BAs are accustomed to working as intermediaries between stakeholders and development teams. However, as a PO, close collaboration with the development team is crucial. Failing to actively engage and communicate with the team can lead to misunderstandings, delays, and suboptimal outcomes. The PO should work closely with the team, provide clarifications, prioritize features, and ensure the team’s understanding of the product vision. Note that the Agile teams work in clear autonomy approach, give them the product needs and requirements and allow them to function in a manner where in their creativity can emerge and provide the right value for the customer.
Requirement-driven approach: BAs often have a strong background in gathering and documenting requirements. However, it is essential for a PO to adopt a more holistic and strategic mindset, considering the overall product vision, market dynamics, user needs, and business goals. Look beyond the obvious and there is a wealth of information on needs and wants of the customer there to be address and resolved.
Lack of user-centricity: BAs sometimes prioritize the needs and wants of stakeholders over those of end-users. This can result in a product that doesn’t effectively address user pain points or deliver value to the target audience. A successful PO should place a strong emphasis on understanding user needs, conducting user research, and ensuring the product meets user expectations, use approaches such as “Gemba” or “HMW – How Might We”. Use thoughts and elements from Liberating Structures.
Resistance to change and agility: BAs typically operate within defined processes and methodologies. However, a successful PO needs to be adaptable, open to change, and embrace an agile mindset. Resistance to change can hinder the ability to respond quickly to market shifts, adapt to feedback, and make necessary adjustments to the product strategy. At times the product as developed could be required to be changed once the requirements are developed, this is an iterative approach, we work and act as we learn more about the users, their issues, pain points, technology capabilities and so on. Agility is all about responding to change.
It’s important to recognize these anti-patterns and address them proactively. By understanding the challenges that may arise, BAs transitioning into the role of a PO can develop the necessary skills, mindset, and behaviors to be effective in their new position. Continuous learning, collaboration, and a focus on user value are key to overcoming these anti-patterns and succeeding as a Product Owner
Last few words of Wisdom:
Transitioning from a Business Analyst to a Product Owner is an exciting journey for professionals seeking to expand their impact in an Agile environment. By identifying skill gaps, acquiring relevant knowledge, and showcasing transferable skills, BAs can successfully upgrade their role. Embracing continuous learning, collaborating with experienced practitioners, and gaining practical experience will empower Business Analysts to become effective Product Owners who drive value and contribute to the success of Agile team. Remember one key element – Product Owner is the Value Maximizer in the game.
The demand for Scrum Masters to also have project management skills can be attributed to several factors and trends in the industry. While it is not a universal requirement, some organizations may prefer or require their Scrum Masters to possess project management capabilities. Here are a few reasons as per me to why this demand is existing in the market?
Overlapping responsibilities: Scrum Masters and project managers share certain responsibilities, such as facilitating communication, removing obstacles, and ensuring the smooth progress of product development or execution of the projects. By combining both roles, organizations can streamline their processes and avoid duplication of efforts.
Hybrid approaches: Many organizations adopt a hybrid approach to project management, combining agile methodologies like Scrum with traditional project management practices. In such cases, having a Scrum Master who is also familiar with project management can be advantageous, as they can bridge the gap between the two approaches and facilitate effective collaboration (question: Are the organizations getting the monies worth by doing this approach – would love to see a few case studies and experience sharing from others)
Project coordination: In larger organizations or complex projects involving multiple teams, a Scrum Master with project management skills can help coordinate and align the efforts of different teams or departments. They can ensure that the work being done by various Scrum teams is in sync and aligned with the overall project objectives (but is this not the pure role of a Scrum Master – Have we ever given a thought and management / leadership understand the pure meaning of the role called – Scrum Master)
Stakeholder management: Project managers often deal with various stakeholders, including clients, executives, and team members. Having a Scrum Master with project management skills can enhance their ability to manage stakeholders effectively, ensuring clear communication, managing expectations, and resolving conflicts (but again here we had Product Owner to deal with the stakeholders and manage their expectations, for resolving conflicts within the team – Scrum Master can handle the job)
Career progression: For individuals working in agile environments, gaining project management skills can offer opportunities for career advancement. By acquiring a broader skill set, Scrum Masters can expand their roles and take on project management responsibilities, leading to increased career prospects within the organization (but when the world is moving towards Agile and Agile adoption is increasing by the day – Not sure if any Scrum Master would care to become a career project manager – any takers?)
It is worth noting that while the demand exists to have a combo offer of Scrum Master Cum Project Manager, not all organizations require Scrum Masters to be project managers. The specific requirements may vary depending on the organization’s structure, size, and project management approach. Agile methodologies like Scrum prioritize flexibility and adaptability, so organizations may choose to have separate roles for Scrum Masters and project managers, depending on their specific needs and preferences.
Have we ever heard that Organizations are looking for Project Manager Cum Scrum Master? You would say Yes ….if you notice industry is looking for Scrum Master Cum Project Manager – Mind you there is a see change of difference between the two demands that the market is looking out for.
When such demands are placed, It gives me a lot more food for thought … in terms if the organization really wants to adopt Agile and do the implementation or it is just a new card that the leadership wants to use in the organization.
Has the management thought on these lines:
Conflicting priorities: Scrum Masters and Project Managers often have different priorities and approaches. Scrum Masters focus on facilitating the agile process, promoting self-organization, and removing impediments for the development team. Project Managers, on the other hand, may prioritize adherence to schedules, budgets, and overall project objectives. Balancing these potentially conflicting priorities can be challenging – It is like Chalk and Cheese, we mixing two elements together – Are we aware of the reactions and impact it would have on the moral of the person and the approach of agile adoption.
Time management: Both roles require significant time and effort to fulfill their responsibilities effectively. Juggling the tasks of a Scrum Master, such as organizing and facilitating ceremonies, coaching the team, and ensuring adherence to agile principles, along with the project management responsibilities like planning, tracking progress, and managing stakeholders, can be demanding and time-consuming (when a SM acts like a PM then the whole concept of Self-Organizing, Self-Managed goes out of the window, there is no concept of team autonomy – Time management for me would be a secondary thought)
Role clarity and expectations: Combining the roles of a Scrum Master and a Project Manager can lead to ambiguity in responsibilities and expectations. Team members may become uncertain about whom to approach for specific issues, and there could be confusion about the boundaries of each role. It is crucial to establish clear expectations and communicate them effectively to avoid role confusion. More than the team, I believe it would utter confusion for the person to play dual role – This is also an indication that Leadership of the organization does not even understand the concept of Agile and have little or no clue on how the work of a Scrum Master is performed. For them we all are just resources available to get some job done.
Skill set requirements: Being an effective Scrum Master and also a Project Manager requires a diverse skill set. Scrum Masters need expertise in agile methodologies, facilitation, coaching, and team dynamics. Project Managers require skills in project planning, risk management, budgeting, and stakeholder management. Finding individuals who excel in both areas can be challenging, as the skill sets required for each role may not overlap entirely. This is an interesting problem to have … if this logic can be applied for Scrum Master and Project Managers … then the same logic should be applied for all roles in the organization, like COO and CFO could be same or COO and CIO could be the same individuals and similar more. I hope the management wakes up and smells the coffee.
Potential burnout: Taking on the responsibilities of both a Scrum Master and a Project Manager can lead to increased workload and potential burnout. Both roles can be demanding individually and combining them may intensify the pressure. It is important to manage workload effectively, delegate tasks when possible, and prioritize self-care to prevent burnout. – Now the important question that I would have is where the HR policies of “Work Life Balance”, are these concept confined to the policies and to be used when recruiting people, later they have little or no meaning
Conflict of interest: Scrum Masters are advocates for the team, ensuring that they have the autonomy and support needed to deliver value. Project Managers, on the other hand, may have obligations to meet specific project objectives, timelines, and stakeholder expectations. Balancing these sometimes conflicting interests can be challenging and may require careful negotiation and communication. Meeting the timelines should be everyone’s job in the project or organization, At times we do not right resources (meaning skills), tools are missing, dependencies do not respond, client behaves abnormally, team members at times are moved across projects, no proper or adequate KT is done for the new joiners to the team – and with all these challenges, one expects ON TIME Delivery !!!
With my hand folded, I request leadership and decision makers across the globe to carefully consider these challenges and assess whether combining the roles of a Scrum Master and a Project Manager aligns with their specific needs and context. It is important to ensure that individuals in these dual roles receive the necessary support, training, and resources to succeed in fulfilling their responsibilities effectively. In a better world – one would not combine these two roles.
A small query – How many of us on a daily basis would combine / mix our tea and coffee together and enjoy the same – Any takers – On a daily basis (not experiment)?
This article is based and drawn on my Scrum Master, Product Owner, and Agile Coach experiences over a period of many years across different domains and industries and not to forget the geographies that I have worked in.
Beyond my fundamental training on Scrum and Agile, I had the privilege of working with and learning from highly competent, ethical professionals who had provided me ample opportunities to learn, make mistakes, and re-apply my learnings. People with whom I have been associated have practiced “Fail Fast” and showed me directions on how to prepare for the future. They have guided me to deal with stakeholders who need to be managed at a different level (as each of them was a different personality – No One size that fits all)
Everyone wants to succeed, but regardless of many forms of success, one must also be successful in dealing with others.
While there are many attributes that contribute to the growth and behavior of an individual, I have listed down what worked for me and helped me in my agile coaching journey.
Positive personal effectiveness is achieved when we can ethically win confidence, respect, and cooperation in our dealings with others (they could be your Seniors or Juniors).
Scrum Master’s job is to work with others; they cannot delegate this nor can they avoid the required interaction. For Scrum Masters to be successful, they should practice the below mentioned nine people skills for ‘Self-Improvement and Effectiveness’.
Personal Ethics
Adaptability
Tact
Creditability
Intercommunication
Persuasiveness
Objectivity
Initiative
Self-Discipline
From the above one would spot over-lapping approaches across many skills like Intercommunication and Persuasiveness vs. Tact.
Personal Ethics
It is thefirst people related skill that any individual should develop, and it applies to a Scrum Master also. It is basic to establish and maintain a high standard of excellence in the practice, life and behavior. Good character, stemming from good ethics, is a quality of leadership and it distinguishes any leader from others. It inspires well-founded and reciprocal confidence and trust of others in you.
I learnt in my career that the best and most successful people at the top (like Ratan Tata) were those who displayed and practiced personal ethics and took personal responsibilities toward their own people, project, organizations, employees, and society at large.
Consistent reliance on personal ethics should be our guiding principle in our personal encounters, which would inspire others to follow the same pattern and principles.
This should be the default element of any Scrum Master and bare minimum traits to have. There cannot be any compromise on this front.
Adaptability
Not everything would always go as per plan. It is important for us to be adaptable, especially in our project environment, where requirements can change, scope gets impacted, estimates go for a toss, – and the delivery of the MVP is at risk. This is the place where adaptability as a people skill would help us bring harmony to our attitudes and actions in our dealings with the situation and economic environment.
The required degree of adaptability varies with the situation, at times it would be temporary or minor in nature and at others, it would cause a major impact in our dealings and thought processes.
Experience has taught me that however crucial the circumstances may be, adaptability with a cool and collected mindset helps in managing the situation better.
The product owner could be putting pressure on the team, teams may have internal conflicts and challenges to deal with, or the market situation may not be as per our needs or plans. To deal with all these situations, adaptability is required. There is no substitute for the same.
Every project would demand a certain amount of adaptability, as its needs and goals would be different than your prior experiences. As a scrum master one would play multiple roles in a day-to-day affair of the product development. Depending on the need, one would act as a wise counselor or demonstrate as an inspiring mentor or display compassion. Scrum Master should know that change is inevitable and would have an overarching impact. A Scrum Master who can adapt to these changing situations would be able to survive and thrive in the business.
Tact
Scrum Master needs to master the art of tact in dealing with the team, PO and stakeholders including the leadership and show genuine concern for their situation and feelings. Tact as an approach cannot work alone, it has to be used with other personal effectiveness traits and people skills.
Lacking tact can be a costly impediment to personal effectiveness. How can we avoid conflict with someone who takes a totally arbitrary posture of disagreement? Now look at these 2 statements –
“Please tell me a little more about how you came to this conclusion.”
“I don’t agree with you.”
The first one might prevent antagonism, but the latter one would more likely cause it.
This is what we call tact – an important parameter in our approach to dealing with people. Self-control under pressure is a powerful tool of discretion. Lacking tact as a skill could be a costly impediment to personal effectiveness. A practical guide to improving your handling of situations with “tact” should consider these three elements:
Perception
Discretion
Empathy
Tact is more about mutual respect for other parties involved in the situation or discussions.
Credibility
Credibility is an essential attribute that is built upon elements of Trust, Integrity, Reliability, and Commitments. Credibility lends its power to personal effectiveness as it helps you earn the genuine respect, trust, and confidence of others.
Imagine a Scrum Master with credibility issues. Will they be able to lead the team, or will the team respect such a person?
Commitment and promises are a necessity in every part and type of job that we do. Breach of these would have issues on credibility of the person, whether it is in the society, organization, project, or family. A person’s past performance creates a track record which builds up credibility.
Intercommunications
Intercommunication is a synthesizer to all the other elements as discussed in this article. Intercommunication capabilities create the power to use all the skills more effectively. A good communicator conveys messages, ideas, thoughts, suggestions, and intentions clearly and concisely, while displaying the reciprocal interactions – listening, hearing, and evaluating the comments and feelings of others. This is a common element of Scrum Master’s daily job.
The effectiveness of Scrum Master’s communication is always reflected in the responses they receive, whether in action or attitude or words. These responses are an excellent ongoing opportunity for evaluating the style of our communication. If the Scrum team’s performance matters, it needs to have excellent communication from Scrum Master. Scrum is a high-intensity team sport. Good communication is one of the essential elements to build a robust Scrum team. Lack of communication or poor communication will invariably cause your Scrum team to fall apart.
Signs of poor communication
Here are the most common indicators of improper communication that you as a Scrum Master should be careful about:
Using a monologue over a dialogue
Disregarding the feelings of others
Being subjective/vague
Resisting feedback
Lack of shared language of communication
Persuasiveness
It is an art of gaining approval, acceptance or agreement when presenting your thoughts, ideas, plans, suggestions, and opinions to others.
It is one of the most valuable skills for the scrum master to have, as it leads to gaining cooperation, and a greater success in our dealing with the situations and people.
Quite often, traditional managers can be very autocratic when they delegate their authority. Scrum supports empowerment. Self-analyzing and self-organizing teams decide the best course of action. At times, it becomes necessary to advise the team to follow the Scrum process or carry out a particular activity. Generally, the teams respond positively by listening to the scrum master and engaging with the task. However, if the team fails to respond in time, or fails to respond positively, it may be required to engage with the team so it can comply. This is where the attitude comes in – the Scrum Master can either instruct the team or discuss the issue and persuade the team to respond positively.
An autocratic attitude is frowned upon by the team, and at an individual level, it may become difficult to avail the team member’s cooperation. The servant-leader role suggests that a scrum master should refrain from delegating his or her authority. Instead, the person should persuade the team member to cooperate.
Persuasiveness forms an integral part of well-defined communication. It is derived from competence, convictions, and ethically driven behavior.
Objectivity
Being objective helps to evaluate the situation, data, information which would be un-influenced by emotions, beliefs, or any personal preference. For a Scrum Master maintaining objectivity – an unbiased perspective when dealing with others and doing so fairly – is vital to achieving personal effectiveness. Objectivity is closely linked to credibility.
For objectivity to survive, an open mind is required, or should I say, it is the bare minimum requirement. An open mind would allow the Scrum Master to have the freedom to evaluate possible choices. A closed mind would rob us of these advantages.
Scrum Masters should be careful about objectivity as per social science research. This is difficult and arises out of the adverse influences of the following:
Personal prejudices and bias
Value judgement
Ethical dilemma
Complexity of social phenomena
A clear objective of Scrum Master should be to focus on the development and dissemination of knowledge and skills which are required to exploit the potential of the latest technologies and have collaborative design and working environment.
Initiative
This is an approach or a skill, where the Scrum Master converts an idea into action. The focus is to find if the idea would work, and whether we should pivot or throw away the thought.
A good product is well-crafted when engineering practices are in place with good effect. Scrum Master should arrange workshops on coding guidelines, designs, tools, and different engineering practices. Arrange a workshop for the team members where you can discuss or try a new tool, current architecture, latest technology, build-process, and do much more. This can be implemented by reserving time for the workshop and organizing an arbitrator who can be from the team.
Never have a laid-back attitude with your team or product, or when dealing with the stakeholders. Play on your front foot and move forward.
Self-Discipline
It is the ability to control one’s impulses, emotions, desires, and behavior. Agile transformation is all about self-disciplined team members. When we find discipline is missing, we do not get the value flow from the team to the end users. Self-discipline is important because it gives the Scrum Master the opportunity to excel in their professional life. It helps establish a set work routine and holds one accountable for the goals by pushing them to pursue advanced job opportunities.
Self-control is discipline in the face of pressure from an immediate urge, desire, or compulsion. It relates to delaying immediate gratification of the senses. Its struggle is the conflict between intellectual knowing and emotional desiring. It is the choice between physical and psychological satisfaction now vs. the hope or expectation of something better later.
A Scrum Master is required and expected that they would maintain a high degree of self-control and discipline.
Because self-discipline is a learned behavior, Scrum Master should make the choice to develop it. It’s important to set clear goals and have a solid plan for how they’ll achieve them. Knowing where we’re headed makes it easier to stay focused and avoid distractions. Here are a few steps you can follow to become self-disciplined:
Know your current situation
Define your expectations and set goals for yourself
Push yourself to meet your goals
Measure your progress
Learn from the situation
Reward yourself when you accomplish it
Identify your areas of improvement
Repeat the cycle – have a defined frequency
Remember there is no magic – it is all about you, your behavior and ability to handle complex, difficult situations, when the career and aspirations of people are involved. It is a delicate balance and Scrum Master needs to walk the tight rope.
Always inspect and adapt. Be the servant leader that Agile expects you to be.
People engagement is a minimum expectation for any team, product, project, and organization. It is a never-ending journey, yet many projects or organizations go awry and lose the required focus. Many organizations fail to embark on that journey. As a result, they’re setting their people (and their bottom lines) up for failure.
Why is people engagement crucial? How do you measure it? Improvements can only come when you know what needs to be done and why, along with the relevant impact or desired change.
What is People engagement?
Many Scrum Masters recognize that engaging the team members plays a critical role in Agile success. But far fewer can define engagement and why it’s so important. What is the so-called engagement? What is the role of Scrum Master in this front?
Team Member engagement is the measure of how motivated a person is within their job, team, and organization. When someone is highly engaged, it means they’re invested in their work, energized by their peers, and committed to their product and/or company’s long-term mission and vision.
Put simply, engagement measures an employee’s level of satisfaction at a given point in the employment lifecycle. The higher the level of engagement, the greater the likelihood that the person is enjoying a positive experience. By engaging your hard-working folks and low-performers alike, you ensure your people can come to work energized—and deliver their best.
Why is an engaged Scrum Team important?
Flip this question on its head: What happens when your team or a few members of the team are not engaged?
When team members feel disconnected their work begins to suffer which ultimately impacts the product / increment delivery. Team member is less likely to go the extra mile for their others and is going to do the bare minimum to stay afloat in their role. And when they decide their organization can no longer support their growth (professionally, monetarily, or otherwise), they’ll leave for a company that can.
Now imagine that effect multiplied across an entire workforce, and the dangers of disengagement become amply clear.
An engaged Scrum Team is critical to productivity—and, by that definition, it would impact your profitability and customers (directly).
We do not even count the losses that we have made by hiring the wrong person or backfilling the position. If we start to calculate the amount of time, effort, and energy that is wasted, more so from the management level, our growth in terms of EBITA would be going north. But, alas, it is considered an element of doing business. No doubt that people would leave, but by retaining them for a longer duration, you are increasing your margins, as well as customer satisfaction.
Improvements to the employee experience can also carry over to the customer experience. If you’re taking steps to improve employee satisfaction, chances are your customer satisfaction ratings will get a boost, too.
Habits of engaged employees and companies.
Engaged team members would have some habits you simply won’t find in other employees. They show up to work with energy and often a genuine smile. They go the extra mile in their role—by working late occasionally or offering to help employees with too much on their plate. Above all else, they’re excellent teammates who contribute to a healthy team dynamic.
Benefits of engaged team members.
When a team member is engaged, that inner fire tends to spread. Others feel the energy. They spend more discretionary effort and aspire to be better team players. Given are a few of the many benefits of engagement:
Higher productivity
Greater profitability
Lower employee turnover
Fewer safety incidents
Stronger customer loyalty
Lower employee absenteeism
Consider this list of benefits, and the takeaway is clear: Employee engagement can transform your business.
Make no mistake: A ping-pong table and office snacks aren’t enough to entice today’s talent. More than ever, people want a fail-safe environment—one where they can be their authentic selves, and work in a way that’s both stimulating and sustainable.
The different levels of engagement
You may know an employee is highly disengaged, but unless you know what is driving disengagement, how are you supposed to take action?
There are four drivers of employee engagement:
Job fit: Alignment between an employee’s responsibilities and their natural tendencies and career aspirations
Manager fit: The relationship between the employee and their manager.
Team fit: Chemistry with teammates, and overall team cohesion
Organizational fit: connection to senior leadership and the company culture
When a team member achieves fitment across all four factors of engagement, they’re more likely to be engaged overall. By contrast, when one or more factors are lacking—a person doesn’t gel with their team, the culture, etc.—they’re more likely to become disengaged over time.
One size doesn’t fit all when it comes to engagement. Job satisfaction may look wildly different to one team member as compared to another—it all depends on each person’s natural behavioral drives. By understanding how to motivate your scrum team members based on their unique needs, Scrum Master can ensure that they are taking an active approach to prevent disengagement and improving the experience.
Don’t try to boil the ocean. When in doubt, look for ways—even if seemingly small—to improve one or more of the four drivers of engagement.
Here are some examples of ways to improve engagement:
Have regular career pathing discussions with your team members.
Build awareness as a Scrum Master and address relationship gaps.
Encourage a healthy work-life balance (and lead by example).
Build trust by leading remote-friendly team-building activities.
Recognize your Scrum Team Members for a job well done, or when a Sprint has gone well (more so publicly than privately).
Write personalized “thank you” cards for your team members.
Embrace hybrid work by allowing people to choose where they work (as long as the work is getting done, the goals and objectives are achieved of the product/sprint).
Once the Scrum Master discovers effective employee engagement best practices, it’s time to think about the bigger picture with the strategy. Scrum Master should take a proactive approach by surveying the team members about their experiences with the project/organization. Identify the biggest opportunity areas, so one can swiftly act on their feedback.
Investing in and measuring engagement
Investing in engagement today can pay dividends in the long term—but only if you know how to measure your progress.
Collecting employee feedback has always been important, but now it’s mission critical. Organizations live in a post-COVID world—one dominated by discussions about mental health, social equity, and personal freedom. Throw economic uncertainty into the mix, and you could make a strong argument that employee engagement is in a recession of its own.
The impact of managers and leadership on engagement
As a Scrum Master, you have an outsized impact on engagement. It’s incumbent that you don’t just listen to your people, but that you advocate and fight for them.
Taking action is a collaborative process. Give your people the forum to voice their opinions and propose ideas for change. Once you’ve agreed upon a plan of action, see to it that you follow through on that plan. Lead by example and encourage other leaders / Scrum Masters across the organization to follow suit.
The role of engaged employees in your hiring process.
Engagement doesn’t just make for a great employee experience—it makes for a great hiring experience, too.
One of the best ways to create a world-class onboarding experience is to involve existing employees, preferably high performers already in the role. Doing so can help accelerate a new hire’s training while providing invaluable mentors they can lean on in their first 30 days.
By having engaged team members, you ensure new hires are exposed to the very best your organization has to offer. By contrast, if you let disengaged team members run the show, you risk discouraging new talent before they even wrap up their first day.
Identifying disengaged employees at your workplace
A proactive approach to engagement isn’t without its flaws. Employees can still fall through the cracks and become disengaged.
Put simply, the four factors of engagement can double as “four forces of disengagement.”
You can probe for these negative forces with the right conversations. If you sense morale is low among a group of employees, bring it up privately during your next one-on-one meeting. Consider asking the following questions:
Are you enjoying your current role?
Do you feel supported by the team?
In what ways can I improve as a Scrum Master?
How do you feel about the state of the company?
Disengaged employees are never a lost cause. Equip yourself with effective tools—and a positive mindset—and you’ll ensure you’re setting up your people for success.
Look forward for your feedback and comments … your personal experience on this front, we all can share and learn from each other’s experience
A Gemba Walk is the practice of Product Owners, Product Managers, Business Analyst personally observe the place where work is being done. The original Japanese term comes from gembutsu, which means “real thing” or “real place.” Thus, the Gemba is wherever work happens, and value is added to products or services. The Gemba may be a production floor, an emergency room, a construction site, or a classroom.
During a Gemba Walk, PO’s / PM’s should physically go to the places where people are putting together products or using them, helping customers, analyzing data, maintaining machinery, or any other process. The philosophy behind Gemba Walks rests on the idea that it is easier to gather feedback, spot process or workspace issues, and build trust with the team by observing work firsthand. Employees tend to be more open to pointing out opportunities for improvement or sharing concerns when they are in their own workplace.
PO’s / PM’s who have committed to Gemba Walks typically spend about 60 minutes a week at the Gemba. They pay careful attention, ask questions, and observe processes, The idea is to catch on ground information and understand the nature of work getting performed
Some Tips on doing a GEMBA walk:
Define a clear focus – In terms of what is to be observed? Who is to be observed? What is the purpose and scope of my learning?
Communicate with the Team Before the Walk:You don’t want your client / end users to feel blindsided by a Gemba Walk – it isn’t a surprise inspection, rather it is a technique for collecting requirements, it is essential to describe the purpose of Gemba Walks and let the team know what to expect. Open communication in advance will help people feel more comfortable and foster engagement.
Pay Attention to the Handoffs: If you follow the value stream, you will likely find that all the stakeholders and output of that process along with the handoffs between processes, peoples, or departments. Those areas may yield the most potential for eliminating waste.
It’s not about just observation: The process of capturing the information / data is very important.
Separate Observations from Interpretation: Pay heed and attention to the methods of working, work around solutions as used, challenges faced, discussions between 2 people (do OSMOTIC communication – do not participate)
Pay attention to routines and details: Qualify how long a work takes (measure it), Quantitative analysis can be easily visualized with charts and graphs and more meaningful insights can be obtained.
Based on all of the above: Obtain new insights on how the problem is resolved today and how the process is lived in the real world
Do not fire or make judgement calls.
Follow Up: After your walk is over, be sure to follow-up with the teams, let them know what you learned and ask for additional input. It’s a good idea to close the loop so people aren’t left wondering about your impressions.
Gemba Walk Checklist
Every time when a PO / PM performs a Gemba walk, they will need to prepare a checklist in advance. This list will help them focus and target their efforts in right direction.
The checklist has to include questions that will help understand the process that they are going to observe in a better way. Questions may vary depending on the theme of your Gemba walk.
Here are some basic Gemba walk checklist questions:
Use Gemba walks a means to collect needs, observe the current behavior and work as performed, challenges, If possible speak to end users or doer’s of the process, understand their needs and viewpoints.
Perform this activity for multiple days and across different segments of people, this would enable you to focus on different situations and scenarios that may come up.
Several times in my career, I have heard many people / gurus say to use Empathy as a tool to better understand your customers and their needs, their behaviors’, their pains, and their future outlook. The idea is empathy would only provide the experience from the past and not give any new insights in the needs and requirements of the future.
A lot of us (including me) get confused, when we speak about Persona and Empathy … are they similar concepts, do they capture and provide similar information, how are they to be used, when are they to be used, what is the value proposition of using them, which one is a better approach?
This document of mine would try and shed some light on the Empathy part and hopefully in future we shall explore the depth of Persona also.
Empathy map is a tool for target audience analysis. It is used to identify feelings, thoughts and attitudes of existing or potential users / customers and understand their needs, The idea is to obtain in-depth insights on potential users by means of what, why and how questions. Empathy maps focus more on the emotional state of customers.
Let’s first focus on the usage and value that Empathy would provide:
It would help us better understand and appreciate insights from testing or observations with the users and capture different perspectives
Helps understand where the user has problems or potential benefits
Helps to collect findings to build Persona
Empathy map as a tool should be used in conjunction with other tools like Customer Journey mapping, Persona / User Profiling and Value proposition canvas
When doing Empathy mapping with the customer, ensure that we have 2 people, one person documents and records the information while the other would-be posing questions. Typically, this should max 30-45 mins of session
Use a template for Empathy map where you record everything about the customer such as:
Think & feel
Hear
See
Say & Do
Pains
Gains
Use questions such as:
Where is the customer? What do they see?
Who influences them, with whom do they interact / communicate?
What emotions are driving the customer
What does it say about their attitude?
Where does the customer behave in a contractionary manner?
What are their biggest challenges / pain areas?
What are the opportunities and benefits they may have?
While doing this exercise, focus on human values – like thoughts, opinions, feelings, emotions (at times these may not be directly available, you have may to infer based on their body language, tone, word selection).
Pay special attention to contradictions, often we can identify something new from what the customer says and the way they behave.
Using this data, analysis all the edge cases, dig into unique behaviors and identify what are we building … why are we building, will it serve the purpose?
Empathy mapping is a unique tool that a Product Owner or a Business Analyst should have in their armory to better serve and engage the End User community, better your tools, product and services are aligned to the end user … higher is the potential for your products to dominate the market.
Agile and its variants / frameworks like Scrum, Kanban’s has been around us for more than 2 decades now, but very few organizations have been able to apply and reap the benefits of the same to the degree of investments made by each organization.
We want to be Agile, but do not want to embrace the value and eco system of Agile, I see a lot of organizations wanting to do Spotify ways of doing things, they have gone ahead and labeled their teams as Squads, Tribes and Chapters … but has anything changed, has the approach changed? Or the culture undergone a transformation? Has labelling teams made them adopt the Spotify ways of working …. I do not believe so.
Any change needs to be driven, its needs to anchored, its needs support and needs to be groomed for survival. It needs time, patience and attention from the Leadership or the sponsors who are putting the hard dollars ($$$) on the table, but alas dollars ($$$) are available, but the sponsors or the leadership team is missing from action.
Why is it so difficult to follow in practice 14 pages of PDF called Scrum Guide? Have we understood the intent of the document? Or it was just a new buzz word or a new kid on the block?
Historically if we see we had 7S theory, Lean, ISO, CMMI, Six Sigma’s and many more … where they now, if organizations have used them, have they got tangible cum measurable benefits? Why would an organization adopt ISO and CMMI and also Six Sigma (either together or one after other) … at the end of the day all speak the same language but with a slight difference, the end result is supposed to the same, the outcome needs to be the same. Why would any organization need improvement approaches using different models and methods, well the harsh truth is that we never implemented the initial one in the true spirit, therefore news ones would be required.
I would like to present an analogy over here … Each day when I get out of my bed, I would brush my teeth (well – Let’s say I use Colgate as a toothpaste), once done and dusted with Colgate, would I use Close-Up as new toothpaste for doing the same job, well my response would be a BIG “NO”, why No … Well, if I have done my job clearly and well with Colgate / 1st option, I should not be needing the second option.
Over a period of years based on my experience, I am jotting down a few elements to be implemented or practiced to gain the true value of using Agile as a framework for developing solutions and products.
As mentioned in of my earlier post, we need a beginner’s mindset and attitude to be succeeding in Agile. Beyond this a few more elements as food for thought:
Start with understanding the problem statement:
Whenever we develop any product, solutions, or any output, it is critical to understand the user base, end user behavior, their needs, their requirements, their current pain areas, problem statements. By doing this we as a Scrum Team would start to understand the big picture of our purpose and create the right vision and objectives for development. In order for the team to create a solution, it needs to internalize the problem, understand the depth of the need, impact of the wrong solution or no solution.
Visualize how our developed solutions and products would change the working pattern or the social behaviors of the society and people who would use it or be impacted by it.
I would like to sound critical here … In real life our Product Owners directly jump to the explaining the user story … but the science behind the story is missing for the team, they are unable to see the vision and visualize the trances of their incremental solution on how it would lead to the potential solution.
Start with Human Beings
Remember our solutions would be used by real people, we need to start engaging and interacting with potential end users for understanding the needs, possibilities, experience, knowledge for creating a deeper understanding. End Users know their pains and gains of the system better than anybody else.
Interdisciplinary Teams
Collaboration is a key element of working on any project (irrespective of using Agile or not), Projects cannot be done by a single source or an entity, we would require collaboration of skills and talent to come together and ensure there is a healthy chemistry of working and all of us are working towards a common goal. Teams with varied skills and talent help in developing a creative process and continuous reflect on the same to see its feasibility of applicability
Our current challenge is that our teams are having different objectives, vision, goals and KRA. Each of us are focused on getting our KRA done to meet the performance appraisal objective. We are conveniently missing the client goals and objectives
Experiments and Prototypes
Only final product when used by the real end users would we know if our development has been successful or not, but to get intermediatory feedback, Scrum team should heavily depend upon experiments and prototypes, this is a quick way to get feedback and understand if our course of direction needs to change. Reviews should always be at 2 levels, one at the Product Owner level and other with the team that would be in touch with the end user community. Both the reviews should be looking at the holistic approach. One should always practice that “Less is More”. Emphasize that solutions have to be proven, ones that have got feedback should be actioned upon … Important – do not focus on only negative elements (actually there should be no negative element, it is more about a feedback).
Be mindful of the process
As in project, there would be some degree of process, that is either pre-defined or the scrum team would define it for itself. Process could be on how the Product Backlog Refinement would occur, Of Defining and agreeing on Definition of Ready/Done, What approach the team would adopt on Daily Standup / Scrum and so on … It could also lead into how conflicts have to be managed, how issues / impediment management would be taken care of.
The idea is to have simple and effective processes that would enable the team to work on a cruise control mode and deliver value
Accept Complexity
At times our solutions would be very complex even for a simple set of problem statement, we may have to integrate multiple 3rd party tools and products, that itself would raise a level of complexity, sometimes working in some cultures could have its own set of challenges, the stakeholder community is changing regularly, this puts additional burden on getting re-aligned with the ever-changing thought process and new stakeholders.
Co-Create and Grow with the concept of Co-Create
Agile is to solve problems, create new solutions, have happy customers. All this cannot be done in isolation, we need to engage multiple vendors, stakeholders, partners, business models, financial elements.
At times systems thinking along with Lean Start up approaches would be critical. Agile recommends collaboration with the stakeholders and the best approach would always be to co-create, It would help us pose right questions to the right people at the right time to get feedback and enable our journey to the next logical stop.
We need to regularly converge and diverge to reconverge back. This is a constant process and should be helping and assisting scrum team along with the decision makers.
All that is described above is nothing new, we all know it, we have read it, heard it, but are unable to put all of these elements in practice.
It takes 3 things to make Agile work in any organization …
Willingness of the Leadership to embrace agile (it cannot be just a lip service)
Attitude of the Scrum Team towards Agile
Aptitude of all involved stakeholders to respect the agile ways of working.
How many of us are willing to say that all 3 happen in our respective organization.
It is time that Leadership wakes up and smells the coffee … before its too late (remember they close the Check In Counters at the Airport 45 mins before the scheduled take off) … we being late would only impact us … as the flight has got its money and flown without you, with this analogy, Industry and Users would move forward and provide their dollars and business to your competitors, if you are not there.
For all those who have been to the gymnasium, let me present to you a concept, somewhat similar to catch 22 situations – of who chooses whom? Do you choose the gym and the personal trainer or the gym chooses you and allocates the trainer for you?
Will your gym trainer/coach refuse to train you on Day 1? Does the trainer say that you are not qualified to be his/her student? Or is it the other way around where you go and enroll in the gym and identify a trainer and figure out the way things work? If you are not happy with the coaching or advice you receive at the gym, are you allowed to change the trainer/coach or switch the gym? How does it work? I am sure, the customer always calls the shots. It is the service provider who is at the receiving end of the system and this I believe is the default rule in the game (whether it is right or wrong, it’s a matter of different debate for some other day.)
This leads me to think about the industry practices that have been nurtured over the period of years by pseudo Agilest and the so-called sponsors of the transformation game from traditional project management to Agile way of doing the job. Have we achieved success? Do expending millions of dollars justify? How do organizations measure ROI in their balance sheets? Nobody has a clue; the consulting organizations are making merry and laughing all the way to the bank.
Come to think about it, when I ponder on the reasons of failures. (Oh yes, Agile says “Fail Fast,” but not at the cost of losing millions down the drain.) One of the failure points could be the SCRUM MASTER (read the pun as SM is written in caps). Especially on how we appoint the Scrum Master.
How is the scrum master selected?
Who selects them?
Who should get involved in selecting the Scrum Master?
What consideration should be applied when identifying a Scrum Master for the role?
What characteristics & traits should one look for when selecting a Scrum Master?
Let’s explore how it is done today in our industry as compared to how should this happen?
Most of the times (9 out of 10), it would be the management who would appoint a person, whom they feel qualified for the job. However, the irony is that the Management would have little or no idea what that role entails. Experience has suggested that we find the job for the person rather than find the right person for the job.
At times, the selection process of appointing the Scrum Master has been dictated by the person who is on the bench and we are trying to find a project to make the person billable or the other approach as seen is to nominate a person close to the management.
In fact, according to Scrum co-founder Dr. Jeff Sutherland, great Scrum Masters can come from virtually any background or discipline (i.e., engineering, design, testing, product management, journalism, academia, social work, etc.), and their role is relatively simple:
Remove impediments
Guide the team in Scrum practices
Protect against outside interference
In a way, a Scrum Master closely resembles a personal gym trainer, where the trainer would not have any direct control over what you eat and how hard you work out. All they can do is inspire you through effective coaching, enablement and guidance, but the implementation of the same is in your hands.
Who should be or become the Scrum Master for your new team? Is it your current project manager, Tech Lead, or the functional manager? I would have to argue against the current industry practices and say, anyone but one of these above-mentioned roles.
During my past few interviews, I have discovered that potential candidates are highlighting achievements; such as managing and controlling more than 2-3 teams at the same time. This reminds me of something that happened a few months ago, wherein I was asked, how many teams should a Scrum Master handle? For 2 minutes it made me think, of my past experiences as Project leader / manager, where in one was managing (or should I say was accountable) for multiple projects and we did not do justice to the projects (any one of them). My response to the person was very diplomatic. I responded, “A good Scrum Master manages two teams whereas an Excellent Scrum Master manages one team”
Although, understandably, the management usually wants a standard answer for who they should select to be the Scrum Master in this new work approach called “Agile,” it is not a one-size-fits-all answer. And the reason is because it depends on the person, the team and the environment. There are multiple factors that would impact the selection of the person for the role. It cannot be a cookie cutter approach, which is pretty much standardized, even in the same organization across 2 teams, the selections could vary (and they should vary, if the circumstances vary)
I think it’s a good question to ask, “Who decides the Scrum Master?” We often see that it is the management who decides, but they make the decision without knowing what Scrum is and more importantly, how it works. If possible, take this crucial decision to the team to see what they think. There needs some prudence in this, certainly, but we should rather lean toward making this statement of empowerment and trust of the team from the very start of adopting Scrum.
We commonly see Project Managers being given the role of Scrum Master. What makes a great Project Manager may not make a great Scrum Master. Often, the management wants Project Managers who can “get things done.” They drive performance and push the team. They may even micro-manage for results and visibility by tracking every task, status, risk, change and deviation from the plan. Management loves this (or, more truthfully, love the results). On the other hand, I’ve also seen Project Managers who provide management what they want (helping get more productivity and more visibility to progress, issues and options) by serving, empowering and trusting the team. If you are currently a Project Manager, which type are you? Experience over the years have identified that about 50% of project managers are on each side of the coin.
The industry has seen experienced managers taking the Scrum Master role. This, more often than Project Managers, has negative consequences, only the consequences are not so obvious, but these can be corrected more often and more easily than I’ve seen with Project Managers.
Some managers, due to their company’s culture and expectations, carry the responsibility of getting results from their people (for the projects their people are on). For these managers, even if they wanted to embrace the trans-formative qualities of the Scrum Master, the company culture will push back, and most often win. For managers in these tough positions, one would rather see them find someone else to be the Scrum Master, and then the manager can focus more time and energy towards the bigger need of being a heat shield, organizational impediment remover and management mindset and organizational cultural change agent.
The problem is much larger than we imagine or can think of; many questions are unanswered and the answer that are correct or atleast deemed right, the industry does not want to embrace them:
So what traits do we expect a Scrum Master to have?
How do we select a Scrum Master?
What skills do we want a Scrum Master to have?
Look for these ideas and thoughts @ selection of Scrum Master:
A person who understands and can practice servant leadership and facilitation
Always in pursuit of continuous improvement
A relationship person and can create a certain degree of influence with team members and other stakeholders
You need a person who is Humble, Ego-less, Collaborative in nature, Knowledgeable on Scrum (should kind of Google of Scrum / Agile Practices)
Getting all of the traits in a single person could be a near to impossible task, in case we do see that happening, find from above items, which are your critical success factors and what are things that are type of MVP (Minimum Viable Personality) for the Scrum Master role in your organization.
agilescrumworld 