In this talk I will make an introduction to Property Based testing concept, as a tool which does comprehensive quality exploration faster. By using PBT at one of my projects we were able to eliminate all the possible user interactions which could have caused unwanted results: production incidents and damages of data.
Property based testing is a popular concept in the world of functional programming. QuickCheck in Haskell is an iconic framework supporting this testing approach. Today we can find PBT libraries any main-stream languages, including Scala, JavaScript, Ruby, Python, Java, C# etc.
User interactions with your application are obviously constrained by the type of parameters accepted as an input of a program. However the range and the variety of these interactions can create large amount of use cases. Some of them you didn't even know existed in your application. With PBT you can generate all the variations of an input for your application and assess an expected outcome by running the tests. Discovering these cases on early stages of your development process brings quite a big support for 'building quality in' instead of ensuring the quality after an application has been created.

Agile Project Management is completely misled by some of those who practice the so called Agile. It is sometime assumed by them, Agile is the solution for all projects issues without making prior assessment into the project they handle.

The presenter will focus on 2 risk management tools for Agile project implantation which targets Agile suitability and Agile readiness.  Under the Agile suitability, the presenter will focus on the ESI Model which talks deeper into factors mentioned below in each area that forms the model

1. Organisations - Innovative, Independent, Risk Tolerance, Resource Allocation, Flexibility and Customer Focus
2. Team – Autonomy, Cohesiveness, Co-location, Customer Participation, Creativity and Skill Level
3. Leader - Customer Focus, Flexibility, Tolerance for Ambiguity, Communication, Commitment and Leadership (motivate the team, delegate, and resolve impediments)
4. Stakeholder – Flexibility, Availability, Risk Tolerance, Collaboration, Involvement and Knowledgeable

• Assess your situation and prioritize your needs;
• Surviving techniques for the hiring process;
• Assemble your own custom emergency kit with essentials tools;
• Manage extreme work conditions and overtime;
• Survive corporate parties and drinks;
• Build trust network and create allies; 
• Identify your enemies and their habits.

There is much discussion about the changing roles of Development and Operations staff when organisations undergo agile/digital/devops transformations. But what about the changing role of the Team Leader?

In pre-agile environments, as a Team Lead, your role is one of structure and co-ordination, it is through you that work routes. You know the skills and capacity of your team and are regularly making decisions about what can and can’t be done.

But as your team starts to work in agile teams, the need for you to keep them busy is reduced, as this is now a responsibility of the product owner and agile team itself.

You might find yourself asking “Do we need Team Lead’s in an agile/devops culture?”, and if so “What value can I provide?

This sessions looks at the opportunities existing Team Leaders have to support and drive digital transformation through the discussion of focus' they can bring to the team.

Mentorship matters. A lot.

The future is going to be weird: technologies are growing faster than we can teach them, and we need more experts quick. In this talk, we'll discuss the many ways we teach DevOps practices in an organization as analogues of how systems transmit data. We'll talk about the advantages and pitfalls of:

 - Broadcast systems (e.g., Universities)
 - 1:1 Discovery (e.g., Mentorships)
 - Gossip protocols (e.g., Communities and guilds)

We'll unpack each methodology, discuss the information dispersal mechanisms and attributes of each system, and see where they fit. Because really: DevOps isn't about technology choice, or language, or infrastructure. First and foremost, it's about people.

The Viable Systems Model (VSM) offers a systematic approach to diagnosing organisational issues and designing organisational structures in consideration of how the organisation adapts to its environment. This session will provide an overview of the VSM's insights and modes of use. 

We propose that enterprises can be considered to have three aspects: setting the strategy (direction), getting the work done (realisation), and structuring for sustainable effectiveness (organisation).

Popular contemporary frameworks for Strategy development include the Business Model Canvas and systems thinking approaches such as causal loop diagrams and system dynamics models.

Realisation methodologies include Lean and Six Sigma techniques for process improvement and BPM for process management, as well as specialist IT practices such as Agile and Enterprise Architecture. 

There appears to be a gap when it comes to methodologies for organisational design.

The Viable Systems Model (VSM), developed by Stafford Beer on cybernetics principles in the 1960s, offers a complementary, systems oriented, approach to the Organisation dimension. 

Stafford Beer's books are not widely available, and much of the discussion on the internet is highly technical and specialised. However, the basic concepts of the VSM can be very useful in analysing and designing organisational structures and interactions.

This talk will provide a non-technical introductory overview to the elements, objectives and application of the VSM, and will invite participants to consider its applicability to their own needs.

When we decide to move from big batch, plan driven long dated constructs of change, so projects and programs in the traditional sense, to more agile methods, we need to rethink a whole raft of stuff. Assume for a second, if you will, we are using the historical program and project construct to identify and deliver change. Initiatives are bundled into a sequential approach and governed through stages of largely documentation production accordingly. As long as you are on track to the stages, your documents are reviewed and signed off, you are Green.

Then we disrupt this. We want more agility on how we identify, plan, deploy and release change. We want to deliver outputs to our customers and ultimately value or outcomes earlier and more regularly, which is one of the significant advantages of an agile delivery model. So we get an ROI uplift. Projects can be self funded.

So lets start a new theory and trial it. EVERY project is red until your first release to a real customer. No more debate, hand wringing, angst or arguments. Recognise and accept that until you have delivered something that tests your theories, is validated and works, and your customers are using it, you have done nothing. Use the RED as it is meant to be - a call to action to pay attention, provide support , facilitate and break through barriers, provide resources and time. Help the team get to done.

My goal is for the attendees to use this session to actually crowd source and  develop a model that people can take back to their business and propose, from scratch using design thinking and agile techniques. 

Docker is an awesome container platform. As part of this talk , I would like to show and discuss , how it can help solve some of the common and annoying issues faced while testing . Namely :

• "It worked on my machine" problem
• Testing different configurations, with the same codebase
• Efficiently testing on your / dev's machine.
• Setting up the Continuous Integration Environment
• Scaling  / Parallelising Test Runs ( via Selenium Grid  & Docker Compose ) 

Join Shannon and Tim for a fast paced account of their move from being high-flying consultants to down-to-earth product people.

Where do they now add value? How has their relationship with their team changed? How many timesheets are they doing?

All will be revealed!

Which way is right? They all are. This talk untangles what these movements, mindsets, and approaches mean, and helps teams and leaders to choose the right bits at the right times, and bring it all together into one big happy collaboration.

The way we do product development constantly evolves and every few years, there’s a new wave of thinking that promises to be the secret key to doing it better. The 90’s saw the rise of the Agile movement for building software better. A bit later, the lean mindset shifted the focus to value creation for the entire organisation. More recently, Design Thinking has democratised design and brought it to the boardroom.That’s awesome! But it leaves leaders bamboozled by an unprecedented array of frameworks, methods and approaches – paralysing meaningful progress. Boots-on-ground practitioners are also confused about how to work with their colleagues from other camps too.

Can these approaches work together? How do we know if we’re doing it right? How does it all fit together? Could this work in my organisation?

This talk will help you find answers to your questions, bringing clarity to the topic, and some practical guidelines to help you find a way that works for you.

There are various reasons why we work with people across the globe and we know it can be very beneficial or very painful. We haven't yet invented Teleportation. Atleast not for the population that isn't working for CIA or NSA. So, we need ways to perform distributed work, where systems either appear "teleported" or they don't require teleportation. In this talk I will explain what tools and possible processes, tips, can teams follow for high quality distributed working. 

How do you approach first contact with a team you are about to coach? This is the question I will be posing in this interactive workshop session.

Through role play and discussion we’ll cover the typical responses you might encounter, including apprehension and fear, curiosity and even bravado.

You don’t have to be a coach to attend this session. It’s for anyone interested in how to succeed in first contact with a new team.

We’ll cover top tips for starting out right, and setting a path for a successful support role.

As Agile Practitioners we use experiments and retrospectives to gain insight into new and better ways of doing things. Change is at the heart of how we work, but how equipped are we to implement change?

The Change Management world is just beginning to recognise how useful Agile can be in supporting change. It’s time we in the Agile world looked to how Change Management can support us embed new ways of working.

Change resistance is one of the most difficult things we encounter. Rossabeth Moss Kantor, a change guru and Professor at Harvard Business School explains that “resistance to change manifests itself in many ways, from foot-dragging and inertia to petty sabotage to outright rebellions”.

In a world where the change that accompanies innovation is inevitable, overcoming resistance to change becomes imperative. Agile provides us with an approach to change that supports the way we need to work in the future.

Come along to this talk to:

• Understand why people resist change
• Learn how to use Agile techniques to overcome change resistance
• Increase your confidence in managing change associated with Agile ways of working

• a humble questions can be powerful
• the best way to learn is to teach someone else.

This session is a case study of how to apply Scrum and Systems thinking to a small development and support group working on multiple products at the same time. Scrum explains how to organise a single team working on a single product. Scaling frameworks such as Safe, LeSS, Nexus & DAD provide ways for multiple teams to work on a single product, but what do you do when you have multiple products and one siloed team?

From the outside Spotify is a company who has solved the riddle of scaling agile, but the insiders perspective might surprise you, with our structure more closely resembling a collection of startups sharing a wifi connection.

What's in a story? Perhaps more applicable to agilists today, what's in a user story?

Let's get real about user stories and what they are trying to achieve. Perhaps the user story is not the story format we should be using!

Let's examine the user story format that we all know and love today. We will dive a little deeper into how a story and personas can create synergy. We will discuss how a user story can be presented on a ticket and how stories can be supplemented with information like acceptance criteria.

Of course something so widely used will have anti-patterns. Let's look at a few and have a few laughs as well.

Let's go even further and talk about user story alternatives, I will propose two. But wait! Are there even other user story alternatives? I will introduce two more.

Finally, let's sum up the purpose of the user story and conclude with the central idea that's really important - your story can be anything you want it to be!

The web is increasingly becoming the standard way in which we conduct our business, but despite the use of ever improving technologies many websites are frustratingly slow and getting slower. It is becoming more difficult to compete for and retain users attention, and If you operate in the online space you can no longer afford to ignore the performance of your website or platform.

This talk will provide an introduction to and the benefits of web-performance optimisation, explain why it matters now more than ever and why it's so commonly overlooked during the development process. It will also show how you can identify and fix the most common performance pitfalls, resulting in reduced costs, and increased user engagement and satisfaction.

During this talk there will be an opportunity to follow along on your own laptop and learn how to use some of the tools firsthand.