From zero to happiness - A practical Kanban experience in an Ops Team

This talk is about a story of an OpsTeam, working in a multi-million Cloud project, looking for a Project Manager to support them. What did they get? An Agile Coach instead!

I'll share how this experience has been, the bootstrapping, what worked well, what didn't, the peculiar challenges of an OpsTeam and how we are increasing our happiness index every day using the follow strategy:   

#1 – Visualize the work

#2 – Reduce batch sizes to improve flow

#3 – Collaborate to win

#4 – Make sure we are doing the right thing and just the right thing

#5 – Collect tangible results

#6 – Run different feedback loops 

#7 – Celebrate quick wins

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

Outline/structure of the Session

 

4 min - Introduction

5 min - #1 – Visualize the work

5 min - #2 – Reduce batch sizes to improve flow

5 min - #3 – Collaborate to win

5 min - #4 – Make sure we are doing the right thing and just the right thing

5 min - #5 – Collect tangible results

5 min - #6 – Run different feedback loops

10 min - Q&A

1 min - Thank you

Learning Outcome

  • How to create different types of boards.
  • The power of small deliverables
  • Kanban metrics that matters
  • The happiness Index
  • The relation between WIP, Throughput, Leadtime and happiness

Target Audience

This talk is pretty much for anyone interested in achieving Team's High-Performance combined with People's Happiness

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Michael Chik
    keyboard_arrow_down

    Michael Chik - Test

    45 Mins
    Talk
    Beginner

    Test

  • Liked Jas Chong
    keyboard_arrow_down

    Jas Chong / Guillaume Duquesnay - PRODUCT OWNER & DEVELOPMENT TEAM – A TANGO IN COMMUNICATION

    60 Mins
    Talk
    Beginner

    With over 5 years in the practice of tango, I would like to use tango techniques to explain the nuances in communication between product team and dev team. It’s not often straight forward or easy.

    Tango is an extreme dance in coordination and non verbal communication. it is also not the kind of dance that can be guided by strict rhythm like salsa. Instead, it’s a decision between both dancers on how fast or how slow they want to take it. It is also one of the few dances where pauses are encouraged and takes the form of regrouping.

    I’ll be using experiential learning to demonstrate techniques in communication. (Note: it’s not a tango lesson but a communication workshop using tango.)

  • Liked Yun Ki Lee
    keyboard_arrow_down

    Yun Ki Lee - Avoiding Test Hell (with examples from FitNesse)

    Yun Ki Lee
    Yun Ki Lee
    Senior Development Specialist
    HSBC
    schedule 1 year ago
    Sold Out!
    45 Mins
    Experience Report
    Beginner

    We are entering a world where everything must be done quicker. You must deliver code faster. You must deploy faster. How can you deliver and deploy faster without compromising your professionalism? How can you be sure you are delivering what your client has asked you?

    In short, testing is the only way to be sure you're delivering what someone asked you to. Often we use BDD Tools such as FitNesse which gained popularity over the recent years

    There are a number of integration / BDD test tools out there that help you deliver a high quality software through tests. Its easy to pick up any tool from just their tutorials and start writing tests. But as I found out the hard way, this can quickly spiral into a state where the tests are giving you and your team hell and are worth less than the value the tests are delivering.

    Using FitNesse and Junit as examples, I will share things that I have learnt working on large enterprise and vendor systems and help you avoid your own path to hell.

  • Liked Teng Daniel
    keyboard_arrow_down

    Teng Daniel - Awakening Change - Influencer's Toolbox to Make an Sticky Impact

    Teng Daniel
    Teng Daniel
    Awakener
    Odd-e
    schedule 1 year ago
    Sold Out!
    60 Mins
    Talk
    Advanced

    If you give kids broccoli and tell them it is good for their health. Most likely, you will still get a no. The reason is quite simple, little kids don't care about being healthy. This broccoli principles applies to agile adoption as well. Simply telling and pushing new ideas and practices don't help very much because It is about changing people's mindset and way of thinking. Push and enforcement will always get resistance. The more push we have, the more resistance we will have as coach or change agent. To make it even worse, each individual, team and organization are so different, the culture is different, the business situation is different, the technology is different. Those are perfect excuses for not to change. One key factor for successful and sustainable adoption is to lit the desire to learn and improve, from individual, to team, to organization level. Rather than being pushed a lot of ideas, team will come for help and guidance, to pull idea from coach then apply in their context. 

     

    It is crucial to understand coachees based on their receptance of ideas. Who are the innovators, who are the early adopters, who are in the early majority and who are in the late majority. Based on the categories, as an agile coach, try to apply various tools to influence the change. 

     

    I presented early version of this talk at Scrum Gathering Paris and Beijing in 2013. 

  • Liked Marcio Sete
    keyboard_arrow_down

    Marcio Sete - The Ten Principles of the DevOps Movement

    Marcio Sete
    Marcio Sete
    Agile Coach
    Elabor8
    schedule 1 year ago
    Sold Out!
    60 Mins
    Talk
    Beginner

    It looks like that DevOps has hit the Mainstream. Gartner says by 2016, DevOps will evolve from a niche to a mainstream strategy employed by 25 percent of the Global 2000 Organizations.

    This means that the DevOps Movement has already begun to be treated as a mainstream market, with vendors enjoying a toolset market that reached US$2.3 billion in 2015. Besides that, a whole ecosystem has been created in order to surf the DevOps wave. Certifications, events, communities, portals, media companies, marketing speeches, roles, self-promotions and more among others.

    This talk is about the 10 Principles of the DevOps Movement. I will attempt to strip DevOps back to its bare essentials and explain the core principles of this great movement, which is definitely changing the digital business game around the World.

     

    Here are the principles of the DevOps movement, covered in this session:

    1. DevOps is a Journey. You will never get there. It never ends...

    2. DevOps is not just about tooling and automation. You’ll need far more to achieve business high-performance and people’s happiness

    3. Achieve a state of flow! The secret is doing small and frequent changes.

    4. As a Team, everybody should be working on the same process, technologies and script languages.

    5. There is just one lifecycle, the business one.

    6. If the business is not involved, believe me, you are not doing DevOps!

    7. Focus on a strategic Business Applications and improve continuously.

    8. Create your own unicorn!

    9. Do whatever needs to be done to help the business win!

    10. Share the results. Help people believe they can also help change the world!
  • Liked Marcio Sete
    keyboard_arrow_down

    Marcio Sete - The Ten Mindsets that are (probably) killing you

    Marcio Sete
    Marcio Sete
    Agile Coach
    Elabor8
    schedule 1 year ago
    Sold Out!
    60 Mins
    Talk
    Beginner

    Almost everything we know about Management comes from the 20th Century. At least, everything you have rooted in your way of thinking and acting indeed comes from that period.

    Everyone who is managing complex systems today created their toolboxes using the knowledge acquired in the last Century. 

    The Knowledge Work industry has emerged so fast in the last two decades, that our society didn't have enough time to learn and spread a whole new management model, compatible with the challenges of the 21st Century.

    We are still using today the same mindset we used to apply when we were dealing with manufacturing industry' challenges.

    This talk aims to help you to be careful not to fall into the trap of using management practices that are incompatible with our reality today. 

    Let's talk how to go:

    • from the Analytical Thinking to the Systems Thinking
    • from the Defined Process to the Empirical Process
    • from the Mechanism (Command & Control) to the Organism (Emergent Culture)
    • from the Efficiency Mindset to the Effectiveness Mindset
    • from Big batches to Small batches
    • from the Commission Error mindset to the Omission Error mindset
    • from the Solution Focus to the Problem Focus
    • from the Occupation Management to the Flow Management
    • from the Push System to the Pull System
    • from the People Efficiency mindset to the Process Efficiency mindset
  • Liked Hugo Messer
    keyboard_arrow_down

    Hugo Messer - Why distributed teams don't work and what to do about it

    Hugo Messer
    Hugo Messer
    Entrepreneur
    Ekipa.co
    schedule 1 year ago
    Sold Out!
    45 Mins
    Workshop
    Intermediate

    Based on 10 years distributed agile experience, Hugo's distilled 5 core problems in distributed software development. To find solutions, he's gathered data from hundreds of practitioners and wrote 6 books about remote teams. In this workshop, participants will learn practical solutions to make distributed teams work better. 

  • Siraj Sirajuddin
    Siraj Sirajuddin
    Co-Founder
    Temenos+Agility
    schedule 1 year ago
    Sold Out!
    90 Mins
    Workshop
    Executive

    Enterprise Agile Transformation initiatives are BIG. Change at this scale of thousands is tough.

    The Leaders and Executives involved in these initiatives are going through their own personal transformation. Change at this scale of one is equally tough.

    Siraj Sirajuddin has worked with hundreds of executives leading enterprise agile transformation initiatives. These are their stories of personal growth and individuation. We will hear how transformation at a personal level is the leverage for transformation at a collective level. We will also learn of unique methods that activate personal transformation for leaders who are ready to step into their leader persona but are unable to get that from traditional leadership training and coaching methods.

  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

  • Liked Balaji Ganesh N
    keyboard_arrow_down

    Balaji Ganesh N - Doing Agile vs Being Agile - Sins and epiphanies from my agile journey

    45 Mins
    Talk
    Beginner

    There are so many organizations and product teams that are embracing agile implementation methodologies as a means to accelerate product development for competitive advantage and customer delight. Agile is now more than a fad or a buzzword.

    Despite all this pervasiveness and penetration, there are only some teams for whom agile works well, whereas it doesn't work so well for some of the other teams and it fails for the rest. 

    But, is the problem really with adopting agile or is it something else? After all, agile is a mirror.

    As Leo Tolstoy once said, "All happy families are alike; each unhappy family is unhappy in its own way.” There is a lesson to learn from every failed implementation.

    From the 9th "State of Agile" survey done by VersionOne in 2014, in cases where agile projects were unsuccessful, 44% of the respondents pointed to lack of experience with agile methods.

    Drawing from my experiences through my journey as a lean agile coach, this is an attempt to collate the anti-patterns (sins) associated with "lack of experience with agile methods" within the teams implementing agile and possible solutions (epiphanies) to overcome them. I believe that addressing these anti-patterns and preventing them from happening in your teams would significantly enhance the probability of succeeding with your agile implementations. Establishing the purpose and aligning the teams with the organization strategy is one of the key determinant of success. Due to time constraints, I would be focusing on 3-4 anti-patterns (points 1,7,8,9)  that are commonly seen while touching on the rest of them briefly.

     Details are given below:

    1. Square pegs in round holes- These are role anti-patterns and arise by looking at Scrum Master / Product Owner as positions to fill rather than identifying and assigning the right person for the job and abrupt transitions from PM / architect to SM / PO creates this anti pattern. It is important to ascertain the fitment and identify the right person with the attributes of a servant leader who can influence the team without authority, empathize, ask the team the right questions which would empower and enable them to become more self-organizing and step back when required. In cases where a transition is involved adequate training / coaching needs to be provided to smoothen the transition.

    2. Ineffective retrospectives - Retrospectives are treated more as a ritual with no feedback loop to the planning process. Ineffective retrospectives are good at addressing the person and not the problem, creating actionable without owner(s) and timelines, have no focused outcomes and create a "blame game" culture.

    3. Sub-optimal local execution - This is reflected in product teams / modules / component not aligned at the global / program level and is primarily due to misalignment of the teams during planning, no vertical slicing, poor dependency management,  inability to create cross functional teams, no single product backlog, infrequent touch points across the teams with no day to day interaction. This typically results in teams following the sprint cadence but not creating any working deliverable at the end of the sprint.

    End to end optimized execution is possible only through creation of flow across the entire product line. As a first step, it helps to visualize the workflow and understand the work in progress across the various sub-systems to surface the bottlenecks. Cumulative Flow Diagram (CFD) is one of the powerful tools that help identify bottlenecks across the system.

    Some general techniques that help address bottlenecks are identifying the right features (Kano model and user satisfaction matrix) and then vertical slicing to create a working deliverable every sprint, having a single Chief Product Owner (Scaled Scrum) who owns the overall product backlog and ensures priority and value alignment with each team's backlog, synchronizing the iteration time-boxes to ensure that dependent user stories are delivered in the same sprint as much as possible, investing in building relationships and trust among teams (investing in kick-off meetings and face to face engagement), creating a scheduled daily cadence for points of alignment like daily scrum of scrums (weekly inter-team sync-ups would be a killer for teams working on 2 week sprints), usage of tools like Design Structure Matrix (http://dsmweb.org/) for the right development sequence during planning / accurate impact analysis and complexity assessment alleviates this anti-pattern to a large extent.

    Other aspects to address include the team structure and alignment. Executing cross skilling plans levels out workload and integrating business + dev + QA ensures that the right product is built right and reduces failure load significantly.

    4. Dysfunctional team  - This typically happens due to trust deficit. There is typically no daily engagement with the team and team is comfortable with conflict avoidance. Understanding the team (Use tools like Pat Lencioni's 5 dysfunctions of a team), managing conflicts effectively, creating conditions for constructive confrontation, rewarding team collaborative behaviors goes a long way in creating trust, confidence and collective responsibility.

    5. Dis-engaging Daily Standups - Typical anti-patterns here include scrum meetings that overrun significantly beyond stipulated time, team members reporting status to the Scrum Master and not the team, impediments not raised in the meeting, dis-engaged team members. Visualizing the work, raising and tracking impediments, being sensitive to the time zone differences and accommodating them, investing in technology that helps enhance the engagement / involvement levels of the complete team helps make the daily scrums more effective.

    6. Unaligned Process model - Team members frequently pulled into firefighting and production support activities with no regard to the commitments made. There is a need to introspect if time boxed sprint is the right way to go for teams in this case or would a different approach like Scrum+ Kanban (ScrumBan) work better ? There are also cases where heavy weight ALM tools are used for short duration engagements or small teams just because of the availability, without any training or regard to the ROI.

    7. Product Owner - Team misalignment: This is typically manifested in busy product owners (Example -: product owner spending time in too many  discussions with the client, Product Owner for multiple teams) for whom this is an additional responsibility apart from their day jobs, mismatch between the product owner's expectations and the team's expectation, disruptive product owners who do not appreciate or understand the team's challenges, team's velocity not factored in release planning by the product owner. Ensuring that a product owner is not assigned for more than 2 teams, business analysts in the team interfacing with clients to see what the market needs leaving the responsibility of the technical product to the actual product owner, proxy product owner who is empowered to take decisions in the product owner's absence are some of the strategies that ensure enough bandwidth is available for the POs to collaborate effectively with the product team and focus on effective product delivery.Appropriate budgeting for PO during the pre-planning phase, sensitizing the product owners through more face time with the team, identifying  chief product owners for alignment across multiple teams (scaled scrum), proxy product owners are also additional strategies that can address this situation.

    8. Not building the right thing - As Drucker said "There is nothing so useless as doing efficiently that which should not be done at all". . Appropriate widely used techniques / frameworks (Value Stream Mapping, Value-Risk mapping, Risk Based Testing, Design Structure Matrix, Product-Market fit decision frameworks, Kano model) for identifying the right thing to implement, prioritize and eliminate waste would help tackle this antipattern.

    9. Cultural anti-patterns - Typical issues observed here includes -Teams not aligned to the organizational goal / purpose of the program,  non-collaboration across teams, offshore team treated as a "B" team,lack of T shaped skills, inappropriate performance / R&R systems that reward individual success over team success, irregular or inconsistent sprint cadence, student syndrome, using velocity as a tool to compare performance across teams, abrupt transition from project manager to scrum master role, management looking at agile as a tool to overwork the teams, poor ALM tooling strategy and non-alignment across the teams.

    Why is alignment important ? Because one of the important components of ownership is knowing "What to own ?". In surveys with the top management misalignment of the team's goals with the organizational goals comes out as a top response.

    Some symptoms of a poorly aligned team include: poor or failed execution, lack of clarity about priorities, low morale, absence of healthy debate, lack of ownership or follow through, underground communications (gossip, “us versus them” thinking)

    Usage of surveys like the team alignment questionnaires, Scrum Butt questionnaire, team assessment versus the 12 agile principles surfaces points of mis-alignment and dysfunction across the teams

    Some solutions to address cultural dysfunctions include usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) to establish the team's purpose, creating cross-functional teams that can get to “done” in each location, recognizing and rewarding adaptive collaborative change behaviors (cross skilling, taking initiatives in supporting team to overcome impediments, helping others cross skill, breaking boundaries for effective problem solving) to reinforce these behaviors,  assessing current project managers and ensuring an effective transition into agile roles through 1:1 coaching (for transforming  smoothly from command and control to servant leadership), effective management of time zone differences in distributed teams to ensure appropriate rotation of meetings / discussions so that one of the teams does not burn out, top down approach to sensitize management and make necessary changes to the organizational structure and career roadmap  for accommodating agile roles like Product Owner, Scrum Master, agile program manager etc.. , adopting objective metrics like Time to Market (TTM) and business value accrued to measure effectiveness.

    As Eliyahu Goldratt once mentioned "Tell me how you will measure me and I will tell you how I will behave". Therefore, look into your performance systems first if you come across any dysfunctional behaviors. One cannot expect a person to display collaborative behavior, if the performance system encourages and rewards individual success over team success.

    10. Surfeit of Metrics  - Team tracks too many metrics that are not relevant and are inherited from waterfall mindset. There is also an obsession for effort tracking at the individual level and % complete’s. Burn-up charts, velocity, committed vs achieved ratio, defects per sprint are just enough metrics for effective tracking.

    11. User story anti-patterns - Teams do not put in efforts to refine the product backlog as it is seen more as a cost than an investment. There are multiple product backlogs and definition of ready is not agreed between the PO and the team. This results in large user stories that cannot be completed in a sprint, wait times for clarifications and things getting put on hold a few days after implementation due to lack of adequate inputs. Agreeing on a Definition of Ready (DoR) and coaching the team / PO on patterns for splitting user stories helps overcome these barriers

    12. Agile Manifesto Delusion - This typically manifests as no documentation, no Definition of Done, multiple disruptions during the sprint to accommodate changes etc... Helping teams understand and interpret the agile manifesto and principles in the manner in which they were intended creates clarity and helps obliterate this anti pattern. 

    At the end of the day, it is all about delivering valuable working software in an incremental manner. Hence principles should always take precedence over practices and tools. We, from the agile community have a big part to play in helping to realize the above and breaking the above barriers for successful agile adoption. 

  • Liked Joseph Yao
    keyboard_arrow_down

    Joseph Yao - Mutation Test - A New Way to Improve Code and Test - More Information

    45 Mins
    Talk
    Beginner

    Mutation test is a way to put a "mutation" into your code, run the test and then see if the test fails or not. A mutation is a change to production code which should make it behave in a different way. The idea is, if the production code is just enough to pass the test, any mutation should make the test failed due to the behaviour change. If test failure doesn't happen, we will say that the test can't kill this mutation. Therefore, some test code smell or production code smell exists, which possibly leads to some learning and improvement of our code and test.

    By TDD, we should get "just enough" code that passing all the test. But, how do we know this? Sometimes, since writing test and code is so interactive in TDD, we may not choose the smallest baby step to pass the test. This means we may write some code which is not driven by current test (code smell). On the other side, we may even miss some important test or create some “weak” test by TDD because the code is too “obvious" to us (test smell). By applying Mutation test mindset and methodology, we can identify such code smell and test smell and then help us improve the quality of our code and test.

    In this topic, I will first introduce what mutation test is and why we can use it to create some learning of and improve our code and test. Then, I will share a real code example in which I tried the mutation test and some learning I got. Finally, based on what I learned so far, I will have a summarisation about the code smell and test smell which can be detected by mutation test.

  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - When to embrace Behaviour Driven Development?

    45 Mins
    Talk
    Intermediate

    Abstract

    Behaviour Driven Development (BDD) is a collaborative and disciplined technique to help us build the right product. In the last decade BDD has had her own bit of glory and criticism. Many teams in the recent past have reaped benefits from this technical practice, while some teams complain that are yet to find any value. This article focuses on answering two questions; Why BDD might not always be the right choice? What are the ideal conditions when teams should adopt it?

    In this talk we come up with a BDD adoption matrix to help us answer the above questions. We also assert that for successful product development it is crucial to bridge the gap between the problem space and solution space, each of which has its own set of complexities. We conclude that Behavior Driven Development can be one of the effective techniques to bridge this gap especially if the problem space is complex. In case the problem space is simple it might be an over kill and teams might not find real value practicing BDD. We also observe that teams whose problem space is simple can continue to document scenarios and automate acceptance testing but they need not spend elaborate time and effort towards discussing and debating scenarios.

     

    Preface about the talk 

    Behaviour driven development has been a buzz word in the recent years and many teams are adopting it. The core of BDD is the collaboration angle that enables teams to build the right product. As a side effect BDD gives you a very essential output, which is an automated acceptance test suite. BDD team members work together in identifying different scenarios elaborated in the form of examples. High performing teams ensure through working agreements to only pull those features in which scenarios are well defined. These scenarios define the acceptance criteria of the feature. The scenario identification process involves full team participation and in these meeting its essential that the three amigos i.e. the entire development team, QA engineers and product owner should participate.  Along with the three amigos any other members who can constructively contribute in scenario identification are also welcomed.

    During these interactions technology facing members get a better understanding of business and vice-versa. It has also been observed that identifying and discussing scenarios helps the team in analysing and studying the feature in much detail. Many teams benefit from this practice as it helps them shape their product ,  saying so few teams are yet to find value in investing time and effort towards these meetings and ceremonies . One should keep in mind that for BDD to be effective we require full team participation.

    In this talk I am making an assumption that these teams who are not finding much value in adopting BDD, were practicing it in fullest of its spirits and not just documenting scenarios for creating an automated test suite. This talk doesn’t discuss on how to effectively practice BDD, as it’s out of scope. This  talk will throw some light on why BDD might not always be the best fit for all type of product development.

  • Liked Ryan McKergow
    keyboard_arrow_down

    Ryan McKergow - The art of facilitating great collaborative workshops

    45 Mins
    Talk
    Beginner

    We can no longer afford to work independently of our customers. In order for teams to deliver great outcomes to them, we need to collaborate with them. Agile encourages collaboration via many different workshops instead of treating requirements as a constract. But, running these workshops can be hard. In order to ensure we don’t waste time, we need a strong facilitator.

    In this talk, I want to share with you some of the tips and techniques that I have learnt over the years when it comes to running great collaborative workshops. We will go through some of the key Agile workshops: Project Inceptions, 3 Amigos sessions, Story Kick-offs, Retrospectives and more. You too can learn the art to facilitating great collaborative workshops.

  • Liked Danielle Jabin
    keyboard_arrow_down

    Danielle Jabin - Measuring Team Performance At Spotify: From Gut Feel To Hard Data

    Danielle Jabin
    Danielle Jabin
    Agile Coach
    Spotify
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    How do we actually know if our teams are doing well? Is gut instinct enough? Furthermore, in a rapidly growing organization such as Spotify, how can we ensure some sort of consistency in our baseline level of Agile knowledge across the technology, product, and design organization? 

    In this talk, I’ll discuss techniques we have developed and use at Spotify to benchmark health and performance for our teams and some tactics we use to bring them closer to—and beyond!—being the best teams they can be. I’ll explain frameworks that can be used to give us tangible evidence about how we’re doing as teams, as Agile Coaches, and as managers of people and product. Furthermore, I’ll tell you about the organization-level methods we use at Spotify to share knowledge and maintain alignment of our agile practices as we scale in order to bring music to people all around the world

  • Liked Timothy Lok
    keyboard_arrow_down

    Timothy Lok - Making use of both Scrum & Kanban

    45 Mins
    Talk
    Intermediate
    1. What is Scrum and Kanban?
    2. Comparing between Scrum and Kanban
    3. How to get the best of both worlds? Scrumban
    4. What are the best practices in Scrumban?
    5. Q&A

     

  • Liked Guillaume Duquesnay
    keyboard_arrow_down

    Guillaume Duquesnay - From Developer to Scrum Master : 5 keys for starting

    Guillaume Duquesnay
    Guillaume Duquesnay
    Agile Coach
    Palo IT
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    New Scrum master coming from the technical world, this session is for you.
    Regarding code, architecture, configuration, you're learning continuously. But there comes a role whose essence is absolutely not technical, and suddenly learning seems hard. And by the way, your teammates are counting on you, not to mention your boss. Feeling some pressure, dude ?

    Based on the difficulties that new Scrum Masters usually faces, heres a few recommandation to get you a maximum confidence at start. Most are focussed on the retrospective facilitation, but the underlying principles can be applied to your whole action in the project.

  • Liked Guillaume Duquesnay
    keyboard_arrow_down

    Guillaume Duquesnay - 5 powerful practices that are little known but work out-of-the-box

    Guillaume Duquesnay
    Guillaume Duquesnay
    Agile Coach
    Palo IT
    schedule 1 year ago
    Sold Out!
    45 Mins
    Experience Report
    Beginner

    At the beginning was the Book of Agile. From there people learnt and teach agile practices. Along the way a natural selection has come, brought by continuous improvement. Some practices were improved, some abandoned, some new one introduced.

    As an agile coach I consider a personal duty to observe and contribute to this natural selection. What are the practices that works the most ? What are those that are hard to catch or don't bring much result ? Am I bringing teams the best for them ? 

    Looking back at my years of practicing and coaching, something struck me : some of the best practices I've seen working are just dead simple, but little known. And most them are roughly universal, no chit-chat, no bickering, no learning curve, you pick them and they're useful in your context 95% of the time.

    So as a way to push forward the natural selection of practices, I'd like to share my top 5, the easiest-to-get-but-most-powerful practices I’ve seen working. As an attender, I expect you to come with all your critical mind, we're here to raise natural selection, right ? So If you hear something that didn't work for you, raise your voice, I've saved 15' of Q/A just for that.

  • Liked Jas Chong
    keyboard_arrow_down

    Jas Chong - Don't waterfall your agile transformation

    Jas Chong
    Jas Chong
    Agile coach / Scrum Master
    IBM
    schedule 1 year ago
    Sold Out!
    30 Mins
    Talk
    Beginner

    The stories of agile transformation are many, some funny, some painful, some frustrating, some motivating. It feels like colours of the wind and often I'm inspired to write books about the adventures in change management. 

    Very often, when a bunch o friends and colleagues sat together to share camp fire stories of agile transformation, 2 phrases circulate in my retrospection of the many stories. 

    From Einstein who said: The very definition of insanity is doing the same thing over and over again expecting a different outcome. 

    From Sun Tze who said: know yourself and know your enemy. 

    The main challenge is that if you've only known waterfall method, then you are likely to do agile transformation in a waterfall way. How can you know what you don't know and implement that which you are learning to know? And then naturally, you'll fulfil what Einstein said, doing something in the way you know over and over again expecting a different outcome. 

    Even agile practitioners are not spared in this trend. It's often easy to recognise software development cycles that are waterfall or agile. But in change, when the impact is team set up, stakeholders management, it's not easy to recognise when you had used waterfall and when it is agile. 

    For eg. If in your agile transformation, you have not used a pilot to test assumptions, you've probably don't it waterfall. 

    For eg. If in your team set up, you've written the job descriptions by yourself or by your HR, you've probably not used agile in your transformation. 

    I'd highlight some blindspots we have, gathering all the camp fire stories from friends and colleagues to share and help us be more aware of it. 

  • Liked Sylvain Mahe
    keyboard_arrow_down

    Sylvain Mahe - How to gain control by letting go? A toolkit to shift from manager to leader

    45 Mins
    Talk
    Intermediate

    I used to work as a Program Manager on a large waterfall project. I spent my day assigning tasks to people, tracking progress and trying to prevent the next crisis. I thought that was the normal life of a Program Manager.

    I was wrong. Agile proved me it can be different.

    In this talk I will share the tools, books and trainings that helped me change my perspective and become a better person in the process:

    • Why let it go from the command and control mindset?
    • Which tools can you use as an Agile leader?
    • Why trust is the foundation?
    • Why self-awareness is key as an Agile leader?
    • Am I a roadblock in the Agile adoption initiative?
    • Why we have no choice (the generation Y is knocking at the door)?
    • How can I become the coolest boss?

    This talk is part of the Toolkit series.

  • Liked Christophe Muratet
    keyboard_arrow_down

    Christophe Muratet - Let's practice Kanban for software, let's play getKanban!

    120 Mins
    Workshop
    Intermediate

    GetKanban is a an empirical introduction to kanban through board gaming.

    2 teams of 6 people team up as 2 startups competing (~3hours) to build a new 'revolutionary' app as fast as possible. What team will shorten time to market and win it all?! But wait things don't come easy, delay penalty, evil test manager and sick developer will spicy up the challenge.

    On same principle of MiT beer game, getKanban is ideal introduction to pull scheduling, WiP limit, lead time, in others words "K"anban for software.

    https://getkanban.com/

    Note: not sure this workshop fits in agile conf agenda, perhaps for a coming meetup instead