An extraordinary story of deeply troubled department turning into a true self organising team of teams

schedule Mar 20th 02:15 - 03:00 PM place Neptune people 99 Interested

It’s not too easy have agility at individual level especially when that person has a lot ot unlearn, it’s then very hard to scale that out to a team, and extremely hard for larger groups such as a business department or entire organisation. And yet when you do unleash that, the upside is definitely unproportional to the effort and hardship, and surprisingly, it’s actually not THAT hard.

You might have heard self-organising / managerless teams, but it’s less likely you’ve actually experienced one. You may have experienced Agile in the most form of Scrum, but it’s not likely you’ve even heard of a Scrum team who doesn’t even need daily standups. In this talk you’ll see how a radical thought of organisational structure turned into reality, and what it is like to witness a team of teams transformed from brokenness to approaching the realm of organisational nirvana in just a year.

 
2 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Case Study

  1. The cost of dis-engagement ($70 billion per year in Australia), with complaint quotes, and real issues the teams were experiencing. Anecdotes with short real stories, aim to let the audience to resonate with emotional connection. Also aim to explain with examples of the ‘brokenness’ and ‘trauatizedness’ of the team before the transformation journey.
  2. The alternative - 8 trends of practices from corporates around the world that consistently demonstrated not only more loyal employees but also directly translated to happier customers and up to 300% profit increase. Ask the audience question: where do you want to be in this trend? Join it, or against it?
  3. That looks like a great picture, but how?
    1. how we turned a team with heavy tech-centric and strong top-down authority into a booming self-organising team, few key points:
      1. Dealing with slackers of the team
      2. Retaining good team members thinking of leaving
      3. Boss has spoken, to listen, or not to listen?
      4. Building an open, vulnerable, and trusting team culture
      5. Teaching the team to deal with conflicts
      6. Helping team to realize and accept real power - what about the one person who is very capable and very helpful and very respected and very controlling?
      7. Diving down into people’s hearts and fundamental thinkings
      8. Culture experimentations - this led to things like “no need for standups”
    2. how we scaled that, even to non-IT teams, and turned that into a self-directing team without the need of manager, few key points:
      1. Each team is different, and they learn differently
      2. Teaching Agile way of working to teams who have no IT development knowledge or experience (it’s contact centre and content management teams with top IT skill being Excel)
      3. Building deep connections with various types of diversities including age, LGBT, and vast personality splits bordering mental health conditions
      4. Clearing the environment so that people and teams can grow, and they did, to the point of a team voting NOT to hire a manager when the current manager decided to take 12 months off her career for travelling (and the team put up a 300 piece jigsaw map of Australia to track her route!)
      5. Supporting a manager-less team
  4. The benefits we observed, e.g.
    1. completely turned around reputation of none-delivery to consistently deliver ahead of schedule
    2. productivity increased to 189%
    3. multiple employees said in multiple occasions “this is the best team I ever worked with”
    4. team trust NPS jumped from -11% to +81% and remains thereabout
    5. a none IT team took on a very technical system upgrade project with huge success, contact centre operators educated themselves to such a technical excellence that’s on par with external consultants previously hired and even got invited by them for a talk in forum
    6. team gone managerless with unprecedented eagerness to participate...
  5. Call to action - what you can do now!

Learning Outcome

  1. Self-organising team is possible and actually not THAT hard
  2. The 8 trends of corporate practices
  3. The steps and key elements to build a self-organising team
  4. The tangible benefits of self-organising team every company can achieve

Target Audience

Leaders who are interested in building and supporting self-organising team, in minimising bureaucracy, in fostering genuine culture that triples engagement and subsequently productivity

Prerequisites for Attendees

Preferably in managerial role and with Agile experience, but not essential.

schedule Submitted 6 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Shashikumar singh
    By Shashikumar singh  ~  6 months ago
    reply Reply

    Hello William,

    Thanks for submitting your proposal on " An extraordinary story of slum dog department turning into a true self organising team of teams " 

    Will it be possible for you to share some previous presentations slides which you would have done , Draft Slides of this presentation or any video link of your presentation.

    As it will help us to do review of your proposal.

    Regards

    Shashi K Singh 

    • William Feng
      By William Feng  ~  6 months ago
      reply Reply

      Hi Shashi, 

      Thanks for the comment. 

      Regarding the slides, though I have just started proposing this talk to various forums, I have not yet prepared the presentation slides as of now. I had discussed some contents with almost every keynote speaker of Agile Australia this year (e.g. Jeff Smith, Steven Denning just to name a few), almost everyone encouraged me to prepare a talk or even write a book about it, but I have not had the chance to settle down and put my effort into that as yet. So unfortunately I don't have what you're asking as of now, and knowing the proposal window is finishing soon, I'm aware this may reduce the chance of the topic being selected.

      Let me know what you think and help me to decide if I'd rather scram a bit to produce some draft slides.

      Cheers.

      William


  • Liked Kaminski Pawel
    keyboard_arrow_down

    Kaminski Pawel - We learn the most when things go wrong - leading leaders to #extremeOwnership and #noBlame culture

    Kaminski Pawel
    Kaminski Pawel
    CTO
    uCreate
    schedule 6 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    If I had a rupee for every time, I heard a CEO, product owner, scrum master or a manager complaining about their teams not caring enough about projects, other team members and users ...

    If I had a rupee for every time, I heard a leader asking for advice on how to stop "blaming games" and "political bureaucracy" in his/her organisation...

    We learn a lot about an organisation, its culture, and real values not during the times of enormous profits, successful product deliveries or CEO monthly motivational speeches but during the times of greatest struggles. We learn and find out who the real leaders are in moments when everything goes wrong, and everyone is making excuses and finger-pointing at other members or external factors. No one is to blame, and no one knows whose fault was the latest issue? The horror stories of firing employees on the spot, tearing down teams, bullying and threats are familiar to all of us.

    I genuinely believe that it does not have to be this way. I believe that there is a more effective way of leading the organisation, teams, and individuals. We have the most extraordinary opportunity to improve, make an impact and improve when things go wrong.

    We just have to change our approach to blame and ownership. Together we will learn how to reconsider your leadership skills and how to use them to accomplish team mission effectively. I want the audience to experience what extreme ownership means for them and what it means to be entirely responsible for all possible outputs. Participate in a challenge to create a team with a #noBlame approach to their mistakes. At the same time develop teams where psychological safety establishes an environment where uncomfortable conversations and creative conflict solutions can thrive.

    I want to share impactful lessons learned from building teams and company that tries to behave differently in moments of failure. How we started to appreciate opportunities created by accidentally removing production database, what we learned by forgetting to communicate with each other or follow agreed processes, and what happened when we declined to do a very profitable project. How we are seeing signs of people owning their projects entirely, taking responsibility and changing others around them. How we train leaders on all level of organisation and how we share more and more responsibilities with them. Experience our approach to blame concept and #noBlame culture we champion and value.

  • Liked Leena S N
    keyboard_arrow_down

    Leena S N - Expand Contract Pattern for Continuous Delivery of Databases

    Leena S N
    Leena S N
    CTO/Programmer
    YogaTree
    schedule 6 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    Modifying the schema of a production database is hard. If something goes wrong, the impact on both customers and the team can be enormous. And it can be hard or even impossible to rollback a database schema change if things go wrong. And the same is true for any architectural change for a production application.

    The Branch by Abstraction and Strangler Pattern makes significant application changes easier. Are there any similar patterns we can use to make production database changes less risky?

    Indeed, there are. The Expand/Collapse pattern is a blueprint for making the database migration. It makes the remodelling both reversible and safe. By expanding the application to accommodate both the old and the new schemas in parallel, we can give ourselves time to:

    • Migrate any downstream dependencies on the old database schema
    • Gain confidence that the migration is safe

    We contract the application to the new version, once we’ve satisfied that the old schema is no longer needed.

    The pattern helps to make significant, but necessary refactorings to your data model in a continuous delivery way. Most importantly, without threatening the robustness of your production applications.

    While working with our product, I’ve successfully applied this pattern to make major changes to the core of the application, all while serving customers in production. I’ve learned some important lessons about how to best implement the Expand/Contract pattern.

    In this session, I’ll share my experiences on how to avoid pitfalls and succeed at these kinds of major data remodelling with hardly any downtime.

  • Liked Kaminski Pawel
    keyboard_arrow_down

    Kaminski Pawel - Practical use of Theory of Constraints - the story about bottlenecks, introducing change and win-win conflicts resolutions

    Kaminski Pawel
    Kaminski Pawel
    CTO
    uCreate
    schedule 6 months ago
    Sold Out!
    90 Mins
    Tutorial
    Beginner

    A perfect introduction to the Theory of Constraints in 3 acts. Three compelling stories that represent crucial aspects of ToC including bottlenecks, introducing change in organisations and resolving conflicts to create win-win solutions.

    Let us start with ToC premise that at least one constraint limits the achievement of the goal by any system. For the system to improve, the bottleneck has to be identified and exploited.

    Experience the pressure felt by ToC experts dealing with "largest marine oil spill in the history" and how creatively and orderly they approached that challenge. I want to share their story and my experiences finding bottlenecks, exploiting them and achieving a higher throughput of value in projects.

    ToC has a fascinating way of looking at introducing change into teams and organisations. Participate in considering some uncomfortable "facts" that we all know and believe about our failures. With the help of Eliyahu Goldratt, we will reconsider why some of our attempts at changing the situation around us failed or deliver limited benefits in comparison to initial promises. We will learn what to do next time we face the same dilemma.

    Finally, I want to recognise conflicts and ToC way of approaching disagreement resolutions. With the help of the audience, we will build pragmatic Evaporating Cloud to show how to create win-win solutions, forget about compromise and increase understanding between parties. The audience will experience and learn how to stay calm, tips and tricks on how to tackle conflict and how to grow empathy and their conflict solving abilities.

    Summary:
    Three stories are bringing essential concepts of the Theory of Constraints to life. We will consider the WHY behind the ideas, HOW to practically implement them and WHAT they can do for you, your team and organisation. Fundamentally we will try to answer three crucial questions:

    • What to change?
    • What to change to?
    • How to change it?
      by helping you, find bottlenecks, control the introduction of change and its outcomes and create an environment where conflict is a potential source of interesting conversations.
  • Liked Neeraj Agarwal
    keyboard_arrow_down

    Neeraj Agarwal - Code reviews - a hidden gem to save time, increase team happiness and improve knowledge sharing

    Neeraj Agarwal
    Neeraj Agarwal
    Manager Operations
    Ucreate it
    schedule 6 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Most of agile conferences talks focus on "soft side" of being agile. We discuss process guidelines, Scrum Masters responsibilities, team building exercises and servant leadership ideas. In our quest to be agile we sometimes forget about developers and technical members of our teams, their tools, processes and way of thinking. Aspects like code reviews, TDD, CI, pair programming are hard for us to understand and justify spending time on them. We should not forget that at the end of the day great products we create needs great code to run.

    All organisations whether startups or large established are products and services using Agile guidelines. But most agile transformations focus on SM and PMs forgetting about developers and their challenges. It's a tough life being a full stack developer these days. They have to keep innovating & adapting latest trends in technology. PO & PM always want changes or ideas to incorporate ASAP, Moreover every line of code is exposed being pushed code to live multiple times a day.

    Constant Environment change, New languages and their regular updates, Huge legacy apps, Constant request from business to do more in new cutting edge has increased complexity in writing code. Code that is difficult to understand, hard to modify and challenging to extend is hazardous to developers, users and organizations. So what measures can be used to prove the code quality and the approach for improving the quality of the code base.

    “Code review” can be a handy tool catering the developers in real time to groom their skills while keep them focused on the agile process.

    Code review actually empowers agility by improving product and code quality and eliminates defects early when they are least expensive to fix. Code review process let developers think of new ideas how to write better code every time. Moreover, when working on project no-one is the only person who knows a specific part of the code base. Code review facilitate knowledge sharing of the code base across the team. Agile teams can realize huge benefits because work is decentralized across the team.

  • Liked PARUL PANDIT
    keyboard_arrow_down

    PARUL PANDIT - "We have been doing agile all wrong and what can we do about it."

    PARUL PANDIT
    PARUL PANDIT
    Scrum Manager
    Ucreate.it
    schedule 6 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Since 2001 Agile has been reshaping the software development and business world. The word chosen at the gathering in Snowbird, Utah in 2001 is now probably the most used and misrepresented word in our industry. Everybody is talking about "doing agile," "following agile," "being the most agile" and changing the world using "agile methodologies." We all make huge claims in the name of “agile” as if it could magically increase our customer satisfaction, improve the quality of our code, processes, products, make our people smarter, highly engaged and passionate about their work, and speed up our delivery. At this stage there are no reasons not to "do Agile," the claims and promises are large enough to jump in, without really considering what Agile stands for.

    We often presume that Agile is the solution to every problem we have, Agile doesn't fix our problems it shines a light on them and exposes all previously unseen issues.

    This movement of following Agile blindly, without thinking, context consideration, and direction lead to claims that Agile is dead, famously mentioned by Dave Thomas in one of his talks. Everybody "do Agile" by hiring certified Scrum Masters, bringing Agile coaches, doing standups, retrospectives and expecting great results and a badge of honor in return. My view is that those organizations are just scratching the surface in "doing Agile," not really "being Agile" and for me, there is a considerable difference between “being” and “doing”. I see Agile organizations still following 12 months predefined plans, having QA departments as a separate function and having all decisions driven by Project Managers and their giant charts. There is very little room for incremental improvements, self-reflection, team, and people orientation and culture first approach. Everybody still feels afraid to be themselves, speak out or suggest a new idea.

    In my view its time to claim "Agile" back and reconsider what it means and how it can help us achieve our personal, team and organization goals. The talk will focus on strategies, conversations, and examples of what "being Agile" really means. Together we will consider “agile” current situation, why "doing Agile" does not deliver the expected results and what you can do about it when you go back to your office on Monday morning.