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

Tips to mess up your Agile Transformation / Adoption

We, for ages have been attending a lot of workshops, trainings, getting coached, reading a lot of material on the internet, wherein all of them are providing guidance on how to implement / adopt the right and the correct practices of agile / scrum / Kanban.

My blog today is a high level summary (not all points) of anti-patterns for everything that the world is preaching, teaching and more importantly NOT IMPLEMENTING

My guidance would help all the organization and respective managers to know and learn how to mess and manufacture a disaster for their agile ways of working.

We all know 3 important roles in Agile or should I say Scrum (in specific) – We shall today take the most neglected role of Agile – “THE PRODUCT OWNER”

Off-late watching and experiencing the world and the behavior with the product owner, I have become more educated on ideas, thoughts and tips to mess around with the role of Product owner and thereby understand methods and ways in which the value of Agile adoption goes / can go down the drain.

Fasten your seat belts, Here we go …

TIP # 1

Never Empower your Product Owner: Giving power for decision making to a product owner could be injurious to the health and wealth of the Line Manager / Sr. Manager. Always tell the PO what to do, how to do, ask them to document each backlog item with every possible scenario (in the same PBI – even though the PBI would now qualify to be a large feature or an EPIC by itself).

Never give liberty to the PO to decide how to maximize the value of the product, the order of the product backlog items, making their only job is to do documentation of the requirements in complete fashion / manner as we desire, they should not be able to move an inch without our approvals. We are more interested that our PO act and behave as SCRIBES … rather than as Product Owners.

If you do what I am recommending here … Bingo you have achieved Level 1 Maturity of Messing up with the agile ways of working …

TIP # 2

Have your PO also double up as Scrum Master: Well every organization that I know is always short of right resources and talent. If one FTE can double up and do the job of two, nothing like it – a bird in hand is worth two in the bush. It would always help the team as they know they have to look up to one person only and it saves a few dollars of the table (nothing like saving money), it prevents challenges and issues or managing the expectations of 2 people, conflicts are reduced (as we have 1 person only – never heard of a single person is having conflict with themselves).

If you implement and adopt this approach as recommended here … Bravado – you have achieved messing up with Scrum Guide itself … and that deserves kudos and a bravery award to those who take, implement such decisions.

TIP # 3

Have a Proxy Product Owner (who is powerless): Our true North Star “THE PRODUCT OWNER” is across the oceans and in those time zones, that is difficult for any sane person to be wake and sit late at nights and interact with the team (when the team is working). Every problem has a solution and this case it would be to create a replica of the actual product owner in our own location and call them as Proxy PO’s (well we have just introduced a new role in Scrum – Who cares of the Scrum Guide).

Using a Proxy PO is an attempt to superficially treat a systemic issue and push the actual problem below the carpet. One should never allow the Proxy PO to take decisions, they are like glorified Postman / Post Woman here … they only have to take orders from one side of the coin and communicate (with gaps of course) to the other side (aka Development team).

In case you implement and adopt this approach as given above … You have installed insecurity, confusion which effectively breaks down communication in Agile, well who cares for Agile Manifesto statement… Individuals and Interactions over Processes and Tools

TIP # 4

The Partial Product Owner (Allocated to more than 2 teams): One nice way to making our product owners ineffective is to give them multiple products / projects to take care of … So that more than 50% of their time will be spent in doing Scrum events (Sprint planning, Sprint Reviews, Retrospectives and so on …) across all the teams, they should never get time to do quality work on the Product Backlog, think about prioritization and ordering of PBI’s or discussing important elements with relevant stakeholders or end-users. Always work with the approach that – we shall cross the bridge when we come to it.

If we have created such situation, we are at the prime of not messing one but multiple projects, we have actually graduated in our approach and thought process and we deserve a pat on our back

TIP # 5

The Over worked Product Owner (working for more than 14 hrs / day): Working in normal times would get you a rating of 3/5 in your appraisal system, which states – Meets Expectations. These days all organizations need people who would work beyond the normal hours. We have unrealistic deadlines and commitments. Management and Sales folks make an unachievable commitment and then the development team (along with the PO) has to deliver … in order to do this we have to work beyond a normal timeline or cut corners – we end up doing both.

This results in Technical Debt, Poor quality of product and services, dis-satisfied team and unhappy customers – but guess what – we are hitting the clock more harder than before …

If your products / projects have managed to have this situation, then we should be proud of our achievements, any-which ways client and management do not understand the concept of Technical Debt (so it is cool and fine).

Conclusion:

I believe these 5 tips are great source of Anti-Patterns (should I say – Industry ways of working – Anti Pattern would sound rude). If you want Agile to be messed up, use these ideas (they are free and no copy right issues – you can take and update them to be become more fancier).

Nothing that I have said today, is new or rubbish – it is actually practiced in our world by all the agilists – who have great certificates and knowledge, but we buckle under the pressure of having a job, regular income, management, peer pressure and so on …

For ages I have failed to understand why management wants to spend money and hard dollars and still not receive value … well the answer lies that nobody wants to implement AGILE. It is just a buzz word in the system.

If you believe in doing the things right and in the right approach, follow the reverse of all the tips given here … you would notice a more productive, safe, guilt free implementation of Agile.

Try for the true Agile for 4-6 months – do it in the true spirit of the game … if you still do not see results … go back to your old ways – nobody would stop you (anyways nobody is stopping you today also). I would be coming out with such blogs as a series on all roles of Agile / Scrum and then move to events and outputs.

Image is what sets you apart – Are you working on it?

Your image as a Scrum Master or a Product Owner or even as Stakeholder in the eyes of the world could be an asset or a liability for you as a leader. Building an image is magic wand, it could not superficial or unimportant activity. Crafting your own image requires a better understanding of what people in the group, project, organization or the society at large are perceiving, you need to gain a clear picture of your image in their eyes and needs.

Your image is the concept that others form about you as a result of the impression you make on them. It can be an asset or a liability as you engage in tasks and roles of Leadership. It is not easy for anyone to see themselves as the world see them or thinks about them. One needs to have a clarity how your image is hindering or making your effective in the world where you operate. You also need to decide what image you would like people to perceive about you.

Your image is based on multiple elements, which would include but not limited to: Physical appearance or formal status, behavior, body language, your tone when you speak and style of communication – all these contribute to the image of yourself.

People form opinion of others all the time (that is the favorite – pass time of this universe), People make assumptions about you, in absence of solid information and frequent communication people form opinions based on some assumptions, and what they invent is likely to be a distortion of truth, which then leads to your image risk. Remember your image speaks louder than you

Image is always referenced by personal experience, People want their leaders to be likable, approachable, be above average, be their role model and so on…

As you work to convey your effective leadership style, keep in mind that working on your image is not about faking anything, it is all about polishing your behavior and skills that allow your authentic self to be most effective.

Myths about Leader’s perception of Image Management:

• Only celebrities and political leaders have to manage their image
• People know me, what is there to manage
• What you see is what you get
• Creating an image is all about faking
• My position creates the image

Assess your Image and Leadership Style:

1. What feedback have you gotten about your image and how you communicate?
2. What image is conveyed by your leaders in the Organization and how does your image fit in this puzzle?
3. Think of time when your image worked in your favor or advantage
4. Also think of time when your image worked in against you
5. Does your body language show that you are comfortable in your role?

Based on your observations from the above and the data you have, plan to do the following (if appropriate):

• Seek feedback from your colleagues / peers
• Seek opinion of your strongest critic (they would give you the best view)
• See guidance from your reportees
• Pick a focus area to improve upon
• If your office or the area where meetings are held has a CCTV – seek if you can get access to the tapes of your meetings / discussions – observe your tone, behavior, approach, body language.

As Scrum Master / Product Owners, we are always under pressure to deliver value to the customer, improve morale of the team, create the right environment for success / failures and many more. We get pulled in multiple different direction and each stakeholder has an agenda of their own and not serving any of them, creates an impression, leads to an assumption, that forms an opinion and creates the image (GOOD, BAD or UGLY)

Like we do Product review during Sprint Review and Process / Relationship review at Sprint Retrospective, it is equally important to review our own behavior, our own internal approaches and see what corrective actions have to be taken, what tweaks have to be performed.

As we always it is all about Transparency (with your own self), Inspection and Adaption is the key to success … it is time we implement the scrum guidelines on ourselves before we move to conquer the world