Team journey from I to We

I have been working as a Scrum Master with a team for a few months. In one of the releases we encountered a bug in our production release. Technically it was a small check missing, but when the team started discussing it then everybody was pointing at other team members as a source of issue. No one was willing to accept responsibility or creatively consider what went wrong and how to stop this from happening again. It was all about finding someone to blame. This situation changed my focus to explore the aspects of teamwork from the perspective of blame and to look into best possible ways to build a team that never use blame to find out solutions to team challenges.

I will try to share a few examples of how our organisation with #noblame culture tries to behave in moments of crisis and how we never considered blame to be an option or a solution.

I am also very confident that this problem is present in more than just our organisation and it impacts our ability to deliver great value to our customers and build great teams.

As we all know our agile teams should be accountable to each other first but i believe many teams and Scrum Masters often confuse accountability with blame. There is usually an underlying set of issues with people using blame as a solution to their problems. For one it feels good, not to be responsible for team problems. Usually there could be a deeper reasons why a person would play a blame game. Those reason vary from unhappy either in personal or professional life or trying to protect herself due to insecurity. Also in modern society people are so much stressed and obsessed with their desire to be successful they feel happy by blaming others they remove spotlight and pressure from themselves. All those behaviours are very dangerous and impact the team ability to deliver value to users.

During the session we will discuss how we try to create no blame culture, what we do and how you can apply those lessons in your context. I will share some practical examples, theory to back them up and aspects that worked for us. I will also share some failures and mistakes we made on our way.

 
7 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

During the session we will discuss how we try to create no blame culture, what we do and how you can apply those lessons in your context. I will share some practical examples, theory to back them up and aspects that worked for us. I will also share some failures and mistakes we made on our way.

Learning Outcome

At the end of this session you will learn how eradicate blaming culture from your organisation or at least to start seeing it as one of the reasons impacting your team capabilities.

Target Audience

Scrum Masters, Managers, Team Leads, Agile Learners & Developers

schedule Submitted 3 weeks ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Nilesh Kulkarni
    keyboard_arrow_down

    Nilesh Kulkarni - Outcome Based Agile Coaching

    45 Mins
    Workshop
    Intermediate

    Session name - Outcome based agile coaching

    We all want to become good agile coach. But what does that mean? How do you get better outcome from your agile coaching sessions? In this session, participants will experience how to improve outcome of your coaching session. Some areas we will focus in this session are output Vs outcome, why, what, how of coaching, how to make coaching outcome etc.

    This will be a hands on workshop with very minimal guidance from facilitator. Participants will have experiential learning through the activities to understand how to align agile coaching to deliver maximum impact on business outcome.

  • Liked Kaminski Pawel
    keyboard_arrow_down

    Kaminski Pawel - “Believe in what your users believe” lessons learned from creating 20 delightful startups in one year

    Kaminski Pawel
    Kaminski Pawel
    CTO
    uCreate
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Case Study
    Beginner

    Everything we do we believe in our startup founders and their new vision of the world. The way we show this belief is by joining them on the journey of challenging every assumption we know, making a difference for one individual person and always being focused on user, no matter the cost. Let me share with you my stories of how to build products by shifting the focus from scalable, technical solutions to addressing single user needs and challenges first. How to impact culture and inspire a distributed, rapidly growing company and how to collaborate and treat your customers and your colleagues like “you believe in what they believe”.

    Everything we do starts with WHY and a single user need.

    The session is for anyone who in their daily job needs a helping hand, a bit of inspiration and a useful set of practical experiments to challenge status quo, move the needle in their organisation and build delightful products that people really want. I also want to show they they are not alone in their failures and defeats. The lessons will apply to executives changing organisations, scrum masters coaching the teams and product owners wanting to build delightful products

    For me this new talk is about constantly evolving set of ideas, thoughts and values that always puts the user first and allows our employees and founders to have the time of our life.

    I had a great pleasure to speak at SUGSA 2017, the biggest Scrum Gathering in Africa, where i presented this talk and I want to share our story and challenge “we have always done it that way!” point of view.

    My objective is to shift the way you think about your current situation, your team, your organisation and your customers by refocusing you on user needs and always starting with “WHY?”. I am going to show you how to apply design thinking, theory of constraints and cynefin framework to situations in your daily job and see how they could be improved. This talk is about sharing what worked in our context and what made all the difference to our products delivery.

  • Liked Vineet Chopra
    keyboard_arrow_down

    Vineet Chopra - A Self-organizing team is an ever-evolving organism

    45 Mins
    Case Study
    Beginner

    The Organization have rules, standards, and procedures on how work is done and should have the control to delegate and prioritize the work assigned, this was what I was told and programmed few years back in the traditional organizational structure I was working for. Still, there we were asked to percolate Self–Organizing behavior in our teams, and that to under a fully constrained and micro-controlled environment. And what we use to get a few responsible individuals organizing tasks in a way to make their managers happy but never a team who can perform together.

    Whereas, it is well understood that trained responsible individuals are the core of any Self-Organized team and who take responsibility to manage their own tasks and don’t rely on a manger to tell them what to do. At uCreate I am following Agile setup that is propagating a self-organizing team and implementing Agile manifesto: “The best architectures, requirements, and designs emerge from self-organising teams”

    Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. In Self-Organizing Scrum team each member is responsible for determining what work he or she will be doing.

    Now, creating a self-organizing team is a continuous challenge in today's dynamic world, where the focus of building a team can get sidelined due to changing business demands. Another uphill task is whose real duty is to create a Self-Organizing, is it the management, or Scrum Master or Scrum team itself.

    So my today’s session is to discuss with you on how we can continuously pursue towards getting a Self Organizing team since this a continuous process like an organism grows towards maturity.

    We at uCreate are also facing this challenge to change the mindset of individuals who were used to traditional approach and mentoring them or training them or coaching them to be responsible individuals in order to have real Scrum Teams delivering agility on its own.

    There have been various ways it’s been practiced at ucreate but major two focus strategies are:

    1. Review Tool.
    2. Spare Time for Learning.

    The above methods have sure imbibed responsible behaviour in our Scrum Teams but the lot has to be improvised to get responsible Self-Organizing Scrum teams.

    Today’s agenda will be elaborating on above methods and also on few examples on how real-time facilitation is all about being a Scrum Master, rather than using command & control and what can be done to instil self-organizing culture among the Scrum Team members.

    So, Creating a self-organizing team in Agile is not an easy task and takes a reasonable amount of time to form. ucreate has been adding deleting ingredients to help fast-track the formation of such self-organizing Agile teams but still a lot to be achieved in this regard. What as a team we learnt is that process of forming Self-organizing teams is that we should develop individuals who are

    • Responsible
    • Trained and Competent
    • Motivated
    • Respect talent and individuality
    • Goal oriented

    An organism grows from infancy to maturity and then delivers results but the process of development is long and learning all the way similarly Self-Organizing Scrum team is a long and continuous process. The Scrum Master should dwell on creating a team which can buy-in and share ownership, Motivation, which leads to an enhanced performance level of the team and Facilitate innovative and creative environment conducive to growth.

  • Liked PARUL PANDIT
    keyboard_arrow_down

    PARUL PANDIT - To Hear What Is Not Being Said

    45 Mins
    Case Study
    Beginner

    Retrospectives are hard. It’s hard to run a valuable retrospective and it’s hard for all team members to feel that the value has been delivered for themselves, the team and organisation. While facilitating retrospectives many of us has faced a problem of team lacking interest and engagement. Why is that some people embrace retrospectives as a way of getting better and some just feel alienated by it? Even with extremely capable scrum masters and facilitators we often end up with very few actionable team items and we feel not satisfied with team results.

    In my experience in retrospective facilitation one of the main reasons is that, we focus on solving the problems that are being discussed between team members and we only give attention to loudest, outspoken team members who can explain their issues very well. We forget about the whole layer of unseen communication. We forget about “what is not being said.” In my opinion that’s the big problem and challenge worth considering.

    This session will focus on discovery into non-verbal communication, active listening and enabling team members to share more openly and without hesitation. We will consider techniques for increasing team ability to listen and respect others opinions. We will discuss team and individual biases including some practical experiments that everyone can use with teams during next retrospectives.

    I will share with you a few techniques to dig deeper, to try to discover real reasons behind people's opinions and views. We will play the 5 why’s game and see how scrum masters can increase their own empathy.

    Together we will consider other aspects of communications including.

      • Body language
      • Individual and team psychological safety
      • “No problem” problems

    I will share with you different activities, games and experiments you can run to learn more about yourself and explain those issues to your teams. My talk is designed for people who work with teams on continuous improvements and it does apply to much wider applications than just retrospectives, standups and agile practices.

    At the end of the session you will learn practical knowledge how to run a better retrospective, have your team members learn more about themselves and how that knowledge can impact the team deliveries.

    We will consider ways to grow individual team members, as well as whole teams. We will also focus on helping scrum masters understand their current failures and learn from them and us. Trust me, we all have been there! At ucreate we failed more times that we can count but no matter what, we never stopped and we are still learning new and better ways to hear “what has not been said”

    As you probably realised there are no silver bullets to sort out all your communication issues. But there are practical ways to help team members share more and there are ways to learn more from them even when they don't speak. It will enable you you to focus on unheard voice of retro, to be an active listener, to hear what people want to share or simply “to hear what is not being said”.

  • Liked Yogesh
    keyboard_arrow_down

    Yogesh - Agile is fast and cheap - a Myth

    Yogesh
    Yogesh
    Senior Automation Engineer
    Ucreate
    schedule 3 weeks ago
    Sold Out!
    45 Mins
    Case Study
    Beginner

    A few weeks ago i took part in an agile meetup where i met managers and leader from other organisations discussing their need to transition into Agile way of working. They came to the conference to learn a little bit more about “Agile”, but they’d already made the decision to adopt it. They shared their assumptions that the transition will be relatively smooth and they were expecting the increase in team performance almost immediately. They expected Agile to be all about being cheaper and faster. As much as in principle agile want to be faster to market with value to users and cheaper in not doing the wrong things, at the same time the journey requires the whole organisation to change its values, behaviours, investing in people and trusting them. Those activities are rarely cheap and fast. The benefits are 100% worth it but the journey is not as easy as a day of scrum master training and changing of mindset based on motivation talk by organisation leader.

    As a Scrum Master, I’m getting really tired of talking to managers and teams whose sole drive to adopt agile is due to cheaper and faster delivery. Ignoring all other aspects of agility cause the organisations to not really see the benefits of transformation and also neglect crucial aspect of any change: people.

    It's hard for me to accept this way of thinking. During our sessions I will try to explain short and long term agile goals and try to establish the expectations of any agile change. I will be fair and honest and present much more real transformation model, so that everyone can understand why certain things work and others don't. I will also address aspects of speed of delivery based on our experiences at ucreate and consider the “cheapness” of agile based on daily decisions we make. I hope after this session it will be much easier for You to understand where you are in your agile journey and enable you to be able to explain reasonably what is going wrong within your team and organisation.

    In this talk i will present biases about agility and agile methodologies when it comes what can be expected and how long does it really take to achieve expected results.

    We will consider multiple aspects of agile software development and look at it from different perspectives. Quality engineers with their focus on Quality Software, DevOps and developers with Continual Refactoring and Continuous delivery and whole team ability to pay down technical debt. We will always look at benefits of those activities vs the speed and cost applied to them. We will honestly judge multiple agile activities vs value they really deliver. My hypothesis is that Agile can actually be slower to deliver individual features but we should always consider long term view of the project.

    In this session you will learn how to start and explain agile to your team members and management team. You will learn practical knowledge how to manage expectations of any agile transformation and show the real value of organisation agility. You will discover benefits of agile and XP practices and how they measure against the metric of speed and cost. You will never consider agile as fast and cheap again but you will understand the value it delivers to organisations, users and team members.