The art of facilitating great collaborative workshops

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.

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

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.

Marcio Sete - The Ten Principles of the DevOps Movement

schedule 1 year ago

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:

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

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

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

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

There is just one lifecycle, the business one.

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

Focus on a strategic Business Applications and improve continuously.

Create your own unicorn!

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

Share the results. Help people believe they can also help change the world!

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

schedule 1 year ago

45 mins

Talk

Beginner

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:

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

schedule 1 year ago

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)

Ryan McKergow - Continuous improvement at scale

schedule 1 year ago

Sold Out!

45 mins

Talk

Intermediate

Retrospectives are one of the most effective continuous improvement practices, but how do you scale them beyond your team? This is the problem I faced with running regular retrospectives with more than 50 people. And with many large organisations scaling agile or adopting the likes of SAFe we are going to run into this problem much more frequently. After all we must not forget that agile is underpinned by the ethos of reflection and improvement.

During this talk, I will discuss how companies like Spotify & Atlassian have implemented scaled retrospectives, and where their stories have helped us and what didn’t work for us. I will share some practical tips on how we’ve run awesome scaled retrospectives and avoid wasting everyone’s time. Learn how you too can improvement your entire organisation, not just your development teams.

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

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.

Naresh Jain - Agile Testing

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.

schedule 1 year ago

Sold Out!

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.

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.

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

schedule 1 year ago

Sold Out!

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.

Ranjith Tharayil - When to embrace Behaviour Driven Development?

schedule 1 year ago

Sold Out!

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.

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

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

schedule 1 year ago

Sold Out!

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: