When it comes to agile many people get caught up with the adoption of particular frameworks rather than focusing on the goal of actual agility in work and releasing software.

In this session we'll discuss the fundamentals underpinning all frameworks -  maintaining flow and  explore how the choices you make impact it .

We'll reinforce each of your learnings with some simple simulations using dice and sticky notes that you can  then use with your own teams to teach the same concepts.

The best software is designed when teams collaborate to understand, prioritize and trade-off customer experience, business process, organizational and technology considerations. In this workshop, we will discuss modeling techniques that work together to enable practitioners to engineer robust solutions - for humans, by humans. 

Learn how Event Storming, a workshop-based approach from domain-driven design, can help engineers to better design software in collaboration,  not in opposition with business stakeholders. As we event storm to engineer robust, flexible, and extensible solutions, we'll also look at how to integrate human-centered design practices to identify so that the design responds to customer/user needs and key pain points.

During this session, we'll give you an overview of domain-driven design, and how event storming works, use case studies as an example. For those of you who've missed collaborative workshops and thousands of sticky notes, we'll also have multiple break out sessions where we'll put some of the theory into practice on example scenarios so you'll leave the session with some practical experience on how to apply the technique.

Team Charters are well meaning, but don't really change the way in which we build software. In this presentation I will talk about how we need instead to live by principals that drive how we design and build software rather than how we interact within a team.

Many agile teams begin their project creating a team charter that describes the behavioural expectations for the team. In my experience nearly all of my teams charters have been quite similar to each other. If an organisation places an emphasis on cultural fit during hiring, and continues to reinforce behaviours, this is even more likely to occur.

A team charter that states that people should collaborate, be respectful, raise concerns promptly and make time to play is repeating standards that are really part of an organization's culture, and often set the behavioural bar way too low.

Instead a A team charter should be a set of guiding principals similar to the Agile Manifesto that helps teams make decisions on how they are going to build software, and the sacrifices that they are willing to make to get the right outcome for the business.