location_city Bengaluru schedule Mar 20th 11:30 AM - 12:15 PM IST place Grand Ball Room 1 people 60 Interested

How can an Agile Coach figure out when an Agile “Transformation” is going wrong? Are there signs that they might see, heed, and take action upon? Of course, there are!

Hindsight is 20/20, but in the moment, these warning signs can be hard to see. Let’s explore some of the more common, and frightening, warning signs that your Agile “Transformation” might be exhibiting. We will discuss transformation provider types, frameworks, keywords, and other anti-patterns that might be signs that THE END IS NIGH.

This session will review common themes and help familiarize you with the warning signs. Armed with this new knowledge, you will be able to plan as appropriate, to help navigate your organization through potential impending doom.

 
 

Outline/Structure of the Talk

2' - Introduction
35’ – Review the warning signs
The Iron Triangle Transformation
The “Agency” provider
The “Large Consultancy” provider
Frameworks that are “Cool”
Keywords “Squad” “Tribe” “Guild”
Keyword “Spotify”
Frameworks that are “Enterprise”
Keyword “Train”
Keyword “SAFe”
A mass redundancy or layoff
Secrecy
Coach isolation
A Scrum “Transformation” team
A Waterfall Agile “Transformation”
A traditional PM on the “Transformation” team
Keyword “Transformation”
Gantt chart
“Transformation” reports
Risks, escalations, warnings are ignored
What happens next?
3' - Conclusion
Remainder of total timebox (45') - Q&A, approx 5’

Learning Outcome

Attendees will learn that Agile Transformations have some consistent warning sign themes.
Attendees will learn to identify common warning signs.
Attendees will learn what happens after warning signs are escalated.

Target Audience

Agile Executives, Agile Sponsors, Agile Coaches

Prerequisites for Attendees

None

Slides


Video


schedule Submitted 4 years ago

  • Gaitis Kasims
    keyboard_arrow_down

    Gaitis Kasims - Regulations eat Agile for breakfast

    45 Mins
    Case Study
    Intermediate

    Quality in Eurofins Genomics is a central focus point - analysis we do or products we produce have critical applications, be it production of drugs, identifying rare diseases or gene editing. IT is a driving force behind the scenes which challenges us to ensure the highest quality standards without compromising on speed.

    When we start a new project, we do it with enthusiasm and feeling of doing something meaningful or even cool. Following scrum we quickly establish our velocity and deliver soon first release into production. Overall quality is quite good; results from testing acceptable, deadlines are coming so nothing can stop us. Let’s prioritize last bugs, fix critical, move rest into backlog – now we can be proud of having delivered value to users!

    We continue delivering at ever increasing speed as team matures! Unfortunately the idyllic scenery gets soon destroyed by first, more and more effort needs to be spent addressing issues from both QA and production. We spend time arguing with QA and users on what is bug or if this defect is P2 or P3 or can even be seen as P4, from time to time we take a sprint to “stabilize”, but all too often nothing changes. User stories are getting spilled to next sprints, we postpone releases to have more time for testing, club them with next releases and finally find ourselves in downward spiral..

    As quality cannot be compromised we quickly decide that Agile is fine, but as we work in regulated environment we need to be pragmatic and adjust Agile to our needs. What comes out is unfortunately not much different to Waterfall or V-Model, we still keep sprints and do reviews, but realize that only form is left. I am directly responsible for IT in Eurofins Genomics so will share experience from the field on how did we overcome this and reanimated Agile.

  • Tobias Anderberg
    Tobias Anderberg
    Developer/Coach
    Agical AB
    schedule 4 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Ever wondered why some people prefer to work alone? Or why some people cringe when pair programming is mentioned? It might be that that person, like me, is an introvert. But is is really that simple? Can we really put every person in a box labeled "introvert" or "extrovert" or are we all just ambiverts?

    During this session I will talk about introverts, extroverts and everything in between.
    Drawing from almost 15 years of personal experience being an introvert on agile teams I will talk about the differences of being an extrovert
    or an introvert, how to foster an inclusive team environment, and the importance of psychological safety.
    You will hopefully leave this session better fit to help EVERYONE on your team to reach their full potential!

  • Jutta Eckstein
    keyboard_arrow_down

    Jutta Eckstein - CD – Continuous Delivery and Cultural Difference

    20 Mins
    Talk
    Intermediate

    DevOps and continuous delivery is typically elaborated technically - what kind of tools, technologies, or skills are necessary for being able to deliver continuously. Often it is forgotten that continuous delivery requires also a culture change - in development, operations, marketing, sales, and not least for the customer.

    This can be recognized for example, that although it is technically possible for a team to deliver continuously, but it seems that this delivery isn't welcomed. This means the actual system will not be directly used.

    Therefore, in this session by taking into account the necessary cultural change, I want to answer the question how to implement continuous delivery successfully and what kind of pitfalls you need to be aware of when doing so.

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - Liberating Structures... 36 tried and true facilitation techniques to amp up your org's collaboration

    45 Mins
    Workshop
    Beginner

    The communication tools of Liberating Structures will teach you how to facilitate the discussions your org needs. I am going to demonstrate how to use these techniques in the workshop. And all the attendees are going to be fully immersed and ready to wield their new knowledge the very next day at work.

    Come learn how to help your team(s), org(s), and company(ies)!!!

    For more information, watch my video at http://youtu.be/UNOjqMUv8h0

    A version of this workshop that was presented at Agile Tour Sydney 2016 is at http://bit.ly/2f4Bie8

  • Gabor Devenyi
    keyboard_arrow_down

    Gabor Devenyi / Alex Sloley - The magic number is 10

    45 Mins
    Talk
    Beginner

    Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

    But what is it about the number 10 that makes it the “magic” number?

    Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

    There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

    We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

    Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!

    45 Mins
    Talk
    Intermediate

    Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

    Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

    And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

    Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

    Join the fun and come learn what horrifying results await!

  • SUNITHA MENEZES
    keyboard_arrow_down

    SUNITHA MENEZES - Agile Applied for Social Cause :experience in Traffic safety campaign “Stop Look Wave”

    20 Mins
    Experience Report
    Intermediate

    Agile methodology is not limited to software development but it can be applied beyond. I am sharing the experience of applying the Agile, to drive the volunteering activity for the social cause. Volvo Group’s Global Safety initiative for Kids – Stop, Look & Wave is a program with young children (aged 4-10) at schools or communities – introducing them to Road safety .

    The success of the program was based on support from management ,engaging volunteers (team members) and touching the young hearts to become the Safety Ambassador. Agile methodology and Mindset is applied for planning and execution and was very helpful to achieve the objective.

  • Peter Lee
    keyboard_arrow_down

    Peter Lee - Creating clarity and focus in changing a large enterprise

    Peter Lee
    Peter Lee
    Agile Coach
    SiteMinder
    schedule 4 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    Using a simple model to focus leadership on applying a cohesive set of transformational changes can improve the success of a agile adoption. This session explores how this model helped, and is continuing to help, the Boral Digital Solutions leadership team decide on a set of cohesive changes such as the adoption of Scrum, the use of Objective and Key Results, and the establishment of a culture code to accelerate its agile transformation.

    Boral is a construction materials company founded in 1946. It adopted Lean practices in its manufacturing areas over 10 years ago but only recently started on a Technology/Digital transformation. Because Boral spans a diverse business from mining through to the delivery of construction materials, there are endless opportunities to pick from in building a highly engaged, autonomous workforce.
    The challenge is creating clarity and focus from these choices as to what we will do, and what we won't. Using a simple model about how we work and how we engage our people, we are able to:
    1) Create clarity and focus around a cohesive set of impactful changes
    2) Build engagement and buy-in with executive leaders
    We will explore how this model is currently helping Boral, as well as how it can help you in your own transformations. Having evolved through different industries (Campaign Monitor - Software Start-up, Commonwealth Bank of Australia - Financial Services), this model can help you create clarity and focus around what to do when you can't do everything.

  • Bruce Taylor
    keyboard_arrow_down

    Bruce Taylor / Ed. Wong - Going Feral: How to Build agile capability by creating a culture of continuous learning

    90 Mins
    Workshop
    Intermediate

    Presenters: Ed Wong, Founder of the LAST, 1ST and Spark the Change conferences and Bruce Taylor, Agile Coach at RMIT Online.

    Outline of program: How we used internal meetups, workshops, gamification, and learning design to build agile capability at RMIT University (One of Australia's oldest tertiary education institutions) as they navigated the rapidly changing world of online education.

    With more and more institutions moving online, with all that implied in terms of speed, tech capability and agility, RMIT Online needed a world class agile capability. Ed and Bruce set up FERAL (The Federation of Eminent RMIT Online Active Learners): A fun, yet serious, way of fast tracking agile knowledge and practice within the many, disparate teams within this fast growing arm of the University. It was also a way of scaling learning and the effectiveness of 2 agile coaches working across multiple teams.

    In this session we'll talk about the design of the program, the buy in needed from organisation, the types of workshops we ran, some practical examples from the workshops and our experiences running them and post-workshop application and coaching back in the teams to embed the practices.

  • Melinda Harrington
    keyboard_arrow_down

    Melinda Harrington - How I learned to stop worrying and love dev-ops: an introduction for non-technical people

    Melinda Harrington
    Melinda Harrington
    Agile Coach
    Woolworths
    schedule 4 years ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    The world of devops is a part of the agile journey that non techies may find intimidating. This talk demystifies the path to production.

  • Melinda Harrington
    keyboard_arrow_down

    Melinda Harrington - “You are moving too fast” - Adapting Your Style When Shifting from Tech Teams to Business Teams

    Melinda Harrington
    Melinda Harrington
    Agile Coach
    Woolworths
    schedule 4 years ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    Those of us who are used to uncovering new ways of developing software may struggle with the pace of executives and business teams adapting to a more agile way of working.

    • How do we stay inspired?
    • How do we leverage our experience with frameworks designed for technical teams?
    • Do we know how to do this?
    • How is leadership different?
  • Maaret Pyhajarvi
    keyboard_arrow_down

    Maaret Pyhajarvi - Next Level Teamwork: Pairing and Mobbing

    45 Mins
    Case Study
    Intermediate

    I know something you don’t know. You know something I don’t know. And I don’t know what you know that I would need to know. This is where individual contributor approach to software development and testing breaks down. Why aren’t we working together, contributing together and learning together? Why do we, often at best, collaborate on the requirements and understanding of what to build, and then step away for implementation, only to come back to test it after?

    This talk looks into my experiences in pairing (two people one computer) and mobbing (more than two people one computer), and the wonders of being a non-programming tester whose ideas get translated into code as equal. The journey to get to pairing and mobbing has been a rocky road, with loads of practical tips to offer on how to approach it.

    In software development, those who learn the fastest do best. Could pairing and mobbing take us teamwork to the next level by enabling learning between everyone? Lessons specific to skillsets rub in both ways, leaving everyone better off after the experience.



help