High performing organizations don't trade off quality, throughput, and reliability: they work to improve all of these and use their software delivery capability to drive organizational performance. In this talk, Jez presents the results from DevOps Research and Assessment's five-year research program, including how continuous delivery and good architecture produce higher software delivery performance, and how to measure culture and its impact on IT and organizational culture. They explain the importance of knowing how (and what) to measure so you focus on what’s important and communicate progress to peers, leaders, and stakeholders. Great outcomes don’t realize themselves, after all, and having the right metrics gives us the data we need to keep getting better at building, delivering, and operating software systems.

If you’re a software developer or architect who wants to play a more influential role in ensuring your software systems are optimised to support business goals, then you need to learn about the benefits and techniques of modern strategic domain-driven design.

Many people think that DDD is about software design patterns, but that’s only a small part, and the least important part of DDD. In fact, Eric Evans wishes he’d focused more on the strategic aspects of DDD in his famous book (Domain-Driven Design: Tackling Complexity in the Heart of Software) and pushed the tactical coding patterns to the back!

Strategic domain-driven design is about truly understanding the business domain. It involves collaboratively modelling business processes using advanced modelling techniques, like Event Storming and Domain Storytelling, with domain experts on an ongoing basis.

One of the core outcomes of strategic DDD is identifying cohesive modules, known as bounded context. Bounded contexts help you to create a maintainable, comprehensible codebase by isolating dependencies and delineating concepts that reference different classes of business value.

In this talk, you’ll see many of the most effective bounded context design heuristics, recurring patterns in the wild, and you’ll learn how to facilitate those vital modelling sessions so you can lead the adoption of strategic DDD in your organisation.

People are unique in their ability to use symbols and images to communicate. After all, that is where the saying “a picture is worth a thousand words” comes from. So, it shouldn’t come as a surprise that enhancing your spoken words with pictures improves the chance that others will understand what you are trying to say.

A picture has a way of showing ideas and solutions that would have remained hidden if you hadn’t picked up a pen. But a good picture doesn’t remove the need for words. It reduces the number of words we use so that the ones left behind are the most important…

So why is visual thinking so important?

Recent studies show that 65% of people learn and retain more information by seeing words - as well as images! In contrast, only 30% of people learn through verbal communication alone. So if you aren’t one of the 65% of visual learners, someone in your team is!

Incorporating visual thinking into your day to day work can:

• Reduce the length of meetings by 24%, by providing a shared record of the discussion
• Capture emotions, making conversations easier to remember
• Help others see the "big picture", by creating powerful visual metaphors
• Serve as a reminder of actions agreed by the team

Luckily, you don’t need to be an artist to think in pictures! Join us as we co-create a visual vocabulary you can apply to work or during studying and learning. We will take you through the essential elements needed to create powerful visual concepts.

No more PowerPoint slides needed!

We like to say that agile teams own their own process by choosing their way of working, their “WoW.” This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?

There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of “agile coaches.”

Organisations invest in agile processes, tools, training, and coaching, but how much are they getting back?

Has product delivery improved?

How much happier are users and the business customers?

Are employees empowered and enabled?

Traditional metrics might give you insight into improvements of operational efficiency, but the real conversation is about the value created for your organisation by the improved processes. Without measuring value, the success of any agile initiative is based on nothing more than intuition and assumption.

Evidence-Based Management (EBM) is a framework to help measure, manage, and increase the value derived from product delivery. EBM focuses on improving outcomes, reducing risks, and optimising investments and is an important tool to help leaders put the right measures in place to invest in the right places, make smarter decisions and reduce risk using an iterative and incremental approach. This empirical method alongside the agile principles and values of Scrum enables successful steps of change for the organisation.

Organisations invest in agile processes, tools, training, and coaching, but how much are they getting back? Has product delivery improved? How much happier are users and the business customers? Are employees empowered and enabled? Traditional metrics might give you insight into improvements of operational efficiency but the real conversation is about the value created for your organisation by the improved processes. Without measuring value, the success of any agile initiative is based on nothing more than intuition and assumption.

Mia will discuss Evidence based management and how this empirical process can help agile transformations measure and manage the value derived from the transformation initiative. Mia will focus on the 4 Key Value Areas: Current Value, Ability to Innovate, Unrealised Value and time to market and how these contribute to an organisation’s ability to deliver business value.

Agile Management, many books, and blog post are written about it, but how do you really do it? What are the tools that you can
use?

In this workshop, we are gonna experience some of those tools by actually using them.

We will start the meeting with what is Agile Management all about. However, we will quickly switch to the games and tools.

The games, practices, and tools we discuss are:

• Delegation Board, delegation is not easy. Delegation boards enables management to clarify delegation and to foster empowerment for both management and workers.
• Moving Motivators, Moving Motivators can be used to identify the impact of motivation and how motivation it is affected by an organizational change.
• Personal Maps, A great exercise for a better understanding of people is to capture what you know about them in personal maps.
• Team Competence Matrix, the Team Competence Matrix is a tool to identify gaps between the current competencies of the team and the required competencies

Attendees will experience the real tools, and when they leave the workshop are ready to apply the tools the next day at work!

Congratulations on deploying applications on Docker and/or Kubernetes; Nowthe next thing that you would worry, is security and would have following questions :

• Are my images update to date ?
• Have I given right access to users ?
• Are there any security loop-holes in application deployment ?
• How I can audit environment/application to be security compliant ?
• Am I running the cluster in right configuration ?
• .... and many more

For a decade of software product agile, we had worked in a structure where business responsibility of what to build was allocated to a product owner and the responsibility of how to build it was allocated to a development team. Product owner would maintain a backlog, act as voice of the customers. Until one day we realized that the choice of what to build or fix is hard, and critical to everyone’s success. If we wanted to do it poorly, we delegated it to a single product owner.

We started a no product owner experiment. For three months, we experienced the development team delivering multitudes of value to what we had grown to expect, and innovate customer-oriented solutions in direct collaboration with customers. Team satisfaction and happiness bloomed. The experiment turned into a continuous way of working.

Customer-focused team directly in touch with their customers performs better without a proxy. Join me to learn how the decision power shared for everyone in the team transformed the ability to deliver, and how collaboration is organized with product experts and business representatives.

Going cloud native in a highly regulated context presents challenges of its own. In this talk, Jez Humble will share with you the platform created by the cloud.gov team at 18F, and the benefits it brought to federal agencies seeking to use the cloud.

Useless \ˈyüs-ləs\

use·less: not fulfilling or not expected to achieve the intended purpose or desired outcome.

[Synonyms: futile, to no avail, (in) vain, pointless, to no purpose, hopeless, ineffectual, ineffective, to no effect, fruitless, unprofitable, profitless, unproductive]

If you want to stop building useless software, then you have to start understanding your customers. Unfortunately, there’s no magic trick for reading their minds. But there is a simple technique that can help you gain insights and build empathy for them.

Empathy mapping is a simple activity for your team, stakeholders and anyone else who is responsible for delivering products and services. It allows you to collectively explore what your customers see, hear, say & do, as well as consider what they think and feel. This leads to insights about their pain and potential wants which are the keys to building more useful software.

In this session, Diane guides you through building an empathy map, showing you how to use silent brainstorming to encourage everyone to contribute. You will see, first-hand, how easy it is to work collaboratively to create a shared understanding of the customer. And that is the first step to start building software that customers find useful.

Today success comes from building products people love, creating loyal customers and serving the broader stakeholder community. In this thoughtful exploration on the future of work, the authors explore the past, present and future of the “project”. And why, in today’s fast changing & hyper-competitive world, running a temporary endeavour is the wrong approach to building sustainable products and how #noprojects is fundamentally changing the way companies work.

The metrics by which we have historically defined success are no longer applicable and we need to re-examine the way value is delivered in the new economy. This book starts from the premise that our goal is to create value, for the customer, for the organisation and for society as a whole and shows how to empower and optimise our teams to achieve this.

The authors draw on modern management approaches to provide proven techniques and tools for producing, and sustaining, creative products that go beyond “meeting requirements”. By creating teams who are accountable for business outcomes, engineering for customer delight, and creating value for all stakeholders - profitability, customer satisfaction and employee engagement are all increased.

This book is far more than just a catalogue of practices and tools which you can apply in your product development. It contains inspirational stories from individuals, teams and organisations who have switched to this new way of thinking and working. It exposes the risks on the pathway and how others have overcome these obstacles

If your team uses velocity for planning but you don't find it very useful, this workshop is for you.

If your manager or scrum master or other pseudo-authority figure keeps obsessing over your velocity, this workshop is for you.

If you want to know about better ways to forecast when a piece of work will be done or how to gather data that actually helps your team, this workshop is for you.

In this interactive workshop, Doc and Diane share insights into metrics and how they can be used to improve your team's performance. From cumulative flow diagrams to lead time distribution charts to forecasting using Monte Carlo simulation and more, you'll come away with the ability to better forecast when work will be done and better diagnose issues with your process.

This talk is for people who care about their Scrum teams, and how to tackle one of the most insidious threats to our team's productivity: the tyranny of interruptions.

In 45 minutes you'll learn why interruptions are endemic in some organisations (but not others), how disruptive they are to teams (it can take 15 minutes to re-focus after each interruption), how the impact productivity and team happiness, and several secrets from mature Scrum teams for reducing interruptions for individuals and teams.

My talks are always interactive and this talk includes a short, fun game to demonstrate how destructive the context switching from handling frequent interruptions is to our productivity. It's simple enough you can play it back in your company after the conference.

The context for this talk is described below.

The average IT worker is interrupted every 15 minutes, which equates to 2000+ interruptions for a Scrum team every sprint. This is "death by 1000 paper cuts for your teams' productivity." Unthinkable on a production line, yet too often the norm in offices.

Ask the Scrum teams around you whether they regularly deliver their committed work per Sprint and you'll find that most teams (very) seldom complete their planned work in a sprint, let alone two consecutive Sprints.

The material for the talk is distilled from original research I conducted with Scrum teams in Australia last year as part of my Master of Management thesis (and achieved an A), to understand the causes, patterns and impacts of these interruptions on the team's effectiveness and their happiness. And, how mature teams control interruptions rather than let themselves be controlled by interruptions.

I selected teams in Australia because the culture is relatively open to discussing challenges and is willing to experiment with new ways of working: hierarchy and tradition are arguably less influential than in some other cultures. (For the record, I'm not Australian...I'm a New Zealander and British, with experience working in the US and Australia as well.)

I delivered this talk the LAST Conference (July 2018, Melbourne, Australia) to a full room and it received one of the highest feedback scores from attendees at the Conference because the topic is so relevant to contemporary teams.

My talks are always highly practical and I provide 3 takeaway actions for people and teams to improve their 'flow' and reduce interruptions.

Please vote for my topic if you would like to help your teams optimise their performance and increase their happiness by reducing interruptions. Thank you.

~ Suzanne Nottage

Collaborative organisational culture doesn't just happen, it needs conscious and deliberate design and careful nurturing. In this workshop participants will explore what a collaborative organisation culture is, why it matters and how to deliberately design culture.

Culture is "the way we do things here" rather than anything written or prescribed, so understanding how leadership attitudes and behaviors influence and create organisation culture is vitally important to successfully establishing an environment where people are able to bring their whole selves to work, are engaged and positively contribute to the organisation's success.

This session is presented as series of facilitated conversations drawing out the key aspects of organisation culture and showing how it is influenced by a wide variety of factors including structure, geography, promotion policies and practices, the conversations leaders have, what gets rewarded, ignored or punished, relationships and friendships and a wide variety of other factors.

Would you like to know what is common between Agatha Christie, John Lennon & Thomas Edison ?
Would you like to know how to feed your idea funnel systematically?

We know that everyone is in search of a "Disruptive Innovation".
It has definitely captured our imagination.

But there is still so much left to do in the world & so much can be done on existing products & services.
We believe that a balanced approach towards innovation will help us make this world a better place.

For thousands of years, innovators & creative geniuses have used patterns in their inventions, usually without realising the same.
In the search of a serendipitous idea or innovation we often tend to ignore innovation which can be done methodically or incrementally.

Systematic Inventive Thinking (SIT) is one such set of techniques which can be applied to any product or process. These techniques help us in breaking our biases towards how things are and how they work , namely functional fixedness and structural fixedness.

Subsequently we can enhance or create an alternative to our product or service
which might look weird initially, but given time & refinement, would be surprisingly useful.

The 5 Tools of Systematic Inventive Thinking along with it’s “Closed World Principle” can help you kick-start or supplement your innovation journey in a well defined manner.

With the arrival of distributed applications that run on Blockchain, it is essential to rethink some of the basic aspects of DevOps. Few things that we take for granted in DevOps area are either irrelevant, impossible or too costly for blockchain applications. Join us to explore the changes that the blockchain apps bring to the DevOps arena, using a hands-on demo of a sample blockchain app.

• “That’s nice in theory, but it’s not possible to do that here because …"
• “That’s not the way we’ve always done it …”
• “Yes, but, in the REAL WORLD …”

• Large service based organizations, when they get into agile transformation leap from waterfall, there comes multiple layers of questions like starting from its approach, convincing the client, strategy to use and the initial resistance while convincing the project teams. Earning the trust factor from teams that are "first time doers" was more challenging with multiple negotiation. The Kanban board we used in teams aids the teams to become more open in their daily standups. These are the distributed teams working in two different shifts where ceremonies are not as easy as it would happen in co located teams.

As an agile coach eliminating the fear of just being fearful from various levels of hierarchical organization have given multiple perspectives .When we dissected the roadblock with senior management and middle management , their common query was how Daily standup meeting and retrospective will be exclusive compared to review meetings and weekly meetings that happens as per their cadence?

As per the empirical process control theory, the ceremonies when it get time boxed and practised day in and day out ,there are evidences for behavioral pattern change. Infact weeds out the invisible queues formed.

Techniques used over here in addressing the problems encountered:

1.cross pollinated through demo to hear from team where ceremonies are used regularly

2.Brought in an Infrastructure to bring in free flow communication irrespective of locations

3.Brought in leads in multiple tracks to attend the daily standup meeting when complete team work in war rooms at urgent scenarios.

4.Negotiated with "Work in Progress" limits with client at times whenever it overflows.

5.Retrospective and DSM has brought in better cost of ownership with individuals and triggers for kaizens in retro.

Experimentation results after couple of months.

1.Teams have become self organized irrespective of working from anywhere, nevertheless being in hierarchical org.

2. Open tickets with aging more than a period of time got reduced significantly.

3.Teams are pulling tickets more than a Manager pushes it

4.Scrum Master has evolved with better emotional intelligence where he draws clear cut line to refrain from micro management .Henceforth conscious KPI's are used without touching the sense of freedom among team members

5.Weekly review meetings nowadays uses live dashboards to have discussion with senior management and client

Last but not the least,Client has appreciated the team for making a defect free zone in one of the geographies in a shorter span of time

The typical questions that bother an engineer who wishes to try DevOps is generally where to start - with various kinds of tools available, it's confusing what to start using just to get a basic experience. What skills to focus on to be able to deliver continuously.

How does one go about building faith in a continuous delivery process? Can there be a proof of concept to show it? This bothers engineers and managers alike.

We explore a typical Devops system, give you a quick feel for what it means to deliver code continuously on an experimental setup that would replicate the whole DevOps process, from discovering a product idea to continuously delivering it as a product.

This will be a hands-on workshop for anyone who wants to play around with the essential tools needed for DevOps journey.

Dan Brown says the most important part of “Design Thinking” is not “Design” but “thinking”, in a similar way we can say that the most important part of “Being Agile” is to understand more about “being”than about agile.

“Being Agile”is one of the key elements of any Agile Transformation. There are many opinions, views and perspectives about – “doing” Agile vs “being” Agile. In this session on Power of Being, Ontological perspective about being Agile will be shared through practical hands on exercises. This presentation is based on the work done by Harvard Professor Michael C. Jensen and Werner Erhard on being a leader based on Ontological / Phenomenological model.

The concepts are based on Ontology, a branch of philosophy(in particular meta-physics) focusing on study and nature of ‘being’, The term is derived from Greek words, “Onto” for existence and “logia” for study, science. The session will be based on activities and learning is through participation and experience (transformative learning).

This session - Power of Being is based on Ontological/phenomological model.

In general ontology focuses on the nature being. For example, let’s consider an apple. The existence of apple can be experienced by sight, touch, smell and taste. In an apple juice, though the form is changed the existence can be experienced in the form of smell and taste. The “essence” or the being of an apple can be experienced.

In the case of living beings the concept of “being” is different, especially for human beings. Human beings have wide range of beings in which they express themselves. Normally they are expressed as emotions like “being happy”, “being sad”, “being angry”, “being enthusiastic” and so on. The being is not just the emotional state but it is much more than that. It is a combination of mental state (attitude and state of mind), emotional state (feelings and emotions), bodily state (body sensation), thoughts and thought process (logic and memory) in a given moment of time or in a given situation. This also includes mind-set (frame of reference) and world view (model of reality).

In fact, one can’t write/read about “being” then it becomes “knowing”.

From an Ontological perspective, being agile explores the “being” as the ways of being for people and teams. For an effective transition to being Agile all aspects are important.

The session will be activity based with concepts, activity, reflection and reinforcement based model.