Scrum Master = People Oriented Master

One of the main task for any Scrum Master is to manage and motivate the development team (do not forget the Product Owner) to deliver the best-in-class output with outcome to the respective end-users / stakeholders. Pure Agile / Scrum processes will not achieve this, A Scrum Master above all else should be a people person.

During the life of the product development, Scrum Master would enable / facilitate creating a range of tangible deliverables that are critical to the meeting of DoD and release to the production. These would include Impediment board, risks, teaming agreement, cadence of sprint and so on… The funny part of the story is that when the product is delivered all the tangible outputs that we are speaking about would be of no use (atleast to the end-user community). They have little or no value outside the life of the product.

It is important for us to understand that Scrum is all about people, who help to create beautiful and meaningful outputs that serve the needs of the stakeholders and market in general.

The main task for the Scrum Master is to ensure that the development team can deliver and all blockages that occur in the journey of theirs are removed or assisted to be removed.

Over next few paragraphs, we shall de-mystify the needs and requirements on what and how a Scrum Master should enact the approach.

Step # 1 – Get the basics right – Right People, Right Skills, Right Tasks.

As a Scrum Master, help, guide and assist / facilitate the development team to get the right skilled people -with adequate dose of attitude and aptitude. Do not focus on technical skills, focus on learnability, ability to survive in a tough environment, how to respect, being open, have the right level of commitment to the team and others.

There would always be some gap between your needs / wants vs. what talent is available. Remember a perfect match may not be available, try to manage this as a risk and work towards mitigating the same. Try to always get a balanced set of capabilities and skills, do not fall in the trap of choosing all the folks that favor you or you like. Infact look for people who can work with others and create magic for your customers.

Also find a balance between internal and external resources, several times you may be forced by the Leadership to take an internal person (in order to save on cost) but evaluate the person as you would when you take any external resource and ensure it fits in your culture band that you are building in your team.

Step # 2 – Go for Quality rather than Quantity.

More resources may not always be the right approach, but the right resources is what matters. Life and experiences have always suggested that a small set of motivated people have delivered far more than a much larger group of able people. Be the master negotiator with the leadership or the resource allocating person to get the best talent for your team, you may have to act as a salesman to get the right quality in your team (Scrum does not talk about this … but it is critical)

Step # 3 – Clear Roles and Responsibilities.

For any team and individual – we all look for clarity of our roles and expectations, how shall we be judged. Yes, there are no defined / allocated roles in Scrum, but it does not hurt to have pseudo approaches for the initial few sprints and then educate the team to self-allocate, self-define how they want to work out. Scrum Master is like parenting job, initially we would be required to do babysitting, but the as team grows, becomes more mature , our role should be limited to guidance and coaching.

Step # 4 – Building the team

Do not take for granted that Team is automatically built – You need to invest your sweat equity into it.

There is no right or wrong way to build a team, different cultures, different set of people will bond in different lengths of time. To build the team with right values, try these elements:

• Ensure roles are clearly understood
• Ensure communication channels are open between you and the team and amongst the team
• Bring people together (More physically)
• Give people time to know each other
• Have the Product Owner address the team on the needs, vision, big picture, roadmap of the product in focus

Step # 5 – Focus on personal development of team members

It may not be the core objective of Scrum Master, but not focusing on the same would have adverse impact.

Face this task much earlier in the life cycle, ideally when people first get involved in the team, As a part of their initial induction have an understanding of their career needs and wants. The areas where they want to grow and contribute. If their expectations are out of line or un-reasonable, then put it straight on the record.

Help the Product Owner agree to have about 4-6 Hrs / Sprint (Assuming 2 weeks of Sprint cycle) to get it invested in growth, learning of new tools, more on the product development, team building, exploration of new ideas (like using Gen AI to help in the development) and so on … this is a bit of selling exercise with the PO and team (also!)

However, make sure that the training / workshops or getting people involved in specific things do not derail the product development, it should not deviate from the core objective with which the team was formed.

Step # 6 – Be aware of team dynamics and politics

When people work together, they develop their own style of communication. Working together, as a Scrum Master your ability to understand the team dynamics is going to become more critical and critical.

Note: There is no right or wrong team working style or responding to team dynamics. Team dynamics will never remain static, it changes over a period – and when the team matures or new team members join, old ones move on, this can help you rebalance the approach for the team.

Implement PI (Predictive Index Assessment) for everyone on your team. Identify their personalities and ensure you and others in the team understand how to deal with a given personality. This is no rocket science, but not knowing how to deal with a Collaborative vs. Strategists can cause unwarranted losses and damage to the morale of the team and thereby to the product.

Encourage openness and honesty – when these elements are in place, then the team would have few barriers to open communications.

Remember to lead by example if you do not want politics in the team, then do not politic yourself. You want to be trusted by the team.

Final note on this one – Team is more important than any individual, In Agile it is the team that would deliver and not an individual.

Step # 7 – Managing Part time resources 

At times, you may not get a fully dedicated person to work on your product development. You would have to work with Shared resources, when such a situation arises, ensure:

• To get fixed and measurable time from shared folks
• Make sure you have sufficient skills and talent and working hands, remember it is not the number of people in your team, but it is the amount time that these folks are ready to devote to you.
• Recommend your team to build a little slack and inefficiency in the approach (this acts like a risk mitigation strategy)
• Your approach to managing the time utilization (not saying to act like a project manager- but watch the game) would be critical to the success of the delivery

Step # 8 – Working with the Wider Organization 

Remember your team, the product’s existence is never in isolation. There is always a requirement with some other function, department to get your product out of door, it could be the marketing or the sales team or the travel team (to book your tickets, hotels) or some other platform team whose output would be critical for integration and working of your product.

There is always to a need to manage relationships with the wider organization, and it would vary depending on context and content of the product as developed, Therefore as Scrum Master is it important to guide and assist the team to manage these relationship internally in the system.

Providing adequate and timely notice to dependency would help them plan their side of the work and provide sufficient time allocation for your work.

Step # 9 – Have a sense of humor  

The ability to generate and enjoy humor is an extremely positive trait for a Scrum Master. Developing products / projects can at times be quite stressful – the ability to laugh and crack jokes (not on any individual) would help the team manage the stress.

If you are not natural at this … do not worry, just smile a lot. People love to see a smiling face, do not underestimate the power of a simple smile. A well-placed smile of yours can completely change the dynamics of the conversation, can lift an individual from a negative stance to a positive frame of mind.

These are a few ideas that has potentially given me the required results and mind you – it has always worked.

Try it – and then Inspect and Adapt.

Ego Management – Challenges to manage Project Deliverables and Goals / Objectives

Ego, as defined in psychological terms, represents an individual’s sense of self-importance and self-worth. In project management, ego manifests as a personal need for recognition, power, and control. While a certain level of self-confidence is essential for effective leadership, an unchecked ego can lead to conflicts, communication breakdowns, and hinder project progress.

While having a healthy level of confidence and self-assuredness is generally beneficial, an excessively inflated ego can be challenging to handle and can have a significant impact on our work life.

In the realm of project management, achieving success requires more than just technical expertise and organizational skills. The human factor plays a pivotal role, and one aspect that can significantly impact project outcomes is ego management. Ego, often associated with self-importance and pride, can become a stumbling block or a catalyst for collaboration and success in project management. Today in this blog / article, we shall explore the concept of ego management and its critical role in project management, highlighting strategies to nurture collaboration and enhance project outcomes.

The Role of Ego Management in Project Success: Effective ego management fosters an environment where individuals can collaborate, share ideas, and work together towards a common goal. By minimizing egotistical behaviors, project managers can create a culture of trust, open communication, and innovation. Ego management is particularly crucial in project teams that comprise diverse individuals with unique perspectives, experiences, and expertise. When ego is managed effectively, it paves the way for improved decision-making, conflict resolution, and overall project success.

Based on past experiences of managing and participating projects, I have observed others, my bosses, leadership, Project managers on how they managed Ego to ensure their project success … I am listing based on my bets memory recall a few of those approaches:

Strategies for Ego Management in Project Management

1. Establish Clear Roles and Responsibilities: Clearly defining roles, responsibilities, and expectations helps minimize power struggles and conflicts arising from ego-related issues. When everyone understands their contributions and how they fit into the project’s overall objectives, it reduces the chances of ego-driven conflicts.

2. Foster a Positive Team Culture: Encouraging a positive team culture characterized by trust, mutual respect, and recognition of achievements helps diminish ego-related challenges. Recognize and appreciate individual contributions while reinforcing the importance of teamwork.

3. Implement Conflict Resolution Mechanisms: Despite efforts to manage egos, conflicts may arise. Implementing effective conflict resolution mechanisms, such as mediation or facilitated discussions, can address, and resolve conflicts before they escalate and impact project progress. In one of my earlier engagement, the Scrum Master implemented the concept of Team Agreement and Conflict resolution approach, She split the team into two and then asked the team to develop Team agreement (with one group) and Conflict resolution (with the other), Once it was done, then the teams were exchanged and asked to review and suggest chances to the data as written by the other team and finally come to an agreement – which then became the BIBLE for the team to behave and manage relationships internally

4. Promote Collective Ownership: Emphasizing shared responsibility and recognizing the team’s collective achievements helps to mitigate individual ego-driven tendencies. Celebrating team accomplishments rather than individual achievements creates a sense of unity and encourages collaboration. – This has been one of the major elements of implementation with one of my earlier managers – Approach was simple – celebrate the smallest of achievement – Even if that was a successful code review or a major bug fix found, or a Sprint Goal achieved.

5. Cultivate a Collaborative Environment: Project managers should prioritize building a culture of collaboration by encouraging open dialogue, active listening, and valuing diverse perspectives. By creating an atmosphere where team members feel heard and respected, ego-driven conflicts can be minimized. For instance in one of my previous organization, there was a process, where the Project manager would have at least 2 one on one with the team members daily and one meeting (called – “All Hand Meet”) – during this meeting – no project discussion, but more of personal touch, life discussions, general elements were discussed, this helped all the team members to know each other and value the skills and talent that others bought to the table.

Though we have a few interesting ideas for managing Ego, we also need to understand the reasons and challenges from the other side of the fence. Observations and better understanding after 3 decades of working gave me the following elements on Ego:

1. Intrinsic Nature: Ego is an inherent part of human psychology. It stems from our need for self-identity, self-worth, and recognition. It can manifest in various forms, such as the desire for power, control, or validation. Since ego is deeply rooted in individuals, managing it requires self-awareness and conscious effort. At times this can also happen due to our local environment at home or office
2. Lack of Self-Awareness: Ego management requires self-awareness, which can be lacking in individuals who are not introspective or reflective. Without recognizing and understanding their own ego-driven behaviors, individuals may inadvertently perpetuate conflicts, hinder collaboration, and impede project progress. Sometimes what a person does, may not realize that their actions are counter-productive, but they fail to understand & appreciate this
3. Resistance to Change: Ego often resists change, as it challenges our sense of self and disrupts established patterns of behavior. When confronted with alternative viewpoints, suggestions, or feedback, individuals with strong egos may feel threatened and resist adopting new ideas or approaches. This resistance can hinder collaboration and innovation in project management – This is a basic human nature to resist, we form opinions about things and do not want to change and this itself could be a showstopper in our life.
4. Fear of Vulnerability: Ego can serve as a defense mechanism to shield individuals from vulnerability. Admitting mistakes, seeking help, or acknowledging limitations can be seen as a blow to one’s ego. This fear of vulnerability can make it difficult to foster open communication and address issues proactively, leading to strained relationships and project challenges. This is the most dangerous part of the human character and nature.
5. Competition and Comparison: Ego often thrives in environments where competition and comparison prevail. When individuals feel the need to outperform others or maintain a superior image, collaboration and teamwork can be compromised. Project environments driven by ego-focused competition can undermine trust and hinder collective progress. At times this can be hugely negative element for the project and its team members – but at times it could be a savior in some manner.
6. Power Dynamics: Hierarchical power structures can exacerbate ego-related challenges. In environments where authority is concentrated and decisions are made unilaterally, individuals may feel the need to assert their own importance or protect their ego. This can lead to power struggles, lack of transparency, and diminished collaboration within project team.
7. Emotional Investment: Ego is closely linked to emotions and personal identity. When individuals become emotionally invested in their ideas, decisions, or positions, it becomes harder to objectively evaluate alternatives or consider differing perspectives. Emotional attachment to one’s ego can hinder rational decision-making and impede effective collaboration.

Last few words of wisdom:

Overcoming the challenges associated with ego requires a combination of self-reflection, open communication, empathy, and creating a supportive project environment. By promoting a culture of humility, self-awareness, and collaboration, project managers can address ego-related challenges effectively and foster an atmosphere conducive to project success.

To foster a healthier work environment, it is important for individuals to develop self-awareness and emotional intelligence, which can help them manage their ego and cultivate more constructive behaviors. Organizations can also promote a culture of collaboration, open communication, and continuous feedback, which can mitigate the negative impact of ego-driven behavior and promote a more productive and harmonious work environment.

Ego management plays a vital role in project management. By effectively managing ego-driven behaviors, project managers can create an environment conducive to collaboration, open communication, and innovation. Nurturing a culture of humility, respect, and shared ownership cultivates a high-performing project team that maximizes its potential for success. Embracing ego management strategies empowers project managers to navigate the complexities of human dynamics, ultimately enhancing project outcomes and achieving organizational goals.

It will always be the ownership of leadership to have the right environment and culture in the organization, This should also be reflected in our hiring practices, can we devise some approaches where these symptoms of Ego can be tracked and traced, this would help the organization and project at large in a long way post hiring of the candidate; but to have these ideas and thoughts implemented (at least on a pilot basis), it requires courage, forward thinking, ability to navigate thru a maze of negative and not so proactive thoughts and actions of people and finance (tools are not free)

Leadership / Management should see the writing on the wall before it is too late and the we miss the bus ….

See you later in some other thought provoking article ….

If you have ideas what you want to see me write – Pls let me know.

Work Life Balance – Is it a Myth or a HR Jargon or Practiced in reality?

Work-life balance in the IT world / industry can be a complex and a difficult issue, as the nature of the work often involves long hours, tight deadlines, and high-pressure situations. While achieving work-life balance in the IT industry can be challenging, it is not impossible, work-life balance is an essential concept, it can sometimes be challenging to implement effectively in real-life organizational setting, but many organizations within the industry are actively working to create a more balanced environment.

I remember during the pandemic, when the entire (I would say about 98% of us) were working from home, It was very worrying for me, if someone called me and I was not in front of my laptop (could be a washroom break, or gone to answer the doorbell), it was assumed that I am not working, Where as when you are in office and people see you once and then you are not on the seat / or your place, it is acceptable – I can spend a whole 1 hr. chatting with someone in cafeteria and that would be considered just fine. My issues are a little different as people behave differently as the policies and the leadership approaches are erratic.

Why do we have challenges in maintaining the Work-Life Balances at our workplace, with my decent experiences of working across the globe and for different types of organizations, I have got some interesting thoughts here – which may resonate with you, Do check them:

Inadequate Project Management and Planning: Poor project management and planning can play a significant role in work-life balance. Unclear communication, unrealistic deadlines, and no proper resource allocation – all these aid to excessive workloads and the need for constant overtime. Prioritization and efficient time management are crucial in maintaining a healthy work-life balance. The 1^st principle for good work and time management – here goes for a toss.

Lack of Boundaries: In some work environments, there is a blurring of boundaries between work and personal life. With advancements in technology, employees may find it difficult to disconnect from work, as they are constantly connected to their devices and expected to be available outside of regular working hours. This lack of boundaries can erode work-life balance and lead to a sense of being “always available.”

Limited Support Systems: Despite having work-life balance policies in many companies, organizations may not provide the necessary support systems to help employees achieve balance. For example, inadequate childcare support or limited access to wellness programs can make it challenging for employees to effectively manage their personal commitments alongside their work responsibilities.

Cultural Expectations and Peer Pressure: In certain workplace cultures, there can be unwritten expectations that employees need to constantly be available and put work above everything else. Peer pressure and cultural norms within the organization may discourage employees from prioritizing their personal lives or taking time off, even when work-life balance policies are theoretically are existing. It is just a hoax to have such policies in the 1^st place – Not sure how employee (including me) falls in such trap.

Long Working Hours Culture: A variant of the above mentioned point, many industries and organizations have a prevalent culture of long working hours, where employees are expected to work well beyond their designated hours. This culture often undermines work-life balance, leading to increased stress, burnout, and a lack of time for personal commitments or leisure activities. Organizational culture and expectations can make it difficult for employees to truly achieve balance as needed in life.

Demand for 24/7 Operations: The IT industry often operates in a 24/7 environment, particularly in areas such as software development, cybersecurity, and IT support (this is the nature of business). As we go global, the customer wants solutions and resolutions to their challenges and problems during their day-time – which could be off-hours for people working in different time zone.  This can lead to employees being on call or working irregular hours, which can impact work-life balance. However, organizations can implement measures such as shift rotations, adequate staffing, and clear expectations around availability to help mitigate the negative effects. (I would state a few organizations have performed Shift approaches, extra cash, transport facilities and others to help their employees work effectively)

Final Approach:

It is important to note that while these elements as stated exist, there are also organizations that prioritize work-life balance and successfully implement policies and practices that support their employees’ well-being. However, the challenges mentioned above highlight the need for organizations to go beyond policies and actively create a culture and environment that values work-life balance, promotes flexibility, and supports employees in achieving harmony between their personal and professional lives.

While work-life balance in the IT industry may present unique challenges, organizations are increasingly recognizing its importance and taking steps to address it. By implementing policies and practices that support flexibility, well-being, and effective project management, the industry can create an environment that enables employees to achieve a healthier work-life balance. However, it is important to note that the extent to which work-life balance is achievable can vary between organizations within the industry, and it may require individual efforts as well.

Business Analyst to Product Owner – A journey to unfold or it is a mismatch of roles and responsibilities.

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.

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.
3. 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
4. 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:

1. 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.
2. 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.
3. 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.
4. 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

1. 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.
2. 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
3. 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.
4. 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.
5. 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.
6. 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.

Conversations – The Forgotten Art of Managing relationship and Creating a Sustainable Team

Good conversations are a two-way street. It’s important to not only express your own thoughts and ideas, but also to listen to and learn from others.  Having a bi-directional conversation within a team is essential for building strong relationships, sharing ideas, and achieving common goals.

It’s important to be aware of how our behaviour can impact a conversation. If you want to keep a good conversation going, focus on being respectful, open-minded, and engaged in the conversation.

In an Agile team, conversations play a crucial role in ensuring that everyone is aligned with the team’s goals and priorities.

Let’s create a background on how to mess up with a team in engaging with a behaviour that is not conducive for any further team building.

If you want to spoil a good conversation, here are some things you can do (and believe me they work and give you the desired results):

1. Talk too much: If you talk too much and don’t let others contribute to the conversation, you can quickly spoil a good conversation.
2. Be negative: If you’re negative and focus on the negative aspects of the conversation, you can bring down the mood of the conversation and make it less enjoyable.
3. Interrupt others: If you constantly interrupt others when they’re speaking, you can quickly make the conversation feel disrespectful and unproductive.
4. Be closed-minded: If you’re closed-minded and not open to new ideas or perspectives, you can shut down the conversation and prevent it from evolving into something productive.
5. Be judgmental: If you’re quick to judge others and their ideas, you can create a defensive atmosphere where people are hesitant to share their thoughts and opinions.
6. Take things personally: If you take everything personally and get defensive, you can quickly turn a good conversation into an argument.
7. Be distracted: If you’re distracted and not fully present in the conversation, you can make others feel like you don’t value their contributions.

It’s important to be aware of how your behaviour can impact a conversation. If you want to keep a good conversation going, focus on being respectful, open-minded, and engaged in the conversation, with this negative approach, you can destroy a team culture, you would not be respected, your opinion is not heard, you are a non-required person on the team.

Scrum master’s should help the team develop a behaviour and approach, where the Scrum Values are practiced and respected, this would help the team to evolve into the next orbit of collaboration.

When you are getting into a new team or supporting a tenured scrum team … I recommend you to adopt the following:

1. Create a comfortable environment: It’s important to create an environment where everyone feels comfortable and safe to speak their minds. Encourage open communication, active listening, and respect for each other’s opinions.
2. Define the purpose of the conversation: Ensure that everyone is on the same page about the purpose of the conversation. Make sure that you have a clear agenda, and that everyone knows what they are expected to contribute.
3. Ask open-ended questions: Instead of asking yes or no questions, ask open-ended questions that require more thoughtful and elaborate responses. This can help promote deeper and more meaningful conversations.
4. Be an active listener: Pay attention to what your teammates are saying and respond thoughtfully. Clarify any misunderstandings, and make sure that everyone feels heard and valued.
5. Stay focused: Keep the conversation on track and focused on the topic at hand. Avoid going off on tangents or getting side-tracked by unrelated issues.
6. Encourage participation: Make sure that everyone has the opportunity to participate in the conversation. Avoid dominating the conversation or letting one or two people monopolize the discussion.
7. Summarize the conversation: At the end of the conversation, summarize what was discussed, and identify any action items or follow-up tasks. This can help ensure that everyone is on the same page, and that the conversation was productive.

By following these tips, you can help create a team environment that promotes open communication, mutual respect, and shared success.

Some additional elements to engaging in a delightful and result oriented conversation would be:

• Use visual aids: Use visual aids like Kanban boards or task boards to track progress and make it easier for everyone to see the status of each task.
• Focus on collaboration: Encourage collaboration and teamwork by encouraging team members to work together to solve problems and achieve shared goals.
• Be open to feedback: Be open to receiving feedback from team members and be willing to adapt and make changes based on that feedback.
• Celebrate successes: Celebrate team successes and achievements to build team morale and motivate team members to continue working towards the team’s goals.

Engaging conversations would also aid the Scrum values to be implemented, adopted and lived.

Remember, good conversations are a two-way street. It’s important to not only express your own thoughts and ideas, but also to listen to and learn from others. By following these tips, you can help create a team environment that promotes open communication, mutual respect, and shared success.

Believe that every team and each individual in every team is different, they have different needs, their personalities are different, their skills set, experience, talent, collaboration style are all unique and when we apply the same yard stick of discussions and conversation that has proven to be successful with some other team – we make the classic mistake of One Size that Fits All.

An experienced Scrum Master would / should be able to adjust its own approach / strategies and cater to the needs of the current team where the services are rendered  / provided / assisted

In summary, managing dysfunctional team in an Agile environment requires a proactive and collaborative approach, focusing on communication, education, coaching, and team involvement, and measuring progress and adjusting as needed.

As we always say in Agile … Inspect and Adapt and Be transparent to yourself atleast and do a daily retrospective of Self-Behavior

How to maintain and sustain a Scrum Team – The Secret Sauce (Engage the Scrum Team Member)

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

Gemba Walk – A method to collect requirements & observe current approach of working (Forgotten tool in the industry)

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.

Empathy – A tool for better understanding of our end users and solution users

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.

Again it should never be one size that fits all.

OLD WINE, IN OLD BOTTLE – BUT WITH NEW LENS

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 / 1^st 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 3^rd 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 …

1. Willingness of the Leadership to embrace agile (it cannot be just a lip service)
2. Attitude of the Scrum Team towards Agile
3. 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.

Choice is always yours. Exercise the right one.

What Is Fail Safe approach at Work?

Scrum Teams are made up of people with different life experiences bringing together many valuable and different perspectives. Diverse groups are better able to recognize problems and offer more creative solutions than group of people with similar experiences.

But what if some team members don’t feel comfortable speaking up? What if they’re afraid to share their concerns or resisted asking challenging questions? What if they avoid suggesting innovative ideas because they’re worried about rejection? – this is an indication of Technical Debt (in our Environment – Not in our code, remember to refactor your working environment also)

A lack of safe environment at work has major business implications.  When employees do not feel comfortable talking about initiatives that aren’t working, if the organization does not listen to these conversations, then it isn’t equipped to prevent failure. When employees aren’t fully committed to your new project or ideas or initiatives, the organization has lost an opportunity to leverage the strengths of all its talent.

People need to feel comfortable speaking up, asking basic questions, and disagreeing with the way things are in order to create ideas that make a real difference.

This also means as an employee we embrace conflict and speak up, knowing that your team has your back, and you have their backs.

Defining Safety at Work

Fail Safe environment is a belief that nobody would be punished or seen down or insulted for speaking up with ideas, questions, concerns, or mistakes.

When we have such safety in our projects and organization, one would feel comfortable being themselves. Employees would bring their full-selves to work and feel okay laying all of themselves on the line.

How to create a Fail Safe Environment in our Scrum Teams?

When a scrum team is characterized by interpersonal trust and a climate of respect, members feel free to collaborate and they feel safe taking risks, which ultimately enables them to implement rapid innovation.

A fail safe workplace begins with a feeling of belonging. Like all theories of human needs — which shows that all humans require their basic needs to be met before they can reach their full potential — employees must feel accepted before they’re able to improve their organizations.

Step 1: Inclusive Safety

Inclusive safety satisfies the basic human need to connect and belong with peers and superiors. In this stage, you feel safe to be yourself and are accepted for who you are, including your unique attributes and defining characteristics.

Step 2: Learnability Safety

Learnability safety satisfies the need to learn and grow. In this stage, you feel safe to exchange in the learning process, by asking questions, giving and receiving feedback, experimenting, and making mistakes. None should feel that any questions are non-value add.

Step 3: Do-er Safety

Do-er safety satisfies the need to make a difference. Each person should feel safe to use their skills and abilities to make a meaningful contribution.

Step 4: Challenging Status Quo Safety

Challenging any status quo inspires the need to make things better. One should feel safe to speak up and challenge the status quo when you think there’s an opportunity to change or improve or you believe something is not done the right way.

How can Scrum Master and Product Owner create a Fail Safe approach in their respective teams?

Think about it in terms of making incremental changes that yield incremental wins. Scrum Masters can set the stage for incremental change by facilitating the Scrum Team to set expectations for factors that contribute to safety of thoughts and ideas. Doing so will help encourage innovation and radically different thought process.

With your team, discuss the following questions:

• How will team members communicate their concerns about something that is not working?
• How will you respond to failure or bad news?
• How do we raise sensitive issues?
• What are the norms for managing conflict with in the team?
• Are you willing to accept creative, out-of-the-box ideas that are not well-formulated?

How can developers nurture Safety at Work?

While Scrum Masters and Product Owners play a role in shaping their team’s culture, it’s up to each team member to contribute to a fail-safe environment.

A culture is defined by “the way we do things around here” and we all have a role to play in how we do things at work — both on our teams and in our organization.

Developers can take the following steps to promote productive dialog and debate:

• Ask powerful, open-ended questions, and then listen actively and intently to understand feelings and values, as well as facts.
• Agree to share failures, recognizing that mistakes are an opportunity to learn and grow.
• Ask for help, and freely give help when asked.
• Embrace expertise among many, versus a “hero” mentality.
• Encourage and express gratitude, which reinforces team members’ sense of self.

Most importantly, positive interactions and conversations between individuals are built on trust. Show empathy in the workplace by giving your team members the benefit of the doubt when they take a risk, ask for help, or admit a mistake. In turn, trust that they will do the same for you.

Scrum Masters should be investing in strengthening the quality of dialogue across the team and the organization. Remember, better conversations will lead to a better culture. Improved conversational skills, combined with a fail-safe environment, will yield employees who are more willing to share unspoken reservations and proposed solutions that are stress-tested more rigorously before implementation.

What happens when the Work Is Virtual?

At first, it may seem that it’s harder to promote fail safe approach when employees are working remotely. How do you establish trust when interpersonal conversations have to be scheduled in advance and conducted through a screen?

On a LIVE virtual call, one has the ability to look intently at people, not just listening to their words, but seeing and feeling their emotions. In many cultures, it can be awkward to stare at someone for 30 seconds or certainly minutes at a time. But on a LIVE Virtual approach no one knows who you’re looking at, and your ability to apply your emotional intelligence can be enhanced.

Conclusion:

Remember, the goal is to create a safe place to work where team members aren’t worried about feeling rejected for speaking up. When that’s the case, not only does interpersonal risk-taking become the norm, but team members are also more adaptable in the face of change. In other words, they understand the challenges and opportunities that exist throughout the organization — and they see their role in making it a better place.

Scrum Masters – Take a lead in creating such an environment … Product Owners need to be supporting the Scrum Master to nurture such an environment … remember a team that is encouraged to take risk, speak freely, keep innovating without worry about failures, will produce the value that your customers would love. Leave the concept of improving your velocity (seems like this is the only metrics and KRA every one in life has – I mean all agilists), rather focus on the environment, culture, collaboration, communication (I know these are dirty and bad words – but believe me they will help you in your journey towards excellence) and would help you improve / increase our required throughput / cycle time / velocity