Key: Presentations Workshop Panel Goldfish Bowl Performative Lightning Open Space

Tuesday, 24 May 2016

Pre-conference Workshops and Tutorials
7.00 Various locations
7.00-8.30 Early Morning Activities
7.00 Early morning yoga - Alexis Beddoe (60 minutes)
An hour of Hatha Yoga to get you ready for the day - all abilities welcome.

Mats will be available, but bring your own if you have one.

7.00 Early morning run - Jocelyn Moar (60 minutes)
Join us for a run around Holyrood Park - different routes every day.

Meet outside the reception at the main entrance at 7.00

7.30 Lean coffee - Various (45 minutes)
An hour or so of discussion over coffee, in the Lean Coffee format.

9.00 Cowan, St. Leonards Mob Programming
Woody Zuill
9.00-17.00 Mob Programming
Mob Programming - Woody Zuill (Pre-conference Tutorial, 420 minutes)
Abstract: All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer.

Mob Programming is a cost-effective, collaborative and fun way to get work done together. It's a whole-team approach to development, where coding, designing, testing, and working with the "customer" (partner, Product Owner, User, etc.) is all done as a team.

Participants in this workshop experience a day of Mob Programming, learning the mechanics of how to work together as a Mob and the techniques that make this form of development so effective. Learn how a Mob performs sample project work, including user stories, prioritization, test-driven development, refactoring, and retrospectives.

Designed by Mob Programming pioneer Woody Zuill, this workshop provides a hands-on education in the art of mobbing and its significant benefits for your teams.


- About Mob Programming & The basics of how it works
- First Exercise: A Code Dojo to Introduce Basic Concepts
- Driver/Navigator teamwork Roles and Techniques
- Second Exercise: A sample project
- The Importance of Retrospectives
- Advanced Mob Programming Concepts
- Third Exercise: Expanding on the Sample Project
- Amplified Learning - How to take advantage of learning opportunities
- Resolving Conflict
- Retrospective and review

Learning outcomes:

- How 5+ people can be effective working on just one thing
- Heuristics for team size
- Guidelines for successful collaboration
- Handling competing solutions and ideas to a coding problem
- Encouraging politeness and kindness of team members
- Reducing or eliminating harmful conflicts
- Mobbing Mechanics
- Tools for team coding
- Workspace setup
- How to "Amplify Learning" and take advantage of continual learning opportunities
- "Real-time" and continuous Retrospectives to reflect, tune, adjust
- The theory of why Mob Programming is effective.
- Test-Driven Development (TDD) as a team
- Working with Product Owners, Business Experts, as part of the team
- Refactoring as a team
- Continuous feedback at all levels of granularity

Method of Instruction: Interactive Dialogues, Simulations, Hands-on Exercises and Videos

Target Audience: Anyone involved in software development work including "non-coders". Not everyone needs to take the keyboard.

Course Level: Introductory-Intermediate

Course Prerequisites: Some experience in software development

Pentland East, JMCC Software Faster
Dan North
9.00-17.00 Software Faster
Software Faster - Dan North (Pre-conference Tutorial, 420 minutes)
Abstract: Great software professionals build better software faster. Agile methods, continuous delivery and software craftsmanship helped speed up delivery from years to months or even weeks, but then what?

Some teams are able to deliver software at a speed of change like you have never seen before, delivering quality software in days or even hours, again and again. So what is keeping the rest of us from doing so? Now is the time to go from months to minutes, to rethink the way we organise and improve our software development and delivery process.

Software, Faster is for people who believe it can be done, people who feel themselves limited by current Agile dogma, people who want to go back to basics and uncover new, simpler ways to deliver great software.

Are you a seasoned software developer who is frustrated at how slow your “hyper-performing” process feels? Are you suffering with an unwieldy feature backlog, the pantomime of estimation, the card wall where cards go to die, the efforts to automate where it obviously isn’t adding anything? Are you fed up with the artificial commitment of sprints and the unwelcome surprises that still seem to derail your projects?

Software, Faster brings software delivery principles into the 21st century. You will learn new techniques that both enhance and replace existing agile practices, some of which are counter-intuitive and many which are completely counter to current “best practise”. Using a mixture of discussion, instruction and exploration you will start to think differently about design, architecture, development and testing, operations, automation and team dynamics, as well as working with legacy systems and integrating with third parties.

What you will learn:

- How to challenge the received wisdom of established Agile methods
- How to design and architect for rapid and sustainable delivery
- Why understanding risk and embracing uncertainty are at the heart of faster delivery
- How to manage build, release and operations
- How systems thinking can help you plan effectively and estimate accurately
- How to identify and reduce gaps in your testing strategy
- How to engage with legacy systems and integrating with third parties
- How to manage different levels of skill and experience within a team

Pollock, St. Leonards Micro services – evolutionary approaches for building systems of systems
James Lewis
9.00-17.00 Micro services – evolutionary approaches for building systems of systems
Micro services – evolutionary approaches for building systems of systems - James Lewis (Pre-conference Tutorial, 420 minutes)
Abstract: “Write programs that do one thing and do it well. Write programs to work together” was accepted 40 years ago yet we have spent the last decade building monolithic applications, communicating via bloated middleware and with our fingers crossed that Moore’s Law keeps helping us out. There is a better way: micro services.

In this tutorial we will discover a consistent and reinforcing set of tools and practices, rooted in the the Unix Philosophy of small and simple. Tiny applications, communicating via the web’s uniform interface with single responsibilities and installed as well behaved operating system services. So, are you sick of wading through tens of thousands of lines of code to make a simple one line change? Or all that XML? Come along and check out what the cools kids are up to (and the cooler grey beards).

In this tutorial we will cover the following topics:

- Principle-driven evolutionary architecture
- Capability modelling and the town planning metaphor
- REST, web integration and event-driven systems of systems
- Micro services, versioning, consumer driven contracts and Postel's law
- Testing, building and continuous delivery
- Operational concerns

Bonnar, St. Leonards Continuous Delivery Foundations
Dave Farley
9.00-17.00 Continuous Delivery Foundations
Continuous Delivery Foundations - Dave Farley (Pre-conference Tutorial, 420 minutes)
Abstract: Continuous Delivery is a complex, holistic approach to software development and has a significant impact on the ways in which organisations operate. This approach demands a broad range of skills and techniques.

This course is designed to introduce and explore a deeper understanding of these ideas and techniques. It is primarily aimed at “Change Agents” within organisations, Leaders, Lead Developers, Lead Architects and so on. This course will give you the tools to help your company become a 'Learning Organisation'. Increase efficiency and quality, and reduce risk in your software development process. Our training can teach the techniques that will allow you to increase user satisfaction and make your organisation more innovative.

We do this by teaching an approach that will allow your company to become more experimental and capable of reacting quickly and efficiently to change and allowing your software development process to become a tool that enables this flexibility rather than an impediment to it.

This one day introduction will concentrate on Continuous Delivery fundamentals. You will learn:

- Why CD is taking the software development industry by storm.
- Why it works.
- The Fundamental Importance of Cycle-Time and experimentation.
- The Anatomy of a Deployment Pipeline.
- Working iteratively and maintaining flow.

Brewster, St. Leonards A Masterclass in Technical Practices for Developers
Jon Jagger
9.00-17.00 A Masterclass in Technical Practices for Developers
A Masterclass in Technical Practices for Developers - Jon Jagger (Pre-conference Tutorial, 420 minutes)
Abstract: You might well be reading this outline and thinking 'I write code every day, why should I go to a tutorial based on writing code?'
Well, ask yourself, why do you write code every day? Your answer will be something to do with implementing some feature,
maybe with tests, or fixing some bug, mostly working alone, for some company, to some deadline.

And that's fine.

But this day is different.
You will not be implementing some feature bound for production.
You will not be shipping anything.
You will not be writing code alone.
You will not be working to some arbitrary deadline.
You will not be writing code just once.

Instead, the day is based on the principles of experiential deliberate practice applied to software development.

You will not be using a normal integrated development environment. An IDE is designed for production. It has many features designed to help you go faster. We don't want to go faster. We want to go slower. We want to go more deliberately.

You will be coding in cyber-dojo, a highly constrained, custom-designed, minimal, 'non-development' environment, designed to maximize learning.
You will be working 100% test-driven.
You will mostly be pair programming.
You will be working in short timeboxes.
You will experience effective code-reviews.
You will apply your chosen learning from each previous iteration in the next iteration.

The day is hands-on and deeply immersive.

Feedback from previous attendees:

1. This was easily the best training course I have attended in my career.
2. Adjusting my mindset towards the process involved in integrating tests with code.
3. The practical involvement. Being able to make changes and learn throughout the process.
4. The cyber-dojo was brilliant. I love the concept. It's an excellent learning tool that I actually pushed out internally at our company.

Nelson, St. Leonards Unleash Value with the Agile Fluency™ Model
Diana Larsen and Steve Holyer
9.00-17.00 Unleash Value with the Agile Fluency™ Model
Unleash Value with the Agile Fluency™ Model - Diana Larsen, Steve Holyer (Pre-conference Tutorial, 420 minutes)
Abstract: Use the Agile Fluency Model to chart a course with your teams, create alignment with management, and secure organizational support for improvement.

As an Agile Business Leader or Coach:

- Do your teams deliver the results your customers need?
- Are you disappointed by the slow rate of Agile growth?
- Do you wonder how to promote innovation?
- Is your process failing to live up to the promise of Agile?
- Do you have questions about leading Agile transformations in complex organisations?
- Has your latest change program stalled? Is it headed towards the rubbish bin like the change program before it? ... and the change program before that?

Too many people have told us, "We tried Agile, and it just didn't work."

Let's do better.

We know your teams can deliver great results consistently.

In this intense, playful, interactive, hands-on workshop, we'll explore concrete and pragmatic ways to create the kind of lasting change that fits *your* teams and organisations best. That's "fit for purpose" Agile. That's Agile that works.

We will uncover ways to use the Agile Fluency Model to:

- chart a course with your teams,
- create alignment with management,
- secure organizational support for improvement.
- and take it to the next level—the right level for you

What is fluency? Fluency is flow. It's practiced mastery. It's performing with routine, skilful ease. Whether learning to speak a language, play an instrument, or develop software in a new and better way, the pathway to fluency involves deliberate practice and investment in learning

**Unfamiliar with the Agile Fluency Model?** An understanding of the Model is not a prerequisite for the workshop, but a quick advanced read will help you participate more actively. To learn more about the model, see where you'll find the short seminal article with other resources.

Join us to unleash value and Agile that works. You will:

- Work in cohort groups to address questions that concern you most
- Explore and Model your own teams' Agile Fluency Journey with using LEGO® SeriousPlay®
- Play James Shore and Arlo Belshee’s engaging team simulation that encourages you to deeply explore XP and Agile practices with the corresponding tradeoffs and investment decisions found in every Agile adoption
- Confront and work through other brief self-diagnostic tools that highlight your team’s journey
- Take away a plan to unleash product value in your development organisation

Past participants in one of our Agile Fluency Model workshops have said:

“We got a vision [for] where to go with the company & how [to get there]!” — 2015 Agile Fluency Immersion participant

"I gathered a lot of new fresh ideas during this workshop ... will help me energize my coaching sessions." - a 2015 Agile FLuency Immersion workshop participant

“As an Agile coach… Agile Fluency has been an effective tool for me to help tell the agility story to the entire organization.” - Brent D. Strange / Go-Daddy

Duddingston, JMCC Exploratory Testing
Elisabeth Hendrickson
9.00-17.00 Exploratory Testing
Exploratory Testing - Elisabeth Hendrickson (Pre-conference Tutorial, 420 minutes)
Abstract: Software is full of surprises. No matter how careful or skilled you are, when you create software it can behave differently than you intended. TDDing a code base doesn't prevent the possibility of emergent behavior; CI only checks for the assertions we thought to write. Exploratory testing is the practice of designing and executing small, rapid experiments, using what you learned from the last little experiment to inform the next.

In this tutorial you'll learn essential skills of a master explorer:

- how to analyze software to discover key points of vulnerability
- how to use test heuristics to design experiments on the fly
- how to hone your observation skills
- how to focus your efforts with charters

Pentland West, JMCC Digital Friction Lab
Tom Poppendieck and Mary Poppendieck
9.00-17.00 Digital Friction Lab
Digital Friction Lab - Tom Poppendieck, Mary Poppendieck (Pre-conference Tutorial, 420 minutes) [slides]
Abstract: Friction. Starts fires. Stops airplanes. Gives traction. Saps energy. A small bit of friction is unavoidable to gain traction and overcome inertia. A large dose of friction slows everything down, annoying customers and eating away at profits. This lab looks at the three most common sources of friction in digital systems:

- Friction in the Customer Journey
- Friction in the Code Base
- Friction in the Process

You will Discover:

- Causes of friction in the customer journey
- How to replace requirements with analytics
- Strategies for creating highly available, fault tolerant systems
- Structures and tools for low friction systems
- How savvy governments deliver digital services
- Unexpected points of friction in your delivery process

For more information read our essay on friction.

The day's agenda will cover:

1) The Customer Journey

- Understanding Consumer Behavior
- Empathy and Analytics
- Journey Maps

2) The Code Base

- The Structure of Highly Available Systems
- Limited Dependency and Automation
- Situational Awareness

3) The Process

- The Responsible Engineering Team
- Fast Feedback and Reliability
- Case Study: Government Digital Services

Salisbury, JMCC International Workshop on Refactoring and Testing
Steve Counsell, Roberto Tonelli and Stephen Swift
9.00-13.00 International Workshop on Refactoring and Testing
International Workshop on Refactoring and Testing - Steve Counsell, Roberto Tonelli, Stephen Swift (Scientific Workshops, 210 minutes)
Abstract: Refactoring and its testing implications/crossover have emerged over recent years to become important inter-related research topics with high industrial resonance. Many issues and problems still remain unexplored in these two highly-related fields incorporating topics such as the theoretical underpinnings of refactoring, Test Driven Development, empirical studies, refactoring of test artefacts, code smell analysis and patterns (both design and micro) to name just a few. Refactoring also has a growing importance in the monitoring of system’s evolution and the propensity of systems to minimise maintenance effort and fault propensity; the over-riding question, still largely unanswered, is whether we can quantify the benefits of refactoring. The purpose and goal of the RefTest Workshop is to bring together industrial practitioners and academics in a setting where current issues in refactoring and test crossover can be presented, relationships with testing discussed, results from current research in refactoring/testing disseminated and future directions distilled.

  • 9am Welcome and Introduction Steve Counsell and Keynote, Dr Nat Pryce

  • 10am Tea/Coffee Break

  • 10.30-11am Francesca Arcelli Fontana, Riccardo Roveda, Stefano Vittori, Stefano Saldarini, Francesco Mazzei and Andrea Metelli, On evaluating the impact of the refactoring of architectural problems on software quality

  • 11am -11.30am Matteo Orru and Michele Marchesi, Assessment of Approaches for Refactoring Activities Detection on Software Repositories. An Empirical Study

  • 11.30-12midday Leonard Elezi, Sara Sali, Serge Demeyer, Alessandro Murgia and Javier Pèrez, A game of refactoring. Studying the impact of Gamification in Software Refactoring

  • 12midday – 12.15 Wrapup – Steve Counsell

  • Lunch

St. Trinneans, St. Leonards International Workshop on Large Scale Agile Development
Nils Brede Moe, Torgeir Dingsøyr, Helena Holmström Olsson and Morten Elvang
9.00-17.00 International Workshop on Large Scale Agile Development
International Workshop on Large Scale Agile Development - Nils Brede Moe, Torgeir Dingsøyr, Helena Holmström Olsson, Morten Elvang (Scientific Workshops, 420 minutes)
Abstract: Agile software development methods were made for small, co-located development teams, but are increasingly applied in other settings. Several large projects, with a number of teams that develop complex systems have started to use agile methods.

The goal of this workshop is to bring together experienced practitioners and researchers on the topic of large-scale agile development, to continue evolving this emerging field.

This workshop will be the fourth which seeks to discuss both the state of research and state of practice in conducting agile software development in large-scale. Such challenges include team coordination, portfolio management, scaling in different domains, knowledge sharing and facilitating self-management. See the summary of the workshop in 2014.


  • Keynotes

    • Communities of Practice in Large-Scale Agile, Casper Lassenius, Aalto University

    • Scaling in practice: Some myths and realities, Evelyn Tian, Ericsson

  • Short talks (before lunch)

    • Distributed large-scale

      • Large-Scale Off shore Agile Tailoring: Exploring Product and Service Organisations, Julian Bass

    • Knoweldge sharing

      • Knowledge Sharing and Process Improvement in Large-Scale Agile Development, Finn Olav Bjørnson and Kathrine Vestues.

      • Scaling Across Knowledge Boundaries: A Case Study Of A Large-Scale Agile Software Development Project, Knut H. Rolland.

    • Large-scale Agile Transformations

      • Challenges and Success Factors for Large-scale Agile Transformations – A Research Proposal, Maria Paasivaara and Casper Lassenius.

    • Teams in Large-Scale distributed projects

      • Agile Teams in Large-Scale Distributed Context – Isolated or Connected?, Aivars Sablis and Darja Šmite.

  • Short talks (after lunch)

    • Inter-team coordination

      • Inter-Team Coordination in Large Agile Software Development Settings: Five Ways of Practicing Agile at Scale, Saskia Bick, Alexander Scheerer and Kai Spohrer.

      • Inter-Team coordination in Large-Scale Agile Development: A test of organizational discontinuity theory, Kevin Crowston, Katherine Chudoba, Mary Beth Watson-Manheim and Pouya Rahmati.

    • Multidisciplinary work

      • Piloting Lean-Agile Hardware Development, Maarit Laanti.

    • New organisational forms

      • Sociocracy – An Organisation Model for Large-Scale Agile Development, Jutta Eckstein.

  • Discussions (World Cafe)

Holyrood, JMCC Second International Workshop on Agile Development of Safety-critical Software
Geir Kjetil Hanssen, Tim Kelly, Osama Doss and Børge Haugset
9.00-13.00 Second International Workshop on Agile Development of Safety-critical Software
Second International Workshop on Agile Development of Safety-critical Software - Geir Kjetil Hanssen, Tim Kelly, Osama Doss, Børge Haugset (Scientific Workshops, 210 minutes)
Abstract: Development, certification and maintenance of safety-critical software systems is complex and costly. In particular, having a high safety integrity system certified according to mandatory standards such as IEC61508 (process), DO178C (avionics) or EN50128 (railway) is fundamental to keep a competitive advantage but also one of the most severe cost drivers. An estimated 25-50% of total costs may be related to documentation of proof of compliance to standards and the assessment by external certification bodies. The established practice in the industry is to base development on extensive up-front planning with a consecutive strict focus on plan adherence in the development phase and late verification and validation of the solution being built. However, this approach gives low flexibility and a risk of discovering critical problems at a late stage where correction costs are high.

The trend of implementing larger parts of safety system in software has led to a growing interest in agile software development methods and techniques to improve performance with respect to development efficiency, system quality and safety integrity, as well as resource optimisation and effective assessment and certification. This raises a series of challenges, for example how to adapt agile principles to large and complex projects, how to implement changes in a conservative and plan-driven practice, how to involve external certification and notified bodies, and how to enable efficient and cost effective traceability and documentation management.

This event will be the second international workshop addressing industrial and scientific challenges related to the adoption of agile methods and techniques to improve development and certification of safety-critical and high-integrity systems. The workshop will invite leading experts to share insights into needs, opportunities, and ideas to shape an important research field.

The workshop will be based on mix of presentations by an invited key- note speaker (to be announced later) and by authors of accepted papers as well as presentations based on extended abstracts. Around 40% of the time will be reserved for discussions.

Invited Keynote: Hardware can be agile - Nancy Van Schooenderwoert [Slides]

Nancy Van Schooenderwoert will give an opening key-note speech at the ASCS workshop in Edinburgh on May 24th. The title is “Hardware can be Agile”. She will look into how an agile development process can be used to synchronise software and hardware development, one of the challenges we see in development of safety critical systems. Nancy was among the first to apply Agile methods to embedded systems development, as an engineer, manager, and consultant. Beginning in 1998 she has led Agile change initiatives beyond software development in safety-critical, highly regulated industries, and coached clients in the art of Agile technical and management leadership.

Board room, JMCC International Workshop on Requirements Engineering in Agile Development
Sabrina Marczak, Maya Daneva, Ville T. Heikkilä, Nils Brede Moe and Knut H. Rolland
9.00-13.00 International Workshop on Requirements Engineering in Agile Development
International Workshop on Requirements Engineering in Agile Development - Sabrina Marczak, Maya Daneva, Ville T. Heikkilä, Nils Brede Moe, Knut H. Rolland (Scientific Workshops, 210 minutes)
Abstract: Requirements are the abstractions used to represent what adds value to the customer business. This value needs to be captured and carried out into the development cycle. Requirements engineering is the well-established discipline that provides a wide range of approaches, techniques, and tools to elicit, analyze, specify, model, verify, validate, negotiate, prioritize, and manage requirements. As software applications became larger and more complex as well as teams get physically distributed, requirements engineering activities also became more complex and difficult to achieve with high quality. Lack of documentation, requirements creep, late notification of changes, misunderstandings of specifications, and lack of customer involvement are just a few of the issues often faced by software teams concerning requirements. Increase of control and addition of formal process definitions and checkpoints over requirements activities, slowing down the development life cycle, were unintended consequences of attempts to improve the aim of delivering higher-value and higher-quality software products to the customer.

The agile movement, with light-weight and effective practices, is one of the most significant changes recently seen in how to develop software. The adaptability to changes and the intense collaboration with the customer are two important characteristics of the agile philosophy translated into practices by agile methods. Despite the almost two decades of agile adoption in the software industry, we still have little evidence on how requirements engineering is done and fits the agile philosophy.

The main goal of this workshop is to promote community building between industry and academia and discussion on the topic aiming to further developing this critical and important field. We encourage the submission of technical, experience or industry reports, research design, and position papers reporting work on the topic of requirements engineering in agile development. Workshop discussions will be guided by submitted papers but not restricted to them. Group work will take place promoting integration and debate among the participants.

12.30 Canteen, JMCC LUNCH
13.30 Salisbury, JMCC International Workshop on Emerging Trends in DevOps and Infrastructure
Rakesh Rana, Darko Durisic, Klaas Jan-Stol and Miroslav Staron
13.30-17.00 International Workshop on Emerging Trends in DevOps and Infrastructure
International Workshop on Emerging Trends in DevOps and Infrastructure - Rakesh Rana, Darko Durisic, Klaas Jan-Stol, Miroslav Staron (Scientific Workshops, 210 minutes)
Abstract: Companies like Amazon, Netflix, Etsy, and Facebook uses a “DevOps” approach to deliver features regularly to their customers, in some cases even several times per day. However, most companies are still operating on a release cadence that takes many months, and struggle to improve on that. In Agile software development, considerable attention has been devoted to the continuous development, delivery and deployment of software. Continuous deployment can enable companies to increase development speed and to quickly react to problems discovered in products post release. The experimentation model whereby companies employ split A/B testing with customers is one example of this. However, there is still a need for a better understanding of the roles, responsibilities and performance measurement of DevOps and the implementation of infrastructure.

The goal of this workshop is to gather practitioners and researchers working on topics related to DevOps and Infrastructure as Code.

Holyrood, JMCC Doctoral Symposium
Brian Fitzgerald and Darja Smite
13.30-17.00 Doctoral Symposium
Doctoral Symposium - Brian Fitzgerald, Darja Smite (Doctoral Symposium, 210 minutes)
Abstract: The XP2016 PhD Symposium will provide students with an opportunity to:

- Present their research work in a relaxed and supportive environment
- Receive feedback and suggestions from peers and field experts
- Gain an overview of the breadth and depth of agile development research
- Obtain insight into research directions taken by other doctoral candidates
- Discuss concerns about research, supervision, access to industry, the job market, etc.
- Network with peers and future colleagues

Other rooms All full day sessions continue
18.00 Centro bar, JMCC
18.00-20.00 Conference "ice-breaker"
Conference "ice-breaker" - Head Resourcing (Social, 120 minutes)
Abstract: Meet your fellow delegates over snacks and drinks.

We'll have plenty of recommendations of good, local restaurants to visit in groups.

20.00 Various restaurants
20.00- Dinner with an agile stranger
Dinner with an agile stranger - Headforwards (Social)
Abstract: Join a group of other conference delegates and go to a local restaurant for dinner. A great way to get to know new people.

See the restaurants chosen at

Wednesday, 25 May 2016

Building JMCC St. Leonards
Room Pentland Duddingston Holyrood Salisbury Pollock St. Trinneans Cowan Bonnar &
West East Brewster
7.00-8.30 Early Morning Activities
7.00 Early morning yoga - Alexis Beddoe (60 minutes)
An hour of Hatha Yoga to get you ready for the day - all abilities welcome.

Mats will be available, but bring your own if you have one.

7.00 Early morning run - Jocelyn Moar (60 minutes)
Join us for a run around Holyrood Park - different routes every day.

Meet outside the reception at the main entrance at 7.00

7.30 Lean coffee - Various (45 minutes)
An hour or so of discussion over coffee, in the Lean Coffee format.

08:45 Conference Opening and Keynote: XP at scale Elisabeth Hendrickson
8.45-10.00 Conference Opening and Keynote: XP at scale Elisabeth Hendrickson (W-M.K)
Opening remarks - Seb Rose (Organisers, 10 minutes)
Abstract: A short introduction to this year's conference

Conference Charity - Mercy Corps - Alan Donald (Charity, 5 minutes)
Abstract: A brief overview of Mercy Corps - this year's conference charity

XP at scale - Elisabeth Hendrickson (Keynote, 60 minutes) [slides]
Abstract: At Pivotal, we have roughly 200 people on 46 teams at 8 sites in 6 time zones all writing code for Cloud Foundry, an open source Platform as a Service (PaaS), all following Pivotal's flavor of Extreme Programming.

Engineers pair, test drive, and continuously integrate. Product Managers steer the product through the backlog. Teams own their quality, their builds, and their tests; there is no independent QA. Explorers—not as many as you might imagine—pair in on teams to discover surprises, mitigate risk, and most importantly help foster an exploratory mindset.

In this keynote, Elisabeth describes how the engineering teams work, and what we added to make XP work at scale. Along the way, she'll tell you about the lessons Pivotal has learned including how to use Conway's law to our advantage; how to foster a "Salmon Initiative" to move quality upstream; and patterns for cross-team collaboration.

10:00 Break & Agile Clinic
10:30 Distributed Agile The place of agile methods in the history of software engineering
Bertrand Meyer
Where No One Has Tested Before: The Case For Textless Environments
Emmanuel Gaillot
Supercharge your Product Backlog with User Stories
Suzanne Morrison and Laz Allen
Symbiotic Design Practices
Michael Feathers
Amplify Agile
Giuseppe De Simone and Evelyn Tian
Self-organisation and Diversity Surviving and Creating Change
Jutta Eckstein
10.30-12.00 Distributed Agile (W-M90.PW)
Applying Lessons Learned from Distributed Agile - Mark Rajpal (Experience Reports, 20 minutes) [slides]
Abstract: What do you do when you've endured your first Agile experience and things didn't go so well? You can abandon Agile altogether or you can take those lessons learned and apply them to future Agile projects.
This paper discusses the journey travelled from that initial Agile introduction to the much more experienced Agile practitioner. We will also look at some of the challenges that are still encountered today.

Dispersed teams - Challenging the Agile Manifesto - Nienke Alma (Industry & Practice, 30 minutes) [slides]
Abstract: A small team of young and enthusiastic professionals are starting a large test automation project. They follow agile principles, but they don't achieve results fast enough. Proposed solution: add team members located in India. Increase the team size while keeping the costs low. The onsite agile test team becomes a dispersed agile test team.

Nienke Alma has faced this situation. As a Scrum Master of the team she was asked to facilitate the growth of the team, support good practices and encourage the dispersed collaboration between the team members. She has experienced how challenging it is to build an effective dispersed team.

How do you for instance deal with Scrum events like standup meetings and retrospectives if you're thousands of kilometers apart? How do you make sure that all team members contribute to continuous improvement and follow the way of working agreed in the team?

In a challenging journey through cultural differences, miscommunication and continuous learning Nienke has tried to find an answer to these questions. Some of the practices she introduced proved to be successful, while other practices simply failed to deliver results. One thing is clear though: in dispersed teams new dynamics appear.

In this talk Nienke aims to inspire both team members and managers to be creative in their approach towards dispersed teams. And eventually have them think about: are the results proving to be worth the investments?

Distributed Agile Anti-patterns - Paul Wilson, Alan Gardner (Industry & Practice, 30 minutes) [slides]
Abstract: In the original Extreme Programming Explained Book, Kent Beck asks a question of Boehm's Cost of Change Curve: what if all that had been learnt over the previous 10 years -- simple design, object oriented programming, programmer tests -- could flatten the curve and move us away from big upfront specification and design?

In the same book, he points out the crucial importance of collocating your teams.

What if in the 17 years since the publication of XP Explained, the advances in technology and all we have learnt about running Agile projects means that collocating is no longer the only way to run an XP project? Sure, having all your team members in one room is still optimal, but are you micro-optimising? What if you can make the advantages of distribution (increased flexibility, better quality of life, increased talent-pool) outweigh the advantages of collocation?

Distributed Agile is not an easy choice, though; there are many pitfalls. In this talk we present some common Distributed Agile anti-patterns, the forces behind them, and the refactored solutions. We will include some tools and techniques that we have found to be helpful, including tips on remote pair-programming.

We will help you decide whether it is worthwhile distributing your team, help you spot problems before they become serious, and know the solutions to those problems.

10.30-12.00 The place of agile methods in the history of software engineering (W-M90.PE)
The place of agile methods in the history of software engineering - Bertrand Meyer (Invited, 90 minutes)
Abstract: Most of the discourse around agile methods has been inspirational and contrarian: its goal is to convince, and it presents agility as a reaction against more traditional techniques. As the dust settles and agile methods gain respectability, it is time to take a broader and more dispassionate view. In fact, the best ideas of agile methods do not negate preceding advances in software engineering; they complement them and rectify some of their deficiencies.

In the spirit of the book “Agile! The Good, the Hype and the Ugly” (Springer), this talk presents agile methods in the general context of the evolution of software engineering principles, methods and tools. Taking the perspective of a practicing software developer and manager focused on quality and productivity, it dissects the key agile ideas, assessing their pluses and minuses.

The result is an analysis of the agile approach not as an outlier or an exception but as a major step in the evolution of our ideas of software engineering.

10.30-12.00 Where No One Has Tested Before: The Case For Textless Environments (W-M90.DU)
Where No One Has Tested Before: The Case For Textless Environments - Emmanuel Gaillot (Industry & Practice, 90 minutes)
Abstract: (Or: How to test-drive your code, in a language as foreign as GLSL.)

Test-Driven Development is desperately simple. Simple, because it takes about five minutes to understand the principles. Desperately, because real-life contexts seem always harder than case studies used for training -- at least by forty-two orders of magnitude.

Just for laughs, we'll aim this time at doing the opposite (to practice TDD in a more difficult context than the typical workplace) and we'll show how we can use TDD to build a non-trivial shader in GLSL (OpenGL Shading Language). This tutorial is intended to push the limits of what is considered doable with TDD.
By doing so, we hope to make the audience realize that if it's possible to test-drive code in GLSL, it should be possible to do so in virtually any TDD-resistant environment.

This is a performative programming session: the audience will watch a performer programming for its (the audience's) benefit some non-trivial piece of code from A to Z. In the spirit of the Brechtian theatre, the audience is encouraged to laugh at the misery of the programmer on the stage, to be critical of their (the programmer's) successes, to cheer and to boo, to smoke and to eat, and to think about what they'd do (better) if they were in the same position.

10.30-12.00 Supercharge your Product Backlog with User Stories (W-M90.HO)
Supercharge your Product Backlog with User Stories - Suzanne Morrison, Laz Allen (Industry & Practice, 90 minutes) [slides]
Abstract: In this fun, interactive workshop you'll learn how manage your product backlog, write good user stories, split stories, add acceptance criteria and more.The workshop is a combination of theory and practice that alternates between teaching new concepts and techniques, practising them and then debriefing.

In this workshop you'll receive a list of home improvement requirements and you'll work in a group and in pairs to create user stories, critique user stories, use different patterns to split user stories and write acceptance criteria.

At the end of the session you'll have a clear understanding of how to keep your product backlog in good shape using user stories and other Agile techniques.

The workshop has been running at Skyscanner on a monthly basis for over a year and is attended by people in lots of different roles across the company including developers, testers, product owners, marketing managers and designers. Skyscanner is structured using a Spotify inspired squads and tribes model which we have adapted to work with our culture and values. We encourage our squads to self-organise in an agile way and use techniques as appropriate from Agile and Lean.

10.30-13.45 Symbiotic Design Practices (W-M90.SA)
Symbiotic Design Practices - Michael Feathers (Industry & Practice, 180 minutes)
Abstract: Decades ago, Melvin Conway coined what is now called Conway's Law: “organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations.” Conway's Law is a deep insight but it is only the tip of the iceberg when we try to understand the interaction between organisation and software. We fail to appreciate that we can use team structure, day to day process, and the interface between business and development as levers to affect the quality of design and code. With this perspective we can also see that concerns like technical debt and portfolio management lend themselves to new solutions when we understand software's sensitivities upon its environment.

Learning Outcomes:
- Understand Design Forces around Software
- Understand the Laws of Software Growth
- Appreciate the Effects of Agile Process, Build Process and Team Structure Upon Software Assets
- Understand How Avert Technical Debt Through Organisational Intervention
- Understand How to Monitor Software for Process Intervention
- Understand How and When to Let Technical Criteria Influence Business and Organisational Decision-Making

10.30-12.00 Amplify Agile (W-M90.PO)
Amplify Agile - Giuseppe De Simone, Evelyn Tian (Industry & Practice, 90 minutes) [slides]
Abstract: It is too easy to fall into temptation that Agile is all about Scrum, Kanban, roles and ceremonies. Embracing Agile means much more than that: it challenges some basic assumptions about how knowledge work gets done! Agility triggers an upgrade in individual beliefs and company culture: failing to understand or achieve this shift will dramatize any other change effort.
But how can we really make this shift?
The workshop proposes a method based on 3 perspectives:
- Challenging current beliefs
- Challenging actions in the light of Lean and Agile principles
- Deliberate practice of functional behaviors in line with the principles
The idea is to break the maps wired deep in our brain by all experiences and beliefs in our life and which we follow naturally like a river bed to interpret the reality. Then build instead, drop by drop, new side river beds, which allow us to see the reality with new eyes and act accordingly.

It's a fun and interactive workshop where we use a tool called “Agile Amplifier”, which has been developed by the presenters together with an internal community of Ericsson Agile coaches. Through a card game, participants will be working in a simulated environment to reflect and discuss around expected behaviors and needed skills to fulfill Agile values and principles.
Participants are encouraged to deliberately practice of such behaviors and continuous self-reflection as ways to deeply grasp Agile values, build habits, and create new beliefs, new assumptions, new structures and ultimately a new culture.

10.30-12.00 Self-organisation and Diversity (W-M90.ST)
XP Women - Clare Sudbery (Experience Reports, 20 minutes) [slides]
Abstract: There is currently a lot of discussion about the paucity of female IT professionals. This is a topic that should be of particular interest to the XP / Agile community for many reasons, in particular the following:

1) As agilists, we value individuals and interactions over processes and tools. The diversity of our teams, and specifically the encouragement of the participation of all members of our populations, is a crucial part of this.

2) There is an argument that agile methodologies attract a higher proportion of women than traditional software development practices. This is something which we should be proud of, and which we should work to emphasise and improve.

3) Agile is a forward-looking movement which emphasises flexibility, change and progress - so this is the ideal group of people to be discussing how to change the proportion of women entering IT.

My life as a female developer has improved considerably since I started working with XP and agile practices, and I believe these practices should help us to increase the numbers of women in IT.

This paper describes my experience as a senior female software engineer with sixteen years of industry experience and a good standing within the industry, but also as someone who has been making efforts to do something about those low numbers, via various means such as hackathons for girls, STEMettes, work placements for schoolgirls and increasing the profile of female role models.

In the light of my experience, I will attempt to answer these questions:

• Why are there so few women working in IT, and particularly in technical positions within IT?
• Is the balance better within teams adopting XP and agile practices?
• Do agile practitioners have both a greater responsibility to increase the numbers of women in tech, and a better chance of achieving that aim?
• Does it matter?

The arguments I will be making in this paper are as follows. All of them will be illustrated with frequent and vivid examples, some based on personal experience and some based on published research:

• Agile and XP working practices will benefit from a higher number of female IT professionals
• Agile and XP working practices should help us to increase the numbers of women in the industry
• Stereotypes - of either men or women - are not helpful
• Assumptions about female aptitude in technology have a deep and detrimental effect on the likelihood of women joining the profession
• These assumptions need to be challenged, as does any bad science (eg the idea that the brains of women are inherently less suited to analytical reasoning)
• Women and girls need to be actively presented with opportunities to enjoy IT, as well as positive role models

I have written several blog posts on this topic.

Self-organizing the organization - Emilio Gutter, Alejandra Ines Alfonso (Industry & Practice, 30 minutes) [slides]
Abstract: Since the breakthrough of Agile methodologies in the Software industry, project management has been transformed radically: from centralized command-and-control structures to self-organised teams. Agile methodologies have not only introduced a new set of practices, but also a new set of values and principles.
Although, it might seems contradictory, there are nowadays a big number of self-organised teams working within hierarchical organisations that are governed by a traditional top-down structure. Sensitive information is kept a secrecy and strategic decisions are made solely by the CEO and the leadership team. How does management in the 21st century has to be transformed in order to not just give people control on their own work, but also empower them to manage the organisation they are working for?
To leverage and make the most of the values and practices of Agile methodologies, a different management model should be applied. In this presentation we will take a closer look at the challenges of self-organised organisations, which some of the recent literature has named as evolutionary-teal. We will cover a diverse set of topics from the organisation structure and how information flows through it, to the decision-making process and core activities such as recruiting, performance reviews, compensation and rewards.

Neuro-diversity and agile: what leading experts in Autism, Creativity and the Psychology of Programming can teach us about the way we develop code. - Sal Freudenberg (Industry & Practice, 30 minutes) [slides]
Abstract: Software development is a pretty amazing endeavour. That the human brain can manipulate such an intangible and complex domain is nothing short of astonishing. We'll take some very different slants on the psychology of programming and explore how each of them might be better supported:

Cognitive – What is known about the mechanisms we use to help us manage the complexity of programming? How do our tools help or hinder this? How does knowing this help us in the process of software development? What else could help?

Autistic – It seems there is a higher propensity towards autism and aspergers in STEM careers. What do we know about the autistic / aspergers mind and how does that lend itself to developing software? How might we better support autistic individuals at work?

Creative – What do we know about the creative process? What inhibits creativity at work and how can we foster it?

Introverted / Extraverted – What distinguishes introverts from extraverts? What challenges does this create for each? How can we create an environment that supports both?

10:30-17:30 Surviving and Creating Change (W-M90.CO)
Surviving and Creating Change - Jutta Eckstein (Industry & Practice, 360 minutes) [slides]
Abstract: The necessity of rapid change is the topic number one nowadays. This regards on the one hand organisational change that we need to create and promote in order to stay in business, to respond to market pressures, and to be innovative. On the other hand this respects change that we face as organisations and individuals.
During this workshop I want to provide answers –using both theory and practice– to the following questions:
- What's happening with affected persons during a change?
- According to complexity theory there is no resistance to change. So why is change still hard and how can we introduce change smoothly?
- What is fundamental to every change?
- What needs to be considered for implementing change successfully?
In order to answer these questions we will make use from the insights from different change models, Human Systems Dynamics (HSD), and Fearless Change.

12:00 Break & Agile Clinic
12:30 Beyond Features: rethinking agile planning and tracking
Dan North
Architecture Distributed, collaborative development Teaching Agile Software Engineering Practices in an Academic Environment
Robert Chatley
(previous session continues) Predictive Models of Development Teams and the Systems they Build
Robert Smallshire
It's systems all the way down
Chris McDermott
(previous session continues)
12.30-13.45 Beyond Features: rethinking agile planning and tracking (W-M75.PW)
Beyond Features: rethinking agile planning and tracking - Dan North (Invited, 75 minutes) [slides]
Abstract: Agile planning has always been a hit-and-miss affair. At one end of the scale is the soul-crushing, multiple day workshops whose output is a list of hundreds of detailed features, many of which will never see the light of day. At the other end is the continual insertion of random demands into the product backlog, with the team constantly on the defensive, never knowing what is coming next and forever switching context.

We estimate as a group using story points and then we carefully track velocity, burn-up, burn-down, and use this to predict delivery timescales or commit ourselves to near-term deadlines. So with all this rigour and discipline, surely your team is a highly-energised unit, delivering quality software in a regular cadence, free from the thrashing, context-switching, pressure and uncertainty that would suggest “bad” planning, right? Or maybe not.

Maybe features aren’t the point of delivery after all. Maybe there are other kinds of work that we could recognise, schedule and track as first class citizens. Maybe this could take some of the uncertainty out of the delivery process, and give us back our sanity. Maybe.

12.30-13.45 Architecture (W-M75.PE)
The journey goes on. Discovering the role of the Architect in an Agile environment. - Avraham Poupko (Experience Reports, 20 minutes)
Abstract: This paper continues my paper from XP2015: "It's been a long journey and its not over yet"

Agile is about flexibility and responding to change. Architecture is about stability. Traditionally, the architect was the responsible for the technical scaffolding of the system. This scaffolding was identified early on in the system. However in an agile world we view scaffolding in a bit of a different manner than we do in a traditional waterfall world. As such, the role of the architect is different.

This paper outlines in detail my personal journey from a waterfall architect to a agile architect. Along the way, I discovered new skills as well as new perspectives and new outlooks on existing skills.

Creating An Incremental Architecture For Your System: What, Why and How - Giovanni Asproni (Industry & Practice, 45 minutes)
Abstract: Experience taught us that creating an architecture for a system with a big design upfront is a bad idea as, usually, we don't have all the necessary information to design the system at the very start—even in moderate sized systems requirements tend to change significantly, often making the initial design unfit for purpose. On the other hand, no upfront design can be just as bad--the code tends to become unmaintainable pretty quickly, and system qualities like performances, scalability, security, latency, etc., can be very difficult, if not impossible, to retrofit.

In this talk I'll show a different way to create a software architecture with just the right amount of design that can be incrementally evolved (or changed) as the system grows and changes.

12.30-13.45 Distributed, collaborative development (W-M75.DU)
Managing an agile team of internal and external partners - Tassos Koutlas, Alyssa Stringer (Industry & Practice, 30 minutes) [slides]
Abstract: Managing an agile team is one thing when you're all part of the same organisation, so how do you manage a hyper-creative, cross-functional team made up of partners from many various agencies?

Our make-up is quite unique: we are an in-house product team and two procured agencies.

We have a brand team that owns the vision for the product, manages on-the-ground delivery, and supports and trains users on the front line; a Drupal consulting agency procured part-time to lead on technology and agile transformation; and a separate agency of developers (in-house and outsourced) with dedicated Scrum Master.

We're a team of around 8 core people working to design, build and test product iterations for the Investors in People online suite (

This presentation will take you through the steps we have faced in applying agile principles in our context, including a look at the successes, the failures, the pitfalls and the many opportunities. Some of the topics we will cover are:

- Alignment: collaborating on one shared goal.
- Communication: communicating the product vision to external developers (PO); bringing multiple parties together in line with one sprint goal (SM); communicating product developments and value back to the business (PO).
- Product delivery: managing an in-life product, iterative releases and a large user base.
- Organisational shift: championing the value of agile to the wider Investors in People business and promoting culture shift.

Distributed, collaborative development for the refugee crisis - Alan Donald (Invited, 30 minutes)
Abstract: As the refugee crisis in Syria and the Middle East spreads throughout Europe, a number of opportunities emerge for technology as an important solution for challenges in affected countries. Employing distributed development across disparate geographies leverages the availability of specialty resources despite location, as well as offering advantages in diverse thinking, accelerated solutions and project cost reduction.

To support the more than 6.6 million people who have been displaced in Syria, collaboratively developed technology can foster a variety of innovative solutions including:-
· information and communication through mobile devices using tools such as WhatsApp and Slack.
· solar shelters developed in partnership between the IKEA Foundation and the United Nations High Commission for Refugees,
· family tracing platforms from organizations like Refugee Unite in collaboration with Mobile Network Operators, Omidyar and others,

Social good development can be highly impactful when approached collaboratively and with tight community involvement. Collaboration between NGOs, private and public entities, together with local communities, can help build back secure, productive, peaceful, and just communities.

12.30-13.45 Teaching Agile Software Engineering Practices in an Academic Environment (W-M75.HO)
Teaching Agile Software Engineering Practices in an Academic Environment - Robert Chatley (Teaching, 60 minutes) [slides]
Abstract: Many degree programmes provide students with a solid grounding in the theoretical basis of computing, but it is difficult in a university environment to provide training in the types of software engineering techniques and practices, such as agile methods, that are commonly used in industrial development projects. There is typically a large gap between theoretical knowledge and practical experience.

In this presentation we will explain how we have developed a programme that aims to bridge this gap, providing students with practical experience of relevant skills for industrial software engineering careers. We will give examples from courses at both Imperial and Oxford. We are aiming to create courses that are practical and industrially relevant, but built on the fundamentals of computer science and rigorous engineering.

We will also discuss how we have applied agile techniques and systems thinking to the design of the educational experience itself.

12.30-13.45 Predictive Models of Development Teams and the Systems they Build (W-M75.PO)
Predictive Models of Development Teams and the Systems they Build - Robert Smallshire (Industry & Practice, 60 minutes) [slides]
Abstract: It's awkward to perform scientific experiments on developers, so let's simulate them instead! The emerging field of software process dynamics applies systems thinking and simulated experiments of software development teams and the systems they build, to inform decisions on projects, process and architecture.

We start out by looking at the nature of scientific enquiry in fields where controlled experiments are infeasible. This leads us to the use of simulated experiments and modelling, which we seek to apply to various hard decisions in software development, particularly those where the system (of software development) responds counterintuitively to interventions.

We present two broad approaches to simulating software process dynamics: Discrete simulations, where distinct entities and actors are explicitly represented, and continuous simulations which deal in aggregates such as number-of-personnel or amount-of-code.

Discrete simulations are illustrated using a model of codebase growth, taking into account individual developer productivity, staff turnover and slowing development with increasing system size. We use Monte Carlo techniques to characterise the range of outcomes, and make predictions about the long-term viability of software systems. This has implications for how we design and document software, and for how we assemble teams.

Continuous simulations are illustrated using a model which incorporates team size, project complexity, communication overhead, staff turnover and training needs, with which we can test Brooks' Law. We demonstrate the circumstances in which Brooks' Law applies and – crucially – those it which is does not apply, showing that the “law” is not universal and so should not be applied naïvely.

12.30-13.45 It's systems all the way down (W-M75.ST)
It's systems all the way down - Chris McDermott (Industry & Practice, 60 minutes) [slides]
Abstract: W. Edwards Deming is known for stating that “95% of the performance of an organisation is attributable to the system (processes, technology, work design, regulations, etc) and 5% are attributable to the individual”.

But Deming was just talking about the manufacturing industry right? In the creative industries that we work in does the system play such a key role? Surely we need creative individuals, rock star developers and the like to be successful.

This tutorial will introduce the audience to systems and systems thinking while dipping into the mirky world of complex adaptive systems. We'll explore the difference between the complicated closed systems where Deming spent much of his time and the complex open systems that we in the creative industries work in. We'll also look at some of the techniques advocated by the lean and agile communities and see how they help us develop more effective systems.

13:45 Break & Agile Clinic
14:15 Design Understandable Test Automation Devops, Kanban and Taylorism Example mapping
Matt Wynne, Julien Biezemans and Steve Tooke
Hunting Value with Structured Conversations
Steve Holyer
Test-Driving Information Radiators
Rachel Davies
Learning at work 1 (previous session continues)
14.15-15.45 Design (W-A90.PW)
Worse Is Better, for Better or for Worse - Kevlin Henney (Industry & Practice, 45 minutes) [slides]
Abstract: Over two-and-a-half decades ago, Richard Gabriel proposed the idea of “Worse Is Better” to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly compromised and imperfect. This is not simply the observation that things should be better but are not, or that flawed and ill-considered solutions are superior to those created with intention, but that many solutions that are narrow and incomplete work out better than the solutions conceived of as being comprehensive and all encompassing. Whether it is programming languages, operating systems, development processes or development practices, we find many examples of this in software development, some more provocative and surprising than others.

In this session we revisit the original premise and definition, and look at how this approach to development can still teach us something surprising and new, as well as evaluate techniques that can help us put it into practice and evaluate it.

Capturing Design When You Really Need To - Eoin Woods (Industry & Practice, 45 minutes) [slides]
Abstract: The Agile Manifesto was partly borne out of valid frustration with “document first” software development methods that seemed to care more about the font size in the documentation set than the value of the software that was delivered. This led to the statement that we value “working software over comprehensive documentation” and a healthy focus on the value of everything we do in software development.

As is so often the case though, we probably overcorrected and we're now often in the situation with 8 year old projects that have lost sight of their fundamental design principles and rationale leading to the very sort of “cargo cult” behaviour that the Agile movement exists to remove. In my design and architecture work with Agile teams, this is something that (as a self-confessed “over-documentor”) I've been working to resolve for years.

In this talk, we'll discuss what architecture and design information is useful to capture and why. This will lead us to a set of tangible practices and guidelines to help teams find the right balance in their particular situations.

14.15-15.45 Understandable Test Automation (W-A90.PE)
Take me on a journey - the next step in automated testing practices - John Smart (Industry & Practice, 45 minutes)
Abstract: Every test tells a story, but some tell a better story than others. Every test illustrates a specific path through the system to achieve a specific goal, but some paths are clearer than others. Valuable tests are the ones that both tell a compelling story, and can stand the test of time, providing value not only as acceptance tests but also as living documentation and easily maintainable regression tests.

Come on a journey of discovery to learn how to write clean, clear and maintainable tests using the Journey Pattern, an innovative new approach to writing automated acceptance tests that are easier to understand, easier to extend and easier to maintain. You will also witness a demonstration of these principles in action, with live coding of Serenity BDD automated tests.

Readability Is King - How to Write Tests That Are Easy To Understand - Paul Rohorzka (Industry & Practice, 45 minutes) [slides]
Abstract: When we write code, we make sure that it does what it is supposed to do. But obviously we read our code way more often than we write it - be it while fleshing out a feature or during maintenance. Therefore it is vital that the code clearly reveals its intent to the reader. This does not only apply for production code but also for automated tests.
While it might be easy to achieve clarity for fine grained unit tests, it can be a challenging task for tests exercising several parts of the system, for example in an acceptance test suite. Typically, those tests initially bring the system to a specific state. Then, after invoking the functionality in question, often multi-faceted assertions are checked. For those parts to work, we might do many calls leveraging cumbersome APIs. The result can be a convoluted mess of code that poses a major hurdle for the evolution of the project.

In this session we will show means to address those issues. After proposing an approach to write tests that solely focuses on the value of the code under test, we will give in depth examples of ways to setup and verify complex scenarios in an intention revealing manner. On the go, topics such as evolving DSLs, the project's ubiquitous language, super entities and wishful thinking might pop up. All topics will be supported by code examples from a 10+ year project that has seen all of those issues.

14.15-15.45 Devops, Kanban and Taylorism (W-A90.DU)
Insights into the perceived benefits of Kanban in software companies: Practitioners' views - Muhammad Ovais Ahmad, Jouni Markkula, Markku Oivo (Research, 20 minutes)
Abstract: In the last decade, Kanban has been promoted as a means for bringing visibility to work while improving the software development flow, team communication and collaboration. However, little empirical evidence exists regarding Kanban use in the software industry. This paper aims to investigate the factors that users perceive to be important for Kanban use. We conducted a survey in 2015 among Kanban practitioners in the LeanKanban LinkedIn community. The survey results consist of 146 responses from 27 different organisations, with all respondents being experienced in using Kanban. The results show that practitioners perceived Kanban as easy to learn and useful in individual and team work. They also consider organisational support and social influence to be important determinants for Kanban use. Respondents noted various perceived benefits for using Kanban, such as bringing visibility to work, helping to reduce work in progress, improving development flow, increasing team communication and facilitating coordination. Despite the benefits, participants also identified challenges to using Kanban, such as organisational support and culture, difficulties in Kanban implementation, lack of training and misunderstanding of key concepts. The paper summarises the results and includes a discussion of implications for effective deployment of Kanban before describing future research needs.

On the Impact of Mixing Responsibilities Between Devs and Ops - Kristian Nybom, Jens Smeds, Ivan Porres (Research, 20 minutes)
Abstract: Many software engineering organisations around the world are adopting DevOps. One of the main goals of DevOps is to foster better collaboration between development and operations personnel, in order to improve organisational efficiency. There are several approaches to adopt DevOps in an organisation. This is due to the fact that DevOps is lacking a common definition and organisations largely need to determine how to apply DevOps for themselves. In this paper, we present results from a case study in which a software organisation adopts DevOps. The focus of this research is to study the impact of mixing the responsibilities between development and operations engineers. We interviewed 14 employees in the case organisation during the study, and the results indicate several benefits of the chosen approach, such as improved collaboration and trust, and smoother work flow. This comes at the cost of a number of complications, such as new sources for friction among the employees, risk for holistically sub-optimal service configurations, and more.

From Taylorism to Agile organization - Ari Tikka, Ran Nyman (Industry & Practice, 45 minutes) [slides]
Abstract: Agile Adoptions tend to fall back to the old status quo. This happens for several reasons. First, a partial adoption introduces changes, which make the socio-techno-economical system inconsistent and uneconomical. Second, partly because of the previous, the old status quo remains more comfortable for the individuals, and the new practices do not sustain. Third, the fundamental leadership assumptions have been cemented the culture.

In our session we explain the logic that takes the vast majority of leaders and organisations towards Taylorian. We will also show the necessary and adequate changes that create a sustaining Agile Adoption.

Organisation functions in a dynamic equilibrium that is economical and beneficial enough for the significant players. There are several such equilibriums, called attractors. When the equilibrium is slightly disturbed, it returns to the current attractor. With a strong enough disturbance the organisational equilibrium may move to another attractor.

We have worked with large scale adoptions, in medical, telecom, finance, public and game sectors, using LeSS and other scaling approaches. We have identified the essentials of two generic attractors that we call Taylorism and Agile.

Taylorism is sometimes called Sequential development (Waterfall), Command and Control, or Bureaucracy. It happens easily and is economical in stable conditions. It works well until growing stiff, inefficient and fragile. What is the dynamics that make this attractor so easy to get into, and fall back to?

The Agile attractor is suited for discovery and survives stormy conditions. Getting there requires deliberate and enlightened leadership. Changing too few of the interdependent conditions leads to falling back to the old status quo. What are the necessary and adequate simultaneous conditions of the Agile attractor?

We point out the most influential systemic conditions and their relations: the fundamental leadership assumptions, Flow efficiency versus resource efficiency, task specialization and coordination versus customer-centric learning, the competence of individuals, technical aspect, and adoption strategies.

We are using several theories and approaches, for example, Hofstede Organisational Culture, Ouchi's theory of organisational control, Hackmann's research on High-Performance Teams, Lean, Large-Scale Scrum and other scaling frameworks, Complexity theory, and history of Leadership.

14.15-15.45 Example mapping (W-A90.HO)
Example mapping - Matt Wynne, Julien Biezemans, Steve Tooke (Industry & Practice, 90 minutes)
Abstract: In this session I'll teach you a simple, practical technique that you can use to break down any user story.

BDD and ATDD enthusiasts already know how useful it is to have the three amigos - tester, product owner and developer - meet to discuss a new user story before they start development. What many teams don't have is a clear structure for these conversations. Sometimes they can take a long time, or drain the group's energy by going round in circles.

Over many years of teaching hundreds of people about BDD, I've developed a simple practical technique that will allow you to break down a story in about 25 minutes. All you need is a pack of coloured index cards, some pens, and a curious attitude.

Learning Outcomes:
- the purpose of a three amigos session
- a practical technique for visualising what you know, and don't know about a user story
- the difference between rules and examples

14:15-17:30 Hunting Value with Structured Conversations (W-A90.SA)
Hunting Value with Structured Conversations - Steve Holyer (Industry & Practice, 180 minutes) [slides]
Abstract: Developers, Customers, Product Owners: you get better outcomes when all partners join the conversation. Explore the structured conversations that you can facilitate in order to discover the value to deliver with your product.

In this workshop:

- You will explore ways to focus on value and engineer better Agile requirements through structured conversations.

- You'll practice new product discovery skills with colleagues in the fast-paced #DiscoveryDojo.

- Learn by doing—facilitating, coaching, observing and providing feedback. (Why should the developers be the only ones having all the dojo fun?)

Who should attend?

- Agile Product Managers and Product Owners together with Customers, Requirements Engineers, Scrum Masters, Coaches, Designers, and Developers are invited to explore the structured conversation and the 7 Product Dimensions.

The first half of this workshop weaves quick teaching moments with hands-on coaching dojo circles.

In the second half of the workshop we will dive deeper into Agile product discovery and requirements engineering with the 7 Dimensions of Product Value. Work together to explore how your team's relation to value creation changes as you and your team are able to master each new product skill.


We'll ask for volunteers with real product needs to serve as PO for each dojo circle. It pays to volunteer; volunteers will be rewarded with the best learning experience.

For the optimal learning experience, come prepared with a real product need from your actual backlog that you can share! Naturally not everyone can share a product need publicly, in that case you'll work in a #DiscoveryDojo with a volunteer PO. (Or use a prepared case study.)

The workshop is based on the work of Ellen Gottesdiener and Mary Gorman in the book Discover to Deliver. It incorporates #DiscoveryDojo circles which are inspired by Rachel Davies and Dave Thomas.

Everyone leaves with helpful assets to immediately apply to your product work.

14.15-15.45 Test-Driving Information Radiators (W-A90.PO)
Test-Driving Information Radiators - Rachel Davies (Industry & Practice, 90 minutes) [slides]
Abstract: Whether you're using Kanban, Scrum or XP your team will need a board to organise their daily work. As agile practitioners, we can apply Test-Driven Development to designing a team board that works as a true information radiator. In this workshop, we'll start by sharing different examples of team board designs with the team use cases that they support. We'll dig into the tests that we want our boards to support and use these to drive alternative designs. Come along to this workshop to learn new ideas about how you can create boards that help your teams coordinate their activities and drive improvement.

14.15-15.45 Learning at work 1 (W-A90.ST)
Hire an Apprentice: Evolutionary Learning at the 7digital Technical Academy - Paul Shannon, Miles Pool (Experience Reports, 20 minutes) [slides]
Abstract: Hiring senior software engineers with experience in Agile and Lean has always been difficult. Training university graduates or engineers from other backgrounds takes time and can cause disruption to software teams. 7digital addressed both of these problems by starting a Technical Academy; a 6 month programme of classroom sessions, pairing, deliberate practice, personal project work and guided learning. The academy taught apprentices skills related to Agile software development and Lean practices, with sessions on subjects including Test Driven Development, Theory of Constraints, Databases, DevOps, Continuous Delivery and Design Patterns.

The Academy programme has completed its third iteration and has evolved through continuous improvement with regular inspection and adaption. In the first iteration, a key retrospective resulted in a move to pull based learning; asking apprentices to solve real business problems and request sessions on the skills they needed to accomplish their objectives. The second iteration saw peer to peer learning and a self organising community develop amongst apprentices. The third iteration brought a wider set of people to the academy and was used to expand understanding of Lean and Agile principles across the organisation. We started with three apprentices in the first iteration, then had four in the second iteration, finally ending with seven; the number of external hires was always two people though as we added people from other departments in subsequent years.

Backed by key metrics and qualitative data, the paper explores the positive impact that the technical academy has had on the technology team and wider organisation at 7digital. It investigates the changes in technique, curriculum and structure that the team made over the 3 iterations of the academy. It goes on to detail the challenges that the team faced around justifying the time away from usual activities, measuring the impact, attempting to predict the long term benefit and make the result of extra diversity in the team more apparent.

I have no idea what I'm doing - And that's OK. - Spencer Turner (Industry & Practice, 30 minutes) [slides]
Abstract: I don't know everything, neither do you. We need to be honest about that, share, learn, collaborate and help each other solve the complex problems we all face, as a team. Some obvious (but easily ignored and forgotten) thoughts on how to build a culture that is primed for learning and continuous improvement by supporting openness and honesty.

I was lucky enough In my first ‘Agile' role to be part of a team that said it was OK to not know everything and you weren't expected to be perfect. This ethos was core and company wide, coming from years of traditional ‘blame' based businesses, it took me two months to believe it, and another four to be able to live it.

I'd like to share some of the experiences and learnings I had coming into a high-performing team as a junior, hired as a developer, but with a background in an area no-one else really specialised in and how that start has informed every day of my career and often broader life since.

• Celebrate Diversity in all aspects of the team.
• Don't 'punish' failure - celebrate it and treat it as an opportunity.
• Be humble and approachable when we have knowledge.
• Be honest when we don't know something.
• Reward honest admissions of ‘I don't know' with positive help (and Ideally treat them as a teaching opportunity)
• Pair! Prolifically. On everything - not just code! ( Meetups / Event organisation / Accounts / Admin / Computer setup / Lunch cleanup)
• Leave everything better than when you came to it. (Do no harm)
• apprenticing/mentoring formally or informally
• Expand our view of what constitutes 'our team' - spreading our values outside the core team helps reinforce them, and allows us to create a more harmonious work environment.

The story of Cyber-Dojo so far - Jon Jagger (Industry & Practice, 30 minutes) [slides]
Abstract: is an innovative, browser based, open-source, environment for practising programming,
conceived, designed, and implemented by Jon Jagger.
It started in 2010 at the Scotsman pub in Oslo.
It's come a long way since then and has hosted over 35,000 practice sessions.
In this talk I will
- recount the origins of cyber-dojo
- describe the value system that influences it's design
- explain some early design decisions
- motivate its unusual use of 'reverse dependency injection'
- reveal some of the hacks to make it work
- recount some of the bugs that escaped testing
- show how the design has evolved
- present some statistics on most common languages,
- etc, etc.

15:45 Break & Agile Clinic
16:15 Metrics and Flow Panel - Agile Hype
Bertrand Meyer, Brian Marick, Mary Poppendieck, Michael Feathers, Dan North
Teaching Agile Just Do It. Don't let me decide
Joe Wright
(previous session continues) Mobbing, Pairing and Open Source TDD (previous session continues)
16.15-17.30 Metrics and Flow (W-A75.PW)
Principles of Agile Metrics - Sunil Mundra (Industry & Practice, 30 minutes) [slides]
Abstract: Agile metrics are very different from traditional metrics. This talk is about the key principles of Agile metrics, which, when understood, will give the audience better insight into choosing as well interpreting the metrics correctly.

Here are some of the principles which I am planning to speak about:

• Outcome over Activity
I will highlight how focusing on measuring completion of intermittent stages and tasks is not helpful, and what actually matters is how much work met the 'definition of done' criteria. The example is team velocity, which is based only on stories which meet the 'DoD' criteria.

• Value over Volume
I will highlight the importance of measuring value addition (business value) over measuring things like how much time was spent, lines of code etc. The examples are business value points signed off and feature completion (comparison of total points of that feature vs. completed points)

• Trends over Absolute Numbers
I will highlight how it is important to look at the overall trend and not just ‘a number. The example will be team velocity, which in reality will never be a straight line. Velocity may drop for an iteration or two, but what is more important is the overall trend

• Systems Thinking over Local Optimization
I will highlight how measuring part of the system is not helpful, and that it is necessary to take the systemic view. E.g. It does not help to focus (and celebrate) development efficiency, when the release process is tedious and all the benefits accrued in the development process are being nullified in the release stage. The example of a metric will be Lead time from requirements to production

• Team Success over Individual Success
I will highlight the importance of meaning of success being common for all team members, as compared with varying success criteria for roles/individuals. An example of individual success metric is number of defects found by the testers before the story is declared as ‘done'. I will highlight how this metric will encourage the testers to not collaborate with the developers. An example of a good metric, instead, is customer satisfaction with quality.

I will also provide examples of metrics, depending on how much time is allocated for the session

Whiskey, Sushi, Systems and Flow - Paulo Caroli (Industry & Practice, 45 minutes) [slides]
Abstract: Come participate in a conversation that challenges you to think about everyday implicit systems and flow parameters. Let's talk about the following: my whiskey bar, my plane boarding skills, the traffic jam on a weekend beach trip, and my frustration while waiting for a temaki on a Japanese restaurant. These examples will guide our conversation about flow parameters, systems thinking, theory of constraint and queues.

Learning outcome:
– Great examples to be used when explaining flow and systems
– Understand flow parameters
– Two simple ways to control lead and cycle time
– How to use the lead time for planning
– The correlation between limiting WIP and lead time reduction.
– A simple life example of Systems Thinking
– An understanding on queues, wait time and class of service

16.15-17.30 Panel - Agile Hype (W-A75.PE)
Panel - Agile Hype - Bertrand Meyer, Brian Marick, Mary Poppendieck, Michael Feathers, Dan North (Panel, 75 minutes)

16.15-17.30 Teaching Agile (W-A75.DU)
Teaching Agile in Higher Education - Katie Taylor, Peggy Gregory (Teaching, 30 minutes) [slides]
Abstract: Whether in a Business or Computing School we need to equip our graduates with industry relevant skills. Agile promotes cross-functional projects that incorporate both technical and business personnel. A range of teaching challenges occur when trying to deliver Agile using the traditional university approach.

· As an academic teaching in this area access to resources, course material and assessment methods based on sound empirical evidence is often difficult
· At undergraduate level students need awareness of the philosophy, principles and process with time to practice a variety of techniques.
· At post graduate level students need to see beyond the hype to understand and evaluate the merits or otherwise of the various approaches.

In this session we will discuss a range of challenges and consider solutions.

Learning by doing: A project-based approach to teaching Agile - Marc Lainez (Teaching, 30 minutes) [slides]
Abstract: For the fourth year, the University of Louvain-la-Neuve in Belgium has been running an experimental Android Agile project with Bachelor students in computer science and engineering. The project is organised for all students in their 3rd Bachelor year and implements a lightweight Agile process in which the teaching-assistants play the role of the Agile coach and the teacher their customer.

It is inspired by SCRUM and introduces the students to other ways of managing requirements and welcoming feedback early-on in their work. Throughout the 3 previous editions, several applications have been deployed to the google play store ( to be used and reviewed by their peers, friends and other android users.

Marc has helped the university define the project process in 2013 and has been following it since it's beginnings. As of 2015, Marc has been offered the opportunity to take over the project as an invited lecturer.

16.15-17.30 Just Do It. Don't let me decide (W-A75.HO)
Just Do It. Don't let me decide - Joe Wright (Industry & Practice, 60 minutes) [slides]
Abstract: "Procedural code gets information then makes decisions. Object-oriented code tells objects to do things." — Alec Sharp

It's all too easy to fall into the trap of asking objects questions and making decisions based on their internal state. We want to send commands to objects and give them the responsibility of handling requests.

Conway's game of life is a popular cellular automaton game. What would happen if you tried to create a solution where no method ever returns a value? Also, just for fun, let's also never use an if statement either. What would this code look like?

During this session we will live code a solution while adopting these constraints. We'll see how removing if statements improves maintainability and discover how object orientated principles support writing loosely coupled code.

16.15-17.30 Mobbing, Pairing and Open Source (W-A75.PO)
Pair-programming from a beginner's perspective - Irina Tsyganok (Experience Reports, 20 minutes) [slides]
Abstract: Many technical teams consider pairing their junior developers with more experienced colleagues as an effective way to upskill their new members. My team at follows the same approach.
However, my experience as a junior developer, who paired with experts on almost every story, showed that simply assigning two engineers with different skill levels to a single task is not enough for a successful pair-programming experience.
In this report I will look at pair-programming from a beginner's perspective, sharing the lessons I learned through my experience at YOOX Net-A-Porter Group over the last 15 months.
The topics I will cover in this report include:
- pair-programming as a social skill: how the level of ‘seniority' affects behaviour and decision-making of the pair
- what I learned about the needs of junior and senior developers when pairing
- what our team found to be most beneficial in pairing novices with experts
- which aspects of pair-programming across skill proved to be ‘pain points' to the team
- a recipe for success: what we did to overcome challenges of pairs with the experience gap, and what we can do to improve further

Arsonists or Firefighters? Affectiveness in Agile Software Development - Marco Ortu, Giuseppe Destefanis, Steve Counsell, Stephen Swift, Roberto Tonelli, Michele Marchesi (Research, 20 minutes) [slides]
Abstract: In this paper, we present an analysis of more than 500K comments from open-source repositories of software systems developed using agile methodologies. Our aim is to empirically determine how developers interact with each other under certain psychological conditions generated by politeness, sentiment and emotion expressed within developers' comments. Developers involved in an open-source projects do not usually know each other; they mainly communicate through mailing lists, chat, and tools such as issue tracking systems. The way in which they communicate affects the development process and the productivity of the people involved in the project. We evaluated politeness, sentiment and emotions of comments posted by agile developers and studied the communication flow to understand how they interacted in the presence of impolite and negative comments (and vice versa). Our analysis shows that “firefighters” prevail. When in presence of impolite or negative comments, the probability of the next comment being impolite or negative is 13% and 25%, respectively; ANGER however, has a probability of 40% of being followed by a further ANGER comment. The result could help managers take control the development phases of a system, since social aspects can seriously affect a developer's productivity. In a distributed agile environment this may have a particular resonance.

Mob Programming; find fun faster - Karel Boekhout (Experience Reports, 20 minutes) [slides]
Abstract: Impressed by the Mob Programming session at XP2015 in Helsinki, I decided to dive into the workings of Mob Programming.

Working for a small company, directly coaching a junior team and a more senior team of developers, I thought it would be a nice experiment to try during the quiet summer months. The junior team consisted fully of young programmers with no previous work experience as developer. There was no senior available to guide them, and we needed some way to accelerate their learning process.

I did a small presentation before the group in which I explained the workings, as far as I understood them at that time, and showed the video of Woody Zuill to illustrate how an experienced team works this way all day.

This isn't a group who by themselves would scout the outer limits of IT innovation, so I didn't expect them to be eager to try this out. The reception was not even luke warm; I would have to earn my pay to get this accepted.

Even after assuring them that it would be a lot of fun, that it was a temporary experiment and that the company, because I told them so, would accept a serious dip in velocity, they were still hesitant.

This meant I had the same dilemma many parents have when trying to get their kids to eat healthy vegetables, like broccoli and brussel sprouts. If I force them, will they hate it for life? If I let them eat what they want, will they explore it in their own time? Or will they will never learn to appreciate it? Or should I just drown it in ketchup and postpone them broadening their experiences? Under the circumstances, I decided to force the issue. We needed some action to improve learning in the team.

In a period of two months, with one full day a week, it proved to be a great experience with a steep learning curve for both the teams as for this coach.

The more senior team disliked the experiment, didn't like the working in a group and kept saying that they thought it was inefficient, even after I made clear that this wasn't their concern, but mine. So we stopped doing it, but I did notice afterwards with some some high pressure projects that they used, by themselves, some elements from this experiment.

The junior team on the other hand has fully embraced it, although they have indicated that they don't want to work this way all week.

I dare to say that because of these weekly Mob Programming days, the team as a whole and all its individuals have grown much faster than they could have done otherwise.

They improved their coding skills, improved in many other aspects, and learned to be much more self-sufficient. Learning would have been even better with a senior as part of the team. but they went forward even on their own.

Conclusion: one team still uses it actively and keeps growing through it. The other team stopped using it, but have learned a lot during the process. And the coach has maybe learned the most.

16.15-17.30 TDD (W-A75.ST)
TDDViz: Using Software Changes to Understand Conformance to Test Driven Development - Michael Hilton, Nicholas Nelson, Hugh Mcdonald, Sean McDonald, Ronald Metoyer, Danny Dig (Research, 20 minutes) [slides]
Abstract: A bad software development process leads to wasted effort and inferior products. In order to improve a software process, it must be first understood. Our unique approach in this paper uses code and test changes to understand conformance to the Test Driven Development (TDD) process. We designed and implemented TDDViz, a tool that supports developers in better understanding how they conform to TDD. TDDViz supports this understanding by providing novel visualizations of developers' TDD process. To enable TDDViz's visualizations, we developed a novel automatic inferencer that identifies the phases that make up the TDD process solely based on code and test changes. We evaluate TDDViz using two complementary methods: a controlled experiment with 35 participants to evaluate the visualization, and a case study with 2601 TDD Sessions to evaluate the inference algorithm. The controlled experiment shows that, in comparison to existing visualizations, participants performed significantly better when using TDDViz to answer questions about code. In addition, the case study shows that the inferencing algorithm in TDDViz infers TDD phases with an accuracy of 87%.

TDD: Cultivating a Beginner’s Mind - Shai Yallin (Industry & Practice, 45 minutes) [slides]
Abstract: How TDD can protect you from your own experience.

What is software design? How does it relate to writing code? many of us are using agile methodologies nowadays, but how can we reconcile these with the concept of software design as we traditionally know it?

In this talk, I will share with the audience my personal journey with Test-Driven Development (and Design) over the last 5 years, a journey that started with me assuming that I know what TDD is and how one should write tests and over time has repeatedly proved me wrong, making me more humble and open to new ideas - and by way of that, helped me become a better engineer.

This is not a talk about code. It's about adopting a Zen-like approach to software design, using TDD as our guide.

17:30 Break & Agile Clinic
18:00 Open space opening
Charlie Poole and Andy Mell
19:00 Open Space
18:00-19:00 Open space opening
Open space opening - Charlie Poole, Andy Mell (Open Space, 180 minutes)
Abstract: The XP2016 Open Space kicks off tonight with an opening session and 3 hours of open space.

19:00-23:00 Open Space (W-OPEN)
Open Space - (Open Space, 240 minutes)
Abstract: As many rooms as we need, for as long as we want.

18.00-22.00 Sponsor's reception and whisky tasting
Sponsor's reception and whisky tasting - JP Morgan (Social)
Abstract: Meet the sponsors, enjoy some more great food and try some of Scotland's finest whisky - with experts on hand to help you get the best out of them.

23:00 Close

Thursday, 26 May 2016

Building JMCC St. Leonards
Room Pentland Duddingston Holyrood Salisbury Pollock St. Trinneans Cowan Bonnar &
West East Brewster
7.00-8.30 Early Morning Activities
7.00 Early morning yoga - Alexis Beddoe (60 minutes)
An hour of Hatha Yoga to get you ready for the day - all abilities welcome.

Mats will be available, but bring your own if you have one.

7.00 Early morning run - Jocelyn Moar (60 minutes)
Join us for a run around Holyrood Park - different routes every day.

Meet outside the reception at the main entrance at 7.00

7.30 Lean coffee - Various (45 minutes)
An hour or so of discussion over coffee, in the Lean Coffee format.

08:45 Keynote: Software engineering in a digitised world Mary Poppendieck
8.45-10.00 Keynote: Software engineering in a digitised world Mary Poppendieck (T-M.K)
Announcements - Seb Rose (Organisers, 10 minutes)
Abstract: Conference announcements

Software engineering in a digitised world - Mary Poppendieck (Keynote, 60 minutes) [slides]
Abstract: Digitisation is happening to businesses everywhere – intelligence is buried in everything from mining equipment to livestock, and the companies that learn how to make the best use of this intelligence will be the winners in the future economy. As modern businesses turn to digitisation to provide the next level of productivity and competitiveness, they find that software is no longer something added as an afterthought to manage the supply chain and track financial transactions.

Software has become integral to the front end of most organisations – software determines how businesses interact with customers, how organisations use assets, how managers make decisions. It is no longer possible to relegate software to a cost centre called IT. Modern Software Engineering takes a lead role in solving business problems and inventing new strategies. This talk is about the new world of Software Engineering.

10:00 Break, Agile Clinic & Poster Session 1
10:30 Improving Software Development Organisations: Startups and Happiness Open Space
Exploiting Fast and Slow Thinking
Rebecca Wirfs-Brock
Modern XP tutorial
Nicolas Paez and Diego Fontdevila
Agile: It's not just about the development team
Andy Longshaw and Kevin Rutherford
Minimum Viability Open Space
Open Space
10.30-12.00 Improving Software Development (T-M90.PW)
Min-Maxing Software Costs - Konstantin Kudryashov (Industry & Practice, 45 minutes) [slides]
Abstract: Software development is riddled with explicit and implicit costs. Every decision you make has a cost attached to it. When you're writing code, you're making an investment, the size of which will for a long time define the costs of your future growth. Making right decision about these investments is very tricky and the cost of wrong decisions might be crippling for both business and teams that support it.

Extreme Programming and Test Driven Development in particular are practices that are aiming at supporting development effort by making it easier to introduce change. That said, sometimes those tools can become a problem of its own when applied in the wrong way or for the wrong context. Understanding software cost forces is a very important skill of successful teams and something that helps understand how to apply XP and TDD in different contexts.

In this talk you will learn how to see, understand and game some of these forces in your favour. This talk will try to present a sense-making model of the software development costs and a way to utilise it for decision-making.

Setting a Good Example: Getting the most out of your BDD, SBE and ATDD artefacts - David Evans (Industry & Practice, 45 minutes) [slides]
Abstract: Specification by Example (SBE), and the related practices of Behaviour Driven Development (BDD) and Acceptance Test-Driven Development (ATDD), are effective techniques to collaboratively drive the implementation of agile stories, using test automation frameworks that blend acceptance tests with specifications and system documentation.

But to get the most out of these techniques you need much more than the right tools. You need high value specifications. How do we get the right level of detail in specifications? How do we express good acceptance tests that are both readable and automated? How do we get long-term value from these as documentation? These and other questions will be addressed in this talk in which we take a practical approach using real-world examples.

If you work with Cucumber, Fitnesse, SpecFlow or similar tools to support BDD and SBE, you will pick up practical tips and advice to avoid common mistakes that teams make when writing tests. You will also learn to recognise the characteristics that take good example scenarios beyond the role of acceptance tests and into living documentation for long-term value.

10.30-12.00 Organisations: Startups and Happiness (T-M90.PE)
Key Challenges in Software Startups across Life Cycle Stages: Empirical Results from a Large Survey - Xiaofeng Wang, Henry Edison, Sohaib Shahid Bajwa, Carmine Giardino, Pekka Abrahamsson (Research, 20 minutes) [slides]
Abstract: Software startups are challenging endeavours, with various road blocks on their path to success. The current understanding of the challenges that software startups may encounter is very limited. In this paper, we use the research framework of learning and product development stages to analyse the key challenges that software startups have to deal with at different life cycle stages, from problem definition to solution validation and from concept to mature product. Based on an analysis of the empirical data collected by a large survey of 4100 startups, we find out that what perceived as biggest challenges by software startups do vary across different life cycle stages. Building product is the biggest obstacle for software startups, even though its significance decreases when the learning focuses of the startups move from problem to solution and their products mature. Business related challenges such as customer acquisition and scaling are more eminent at the later stages. Our study raises the awareness of these challenges and suggest to tackle right ones at the right time.

Happiness Doesn't Deliver Software. So Should You Use It As a Measure? - Katherine Kirk, Pawel Brodzinski (Industry & Practice, 60 minutes) [slides]
Abstract: “Chasing an emotion, like happiness, is not a reliable method of delivery”
~Katherine Kirk.

“Happiness is a useful measure.”
~Pawel Brodzinski

If you've ever tried to bring happiness into an organisation you know how hard is make everyone happy, especially in challenging environments or with political agendas in play. What's more: it could be said that aiming for happiness could actually be counterproductive.

This talk will be a light hearted fun debate between two speakers exploring the use of happiness as a metric, presented via stories based on their extensive professional experience – one who found what they believe is a better alternative to happiness, and another who continues to use it as a metric to this day.

Katherine will discuss her experimentation with Eastern and Tribal philosophical models in the context of IT projects and present an alternative that she believes works surprisingly well. Claiming it provides broader perspective of a situation and arguably enables better choices, especially during tough scenarios, when stress levels skyrocket and delivering within set constraints is paramount.

Pawel, on the other hand, argues that even if happiness is not a perfect goal to aim for, it still provides a meaningful signal to leaders, serving as a team sustainability metric that gives an early warning when all sorts of things go wrong. He will also contend that happiness can be a reliable source of information about behaviors that affect how we make professional decisions. Justifying why he still measures happiness long after he invalidated his initial hypothesis of its use.

10.30-12.00 Open Space (T-M90.DU)
Open Space - (Open Space, 90 minutes)

10.30-12.00 Exploiting Fast and Slow Thinking (T-M90.HO)
Exploiting Fast and Slow Thinking - Rebecca Wirfs-Brock (Industry & Practice, 90 minutes) [slides]
Abstract: As agile team members, leaders and change agents, we can benefit by knowing about how we think, deliberate, and decide. Thinking, Fast and Slow, by Daniel Kahneman, explains two systems that drive how we think. System 1 thinking is fast, intuitive, and emotional; System 2 is slow, deliberate, and logical.

In this session, you will learn how fast and slow thinking affect your decision making and explore how agile practices can amplify your thinking abilities and how they also might lead you astray. For example, Given-When-Then behavior-driven development scenarios are concrete and specific. They prevent you from leaping to conclusions about expected results. Those same BDD specs can also lead you to believe that's all there is. The Pomodoro Technique helps block work into manageable chunks, making time for uninterrupted work. What else can you do to slow down when you need to think things through?

Fast thinking works well in familiar contexts. But fast thinking can lead you to jump to conclusions, be wildly optimistic, or under-assess risks and rewards. You need to exploit both fast and slow thinking on agile projects and be aware of when fast thinking trips you up.

During this session, we explore some impacts of fast and slow thinking. We will practice reframing questions about specific situations in terms of fast and slow thinking and identify specific situations where our thinking needs to shift and explore how to make those shifts.

10.30-17.30 Modern XP tutorial (T-M90.SA)
Modern XP tutorial - Nicolas Paez, Diego Fontdevila (Industry & Practice, 360 minutes) [slides]
Abstract: A long time has passed since the first version of Extreme Programming was published. Many things have changed and new practices and tools have spread in the software development community. Specification by Example, Infrastructure as code, Continuous Delivery and Mob programming are some of them. In this session we will see how these new practices have been adopted by teams practicing Extreme Programming and we will put them in practice a with a software development exercise. We will run 3 time-boxed iterations to develop an application using Java, AngularJS, Git, Jenkins and some other popular technologies and tools.

10.30-12.00 Agile: It's not just about the development team (T-M90.PO)
Agile: It's not just about the development team - Andy Longshaw, Kevin Rutherford (Industry & Practice, 90 minutes) [No slides]
Abstract: Many businesses perceive software development as a blocker. If only the development team could work faster and deliver software at the rate imagined by the wider business. However, what if their dreams came true? Imagine you had a development team that could deliver working software into production every hour. What would that mean for your business? Would your business be able to cope with it and what's more, would it be able to capitalise on it?

This workshop will explore the challenges that can occur when the perceived development bottleneck is removed. Kanban tells us when you remove one bottleneck this exposes others, so which ones would become apparent in your business? Will the new bottleneck be product management, sales, support or another part of the wider business? What problems would be exposed in those areas and how could these be addressed? Are these issues actually impacting your business currently? When all these things are considered, you may question whether development is actually your most pressing bottleneck.

Participants will work in small groups to exchange thoughts and ideas, build them into a coherent viewpoint and present them back to the other groups.

10.30-12.00 Minimum Viability (T-M90.ST)
Minimum Viable User eXperience: A Framework for Supporting Product Design in Startups - Laura Hokkanen, Kati Kuusinen, Kaisa Väänänen (Research, 20 minutes) [slides]
Abstract: Startups operate with small resources in time pressure. Thus, building minimal product versions to test and validate ideas has emerged as a way to avoid wasteful creation of complicated products which may be proven unsuccessful in the markets. Often, design of these early product versions needs to be done fast and with little advance information from end-users. In this paper we introduce the Minimum Viable User eXperience (MVUX) that aims at providing users a good enough user experience already in the early, minimal versions of the product. MVUX enables communication of the envisioned product value, gathering of meaningful feedback, and it can promote positive word of mouth. To understand what MVUX consists of, we conducted n interview study with 17 entrepreneurs from 12 small startups. The main elements of MVUX recognized are Attractiveness, Approachability, Professionalism, and Selling the Idea. We present the structured framework and elements' contributing qualities.

Minimum Viable Product or Multiple Facet Product? The role of prototyping in early stage software startups - Anh Nguyen Duc, Pekka Abrahamsson (Research, 20 minutes) [slides]
Abstract: Prototyping has been a key activity in both business and product development in software startups. We empirically explored five early stage bootstrapping software startups to understand practical development and usage of prototypes. Data was collected from interviews, observation and documents. We found that roles of prototypes in startups were not fully aware by entrepreneurs. Besides a tool for validated learning, prototypes are used to support communication, design process, and later-phase product development. Entrepreneurs should consider strategic plans for prototyping approaches and adoption. The work also implies several research directions about prototyping practices and processes in software startups.

Minimum Viable Quality: What startups always seem to get wrong. - T.H.E. Engineer (Industry & Practice, 45 minutes)
Abstract: The excuse is always: “We have to acquire some technical-debt in order to get to market first.” What they really mean is: “Hack and slash, and just get something working.” This attitude one of the reasons that so many startups fail.

10.30-12.00 Open Space (T-M90.CO)
Open Space - (Open Space, 90 minutes)

10.30-12.00 Open Space (T-M90.BA)
Open Space - (Open Space, 90 minutes)

12:00 Break & Agile Clinic
12:30 Lightning 1
Bringing XP to functional programming (and vice versa) - Part 1
Brian Marick
Open Space
User Focused Practices (previous session continues) The Art of Visualising Software Architecture
Simon Brown
Novel Agile Processes Open Space
Open Space
12.30-13.45 Lightning 1 (T-M75.PW)
Lightning 1 - (Lightning Talks, 75 minutes) [slides]
Abstract: A selection of short presentations (of 5 minutes or less) submitted during the conference.

12.30-13.45 Bringing XP to functional programming (and vice versa) - Part 1 (T-M75.PE)
Bringing XP to functional programming (and vice versa) - Part 1 - Brian Marick (Invited, 75 minutes) [slides]
Abstract: "Things are the way they are because they got that way." - Gerald Weinberg

XP, like everything else, contains traces of its history - traces that, to an outsider, seem arbitrary. The same is true of functional programming (FP). The histories of XP and FP have had little influence on each other. As a fan of both, I think that's a problem.

Possibly it's more of a problem for FP: I see XP insights being painfully and expensively rediscovered.

It's also a problem for XP. When Agile became popular, XP was eclipsed because (1) it requires a lot of discipline, and (2) it focuses on "that point in the proceedings [where] someone competent has to write some damn code" [told to me by a speaker at this conference who, at the time, wanted to remain anonymous]". As Agile became a management fad, that made XP unappealing.

FP is (arguably) at the point object-oriented programming was during XP's heydey: people with money to spend on programmers are willing to risk it on programmers programming in weird ways. IF XP can't jump on this latest bandwagon, it will miss the latest chance to change programming for the better.

Therefore (as we used to say in the patterns days): I want to bring FP and XP together. This conference is a first part of that effort: I hope to have many conversations and Open Space sessions about it.

However: my actual talk will not be about grandiose plans. In the spirit of "writing some damn code", I plan to discuss an FP-friendly programming style that spits in the face of OO wisdom: don't bother with models based on well-defined objects with behavior; instead flow dumb data (arrays and associative arrays) through a series of steps that make the dumb data even more complex (yet still just as dumb). This style eschews object-to-relational mapping for an embrace of SQL. It pays little mind to "didn't we already settle this in 1999?" certainties like "a constructor should fully construct its object". It has to survive (valid!) objections like "In 2002, we concluded that Transaction Scripts don't scale - what's different now?"

My example will contrast the Phoenix web framework (built on the FP language Elixir) to similar OO frameworks that are well-tuned to traditional XP style.

I mean this to provide a concrete example of eternal verities that are no longer true. After all, challenging such things is squarely in the XP tradition.

12.30-13.45 Open Space (T-M75.DU)
Open Space - (Open Space, 75 minutes)

12.30-13.45 User Focused Practices (T-M75.HO)
Focal Points for a More User-Centred Agile Development - Silvia Bordin, Antonella De Angeli (Research, 20 minutes) [slides]
Abstract: The integration of user-centred design and Agile development is becoming increasingly common in companies and appears promising. However, it may also present some critical points, or communication breakdowns, such as a variable interpretation of user involvement, a mismatch in the value of documentation, and a misalignment in iterations. We validate these themes, emerging from both literature and previous fieldwork, in a case study performed in an IT company that adopts both software engineering approaches, and we further extend the framework with a new theme related to task ownership. We argue that communication breakdowns can become focal points to drive action and decision for establishing an organisational context acknowledging the value of user involvement: to this end, we suggest the adoption of design thinking and the active engagement of the customer in embracing its values.

Be The Naturalist! Or: I'm Sorry, Your Mum Is Not a Valid Test Participant - Michael Rawling (Industry & Practice, 45 minutes) [slides]
Abstract: "If you want understand how a Lion hunts, don't go to the Zoo, go to the Savannah."

User Research is one of the cornerstones of UX but the sheer volume of techniques around, combined with jargon and ‘silo'd teams often means the fundamental goal of many approaches like UX and XP always seems beyond reach:

- To bring together (understanding of) the people who use a system with those who actually create it.

Mike Rawling, a ux veteran of products and projects of all sizes and shapes, takes attendees on a safari through the world of user research techniques, combining tried and tested formal UX experiences with the latest practical techniques, hot from the ux trenches you can use as a team. These include methods for user interviews, agile ethnography, user observation and practically testing your ideas with users in a measured way that fits right into the world of digital design and development: without compromising either UX or your XP, Agile, Lean or other development principles.

Those new to UX, new to user research or struggling with getting good feedback will come away from this session with an introduction to using the right types of user research in your Agile/Lean/XP process so they serve as an invaluable source of intelligence for you, your team and stakeholders, whilst most UX practitioners will come away with techniques that can help them solve the conundrum of ensuring rigorous user research in a rapidly changing landscape of disrupted devices, platforms and markets.

12.30-13.45 The Art of Visualising Software Architecture (T-M75.PO)
The Art of Visualising Software Architecture - Simon Brown (Industry & Practice, 75 minutes) [slides]
Abstract: Ask somebody in the building industry to visually communicate the architecture of a building and you'll be presented with site plans, floor plans, elevation views, cross-section views and detail drawings. In contrast, ask a software developer to communicate the software architecture of a software system using diagrams and you'll likely get a confused mess of boxes and lines. I've asked thousands of software developers to do just this over the past decade and continue to do so today. The results from these software architecture sketching workshops still surprise me, anecdotally suggesting that effective visual communication of software architecture is a skill that's sorely lacking in the software development industry.

Of course, as an industry, we do have the Unified Modeling Language (UML), but asking whether this provides an effective way to communicate software architecture is often irrelevant because many teams have already thrown out UML in favour of much simpler "boxes and lines" diagrams. Abandoning UML is one thing but, perhaps in the race for agility, many software development teams have lost the ability to communicate visually. This workshop explores the visual communication of software architecture based upon my experience of working with software development teams across the globe. We'll look at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, the value of creating a model plus how to use tooling and static analysis techniques to automate diagram generation.

12.30-13.45 Novel Agile Processes (T-M75.ST)
Scaling Agility with LeSS - Ran Nyman (Industry & Practice, 30 minutes) [slides]
Abstract: How to scale Agile development and especially Scrum for large organisations is a problem that several scaling frameworks try to solve. This presentation analyzes two cases where Large-Scale Scrum (LeSS) was used successfully. The first instance starts already as early and December 2005 where LeSS was adopted by an organisation using incremental sequential development. The second case is from 2008 - 2010 where LeSS framework was used to build a new product from scratch. Both cases handled are coming from Nokia Networks that is successfully continuing to use LeSS framework in several organisations.

The presentation focuses on several aspect that needs to be dealt with when adopting LeSS for large groups. First we look organisational challenges that one encounters while using self-managing cross-functional teams that are fundamental building blocks of LeSS framework. Then we look the difficulties that organisations face when moving beyond eight teams and one Product Owner can not anymore handle the prioritization for all the teams. The development practices are essential to scaling agility successfully, and this presentation will show what methods were used and how they evolved during LeSS adoption.

At the end of the presentation, there is analysis from both cases where we demonstrate the common success factors that were present in both instances.

Adaptive management - Emma Proud (Invited, 30 minutes) [slides]
Abstract: A confluence of new challenges and greater complexity require aid agencies to be more agile. We need to be able to adapt in a timely and intentional way, by better understanding, and responding to, contextual dynamics. How can we set up our organisations, country offices and programmes to be better able to adapt?

The presentation will look at:

- A case study from Mercy Corps’s work in Uganda which will describe how the programme course was adjusted in light of information received about the context

- An overview of the four elements Mercy Corps are using to think about adaptive programming: organisational culture, people and skills, tools and systems, and the enabling environment

- A description of the ADAPT initiative (Mercy Corps and IRC) which takes a case study based approach to identify the enablers and inhibitors of adaptive management in complex contexts

12.30-13.45 Open Space (T-M75.CO)
Open Space - (Open Space, 75 minutes)

12.30-13.45 Open Space (T-M75.BA)
Open Space - (Open Space, 75 minutes)

13:45 Break & Agile Clinic
14:15 Large Scale Agile The test automation pyramid - does it matter and who really cares?
Elisabeth Hendrickson, David Evans, Steve Freeman, John Smart, Simon Brown
Open Space
A Nest of Tests
James Lyndsay
(previous session continues) EventStorming - Condensed workshop
Alberto Brandolini
Organisations: Motivation and Self-management Open Space
Open Space
14.15-15.45 Large Scale Agile (T-A90.PW)
The Lack of Sharing of Customer Data in Large Software Organizations: Challenges and Implications - Aleksander Fabijan, Helena Holmström Olsson, Jan Bosch (Research, 20 minutes) [slides]
Abstract: With agile teams becoming increasingly multi-disciplinary and including all functions, the role of customer feedback is gaining momentum. Today, companies collect feedback directly from customers, as well as indirectly from their products. As a result, companies face a situation in which
the amount of data from which they can learn about their customers is larger than ever before. In previous studies, the collection of data is often identified as
challenging. However, and as illustrated in our research, the challenge is not the collection of data but rather how to share this data among people in order to
make effective use of it. In this paper, and based on case study research in three large software-intensive companies, we (1) provide empirical evidence that
‘lack of sharing' is the primary reason for insufficient use of customer and product data, and (2) develop a model in which we identify what data is collected, by whom data is collected and in what development phases it is used. In particular, the model depicts critical hand-overs where certain types of data
get lost, as well as the implications associated with this. We conclude that companies benefit from a very limited part of the data they collect, and that lack
of sharing of data drives inaccurate assumptions of what constitutes customer value.

Tailoring Agile in the Large: Experience and Reflections from a Large-scale Agile Software Development Project - Knut H. Rolland, Vidar Mikkelsen (Experience Reports, 20 minutes) [slides]
Abstract: It is not surprising that agile methods are tailored or customized in various contexts and projects. However, there is little advice for practitioners, and empirical studies on tailoring are also hard to come by. Henceforth, the aim of this experience report is to highlight some of the challenges with large-scale agile software development and especially how dealing with these challenges involved continuous tailoring of the agile method in use. In so doing, we report from a study of a large-scale agile software development effort involving more than 120 participants in a Governmental organisation and running for 3,5 years. The project consisted of three deliverables, partly running in parallel after a delivery model based on Scrum. After a much troubled start related to scaling challenges and architecture complexity during the first deliverable, the project was turnaround and the second and third deliverables were portrayed fairly successful by both supplier and customer – including their end users. In this on-going study, we found that novel incremental modifications and ‘skilled' improvisations of the upfront agreed upon Scrum-based approach were increasingly cultivated and diffused through out the project. Noteworthy, we came across the following new practices as the project had been ‘turned around':
1) Various temporary ‘task forces' were established across teams to deal with common challenges such as performance issues
2) ‘Champion roles' were implemented working across teams on specific technology issues for example databases or java scripting
3) ‘Specifying up front' in terms of close collaboration between customer and supplier in preparing user stories, uncovering dependencies and prototyping prior to sprints
4) ‘Mini demos' were improvised in the middle of sprints to get users' feedback as soon as possible, and to do smaller adjustments to features and/or interaction design
5) ‘Re-distributing development tasks' within the current sprint in order to utilize competence across teams and scale the project.

We argue that these novel practices are good examples of agile method tailoring reflecting the complexity and large-scale characteristics of the project. We do not argue that these actual practices denote any ‘ultimate way' of tailoring agile projects, but more on an analytic level – that in succeeding with large-scale projects continuous tailoring throughout the process is necessary. In reflecting upon the establishment of these practices we discuss how some are bottom-up initiatives (1,2 & 4) whereas some are a blend of bottom-up and top-down (3 & 5). Furthermore, we recognize that some of the practices turn out more emergent (4 & 5) whereas some are to a larger extent deliberate (1, 2 & 3). Collectively, then, the project seems to preserve a sense of agility in terms of ‘learning from change'. Additionally, interestingly, some of these practices are seemingly also in conflict with the agile principles – notably (3) focusing on planning. As a concluding remark we carve out some guidelines for tailoring a Scrum-based method in large-scale agile software development projects.

Scaling up the Planning Game: Collaboration Challenges in Large-Scale Agile Product Development - Felix Evbota, Eric Knauss, Anna Sandberg (Research, 20 minutes) [slides]
Abstract: One of the benefits of agile is close collaboration of customer and developer, e.g. in the planning game of eXtreme Programming (XP). This ensures good commitment and excellent knowledge flows of information about priorities and efforts. However, it is unclear if this benefit can be leveraged at scale. Clearly, it is infeasible to have a planning game with several agile teams in the room. In this paper, we investigate how a large-scale agile organisation manages, what challenges exist, and which opportunities can be leveraged. We found challenges to fall into three areas: (i) the ability to estimate, prioritize, and plan; (ii) the context of planning with respect to working environment, team build-up, and team spirit; and (iii) the ceremonial agreement which prom- ises to allow leveraging abilities in a given context.

The Rationale for Continuous Delivery - Dave Farley (Industry & Practice, 30 minutes) [slides]
Abstract: The production of software is a complex, collaborative process that stretches our ability as human beings to cope with its demands.

Many people working in software development spend their careers without seeing what good really looks like.

Our history is littered with inefficient processes creating poor quality output, too late to capitalise on the expected business value. How have we got into this state? How do we get past it? What does good really look like?

Continuous Delivery changes the economics of software development for some of the biggest companies in the world, whatever the nature of their software development, find out how and why.

14.15-15.45 The test automation pyramid - does it matter and who really cares? (T-A90.PE)
The test automation pyramid - does it matter and who really cares? - Elisabeth Hendrickson, David Evans, Steve Freeman, John Smart, Simon Brown (Panel, 75 minutes)

14.15-15.45 Open Space (T-A90.DU)
Open Space - (Open Space, 90 minutes)

14:15-17:30 A Nest of Tests (T-A90.HO)
A Nest of Tests - James Lyndsay (Industry & Practice, 180 minutes) [slides]
Abstract: It is cheap and easy to generate thousands of tiny tests. Building a diagram from the results can help you understand what you've done, and to understand the system you're working with. This approach, while limited, can help identify behaviours that may be missed with simple verification or hands-on testing.

In this hands-on workshop, James Lyndsay will introduce you to the ways that he has used this approach, and to straightforward data and tools that he has found helpful. You will play with interactive demonstrations to gain a visceral understanding, building swiftly from basics into broad tests designed to expose surprises and refine our understanding. We will talk about techniques for test generation and data visualisation, how to use/abuse/reuse unit tests, and how to isolate emergent behaviours in complex interdependent systems. James will highlight the elements of a system that commonly respond well to this approach.

Participants need something to test with – a laptop is better than a phone. Some exercises will need a flash-capable browser.

14.15-15.45 EventStorming - Condensed workshop (T-A90.PO)
EventStorming - Condensed workshop - Alberto Brandolini (Industry & Practice, 90 minutes)
Abstract: How to explore quickly the complexity of a corporate domain, dealing with conflicting requirements form several stakeholders?

EventStorming's recipe is very simple: put stakeholders and developers in the same room, provide them with an unlimited modelling surface and have them start capturing the Domain Events in orange stickies.

Well, ... this is just the beginning. With a step by step process you'll be able to highlight key risks and business opportunities, prioritize features, and have a better design for your enterprise software. Especially if you're into Domain-Driven Design, Event Sourcing and/or Command/Query Responsibility Segregation.

14.15-15.45 Organisations: Motivation and Self-management (T-A90.ST)
Flow, Intrinsic Motivation, and Developer Experience in Software Engineering - Kati Kuusinen, Helen Petrie, Fabian Fagerholm, Tommi Mikkonen (Research, 20 minutes) [slides]
Abstract: Software developers are both users of development tools but also designers of new software systems. This dualistic role makes the developer special user of work-related software. To increase the understanding of developer as a user and to evaluate the ability of common measurement scales to address developer experience, we conducted a survey study measuring developers' flow state, intrinsic motivation and user experience. Used scales included Short Dispositional Flow Scale, items from Intrinsic Motivation Inventory, Short AttrakDiff-2, and our own DX scale. In total, 57 developers from 25 countries responded to the survey. Results indicate that intrinsic motivation and autotelic experience are significant predictors of developers' UX assessment whereas hedonic, pragmatic, and general quality cannot significantly predict it. Moreover, developers' needs are characterized by efficiency, informativeness, intuitiveness, and flexibility of the tool.

Agile testers' identity and TCoE transformation journey in a regulated industry - Michal Dolezel, Theresa Pullen (Experience Reports, 20 minutes) [slides]
Abstract: Over the last decade, a shared-service concept widely known as "Test Center of Excellence" (TCoE) or "software test factory" established itself as a valuable option for many enterprise companies, to support their IT function. The key original benefit was to offer flexible and cost-effective managed test services to internal IT projects, realized in the form of a strategic partnership with a third party as the service provider. However, while the research literature mostly continues to remain silent on the topic, many practitioners argue that as agile development methods penetrate large and complex enterprise environments, we have to change our way of thinking about some of the traditional enterprise IT concepts These practitioners insist the traditional TCoE approach is “breaking down the Agile organisations”.
This reflection exercise summarizes our ongoing experience with transformation of a test organisation (TCoE) in a large multinational pharmaceutical company. This organisation has a managed testing service based on an outsourced, offshore staffing model. At the same time, the IT function in the organisation has been undergoing a multi-year transformation initiative. One of the tangible aspects of this transformation is a shift from fully outsourced IT solutions back to in-house systems development (i.e. partial backsourcing). A new IT hub focused on IT innovation and systems development in several strategic areas was built in Prague, Czech Republic during 2015.
Existing test organisational patterns in EMEA have been heavily impacted by this decision. First, we have got responsibility for redefinition and transformation of the existing TCOE concept in EMEA towards an “Agile TCOE” vision (see e.g., World Quality Report 2015-16). (The first author has been leading the TCOE-in-transition in EMEA. He is also finishing his industrial PhD in Business Informatics/Information Systems at University of Economics, Prague. The second author is a member of the IT leadership team in EMEA. Her responsibility covers Testing and Release Management transformation, including introduction of DevOps principles.)
The responsibility for provision of outsourced, offshored testing services for waterfall-like projects remains with the TCOE. Moreover, the EMEA TCOE is responsible for “agile testing leadership” and provision of embedded test engineers for agile teams collocated in Prague. That means, our collocated agile teams don't have total autonomy because of regulated nature of our business and organisation history. However we seek to follow principles like “community of testers” instead of enforcing existing TCOE processes, as much as possible. Clearly, our main challenge is to develop a new "agile test entity" amidst the established TCOE within the constraints of complex and regulated environment [4] of the pharmaceutical domain.

More specifically, we connect our experience with observed problems in the following areas:
- Hiring a new skill profile into the organisation, to allow us to re-establish a workforce connected to the technology. We debate the resistance this generates, and how we neutralise the impact.
- We follow an approach to “embed” testers within the agile product centric teams.

This brings a crisis of identity :
- Struggles with testers' newly acquired identity as perceived in the light of their previous work experience.
- Interconnected issues of tester's main mission and positioning in the context of different types of testing. We have to define the distribution of a test effort in a cross-functional development team working in the regulated pharmaceutical environment.
- We uncover issues with enabling certain independence of test while still abiding the core agile principles. We have to help testers to strike a balance to not compromise “too much” quality when under the pressure to deliver “minimal viable” product increments.
- Selection of test automation tools for a cross-functional agile development team becomes a source of conflict between testers and developers.
- We encounter divergent core values and presumptions between those who identify with the agile movement, and the concept of ”Agile testing” and those who work within the scope of the traditional process centred test model which is ingrained in our pharmaceutical domain. We describe this as “paradigm incompatibility” and how we have to use “boundary spanners” to connect across these fragmented belief systems [6].
- Establishing foundation elements to support the evolution of the TCoE. This includes re-thinking our funding model and resetting expectations of our supplier partnerships.

Extreme Self-Management: An Alternative Path of Organizational Design - Pawel Brodzinski (Industry & Practice, 45 minutes) [slides]
Abstract: Hierarchical structure is a default pattern of organisational design. We perceive managers as one of the most obvious parts of our professional landscape. In fact, even when we are talking about flat structures we are simply talking about fewer layers of management and not truly flat organisations. Put simply, management hierarchy is a universal power distribution structure in organisations.

At the same time, for past years we have been stressing how important self-management is for effective teams. We see how important distributing authority and autonomy is in order to achieve challenging goals while facing face-paced change.

What would happen if we brought self-management to the extreme, to the point where the whole organisation is collectively and autonomously managed by all employees? Wouldn't it be an interesting experiment to run? It is indeed an experiment that is happening right now at Lunar Logic.

This is a story about our way down the avenue of distributing autonomy, authority and leadership across everyone. It is also a distilled knowledge of what it takes to become an Extreme Self-Management organisation. We need to understand a broad context of organisational design, but surprisingly enough there are only few rules that we need to follow.

Many of the things from this session will sound counter-intuitive and yet they are backed up by research and our personal experience too. Once we connect the dots we won't look at our organisations the same way again.

14.15-15.45 Open Space (T-A90.CO)
Open Space - (Open Space, 90 minutes)

14.15-15.45 Open Space (T-A90.BA)
Open Space - (Open Space, 90 minutes)

15:45 Break, Agile Clinic & Poster Session 2
16:15 Agile apocrypha and an ad-hoc manifesto
Harry Harrold and Rupert Redington
(previous session continues) (previous session continues)
16.15-17.30 Agile apocrypha and an ad-hoc manifesto (T-A.K)
Agile apocrypha and an ad-hoc manifesto - Harry Harrold, Rupert Redington (Keynote, 60 minutes)
Abstract: Harry and Rupert present a survey of the cults, sects and heresies they’ve encountered while working with people “doing agile”, culminating in their formulation of a new “ad-hoc” manifesto.

Doctrinal purists are invited to be appalled.

17:30 Break & Agile Clinic
19.00-01.00 Conference party at Edinburgh Castle
Conference party at Edinburgh Castle - Sky (Social)
Abstract: We have the exclusive use of Edinburgh Castle for the night. All the museums and exhibits will be open throughout.

There will be food, drink, music and dancing.

The castle is within walking distance of Pollock Halls campus, but limited coach space is available for those that need it.

Please wear comfortable footwear - high heels are unsuitable for the castle's cobbled streets.

01:00 Close

Friday, 27 May 2016

Building JMCC St. Leonards
Room Pentland Duddingston Holyrood Salisbury Pollock St. Trinneans Cowan Bonnar &
West East Brewster
7.00-8.30 Early Morning Activities
7.00 Early morning yoga - Alexis Beddoe (60 minutes)
An hour of Hatha Yoga to get you ready for the day - all abilities welcome.

Mats will be available, but bring your own if you have one.

7.00 Early morning run - Jocelyn Moar (60 minutes)
Join us for a run around Holyrood Park - different routes every day.

Meet outside the reception at the main entrance at 7.00

7.30 Lean coffee - Various (45 minutes)
An hour or so of discussion over coffee, in the Lean Coffee format.

08:45 Keynote: Documented requirements are not useless after all Professor Lionel Briand
8.45-10.00 Keynote: Documented requirements are not useless after all Professor Lionel Briand (F-M.K)
Announcements - Seb Rose (Organisers, 10 minutes)
Abstract: Conference announcements

Documented requirements are not useless after all - Lionel Briand (Keynote, 60 minutes) [slides]
Abstract: The Case for Supporting Change, Configuration, and Testing

Many agile methods tend to question, in more or less explicit ways, the benefit of clearly and precisely documenting system requirements. This talk will show, in various contexts, how natural language requirements can be analysed, with the help of Natural Language Processing (NLP), and contribute to providing significant automation for important development activities. Examples that I will cover include change impact analysis, system test case generation, and automated configuration of product lines. I will illustrate my points using results from collaborative research projects with industry, in contexts where requirements are expressed in natural language, either as statements or as use cases. Whether such approaches are beneficial does nevertheless depend on many contextual factors that I will try to identify and discuss throughout the talk.

10:00 Break & Agile Clinic
10:30 Innovative Testing Refactoring cards and code, a success and many failures
Willem van Den Ende and Marc Evers
Open Space
Working Effectively With Legacy Tests
Nat Pryce and Duncan McGregor
How Long Is a Piece Of String?
Sean Moir
Harnessing the Power of Simple Rules for Coherent Teams and Complex Teamwork
Diana Larsen
Advanced Scrum Open Space
Open Space
10.30-12.00 Innovative Testing (F-M90.PW)
Agile Testing on an online betting application - Nuno Gouveia (Experience Reports, 20 minutes) [slides]
Abstract: My name is Nuno Gouveia and I am a Quality Analyst at Blip and I've been working on a multidisciplinary Scrum team for the past 2,5 years.
Blip is part of the Betfair group, one of the biggest online betting companies in the world. In such a demanding market, the need for constant innovation means that we need to have new features out the door fast, in order to beat the competition. In such a changing environment it is necessary to have a solid quality assurance process that gives us the necessary confidence to deploy our application often in production. This process has evolved over the time with input from Delivery Managers, Developers but mainly Quality Analysts. In this presentation I intend to share some of the processes and techniques we use in order to deliver quality, working software twice a week to production.
There are three main topics that I want to cover in the presentation: our CI pipeline, exploratory testing and documentation.
Firstly I would like to talk about our Continuous Integration Pipeline. The main tasks performed by the pipeline are building and deploying a specific version of the code in the master branch and running unit and functional tests on that version. The unit tests run on the build phase, and the functional tests run after the deploy on a testing environment. The functional tests are built using protractor and are divided in three steps: Smoke (~40 tests), Mock (~330 tests) and End to End (~70). We have a small load of Smoke tests once these tests are mainly to verify that certain modules are loaded correctly in the page. The highest load is focused on Mock tests, because we believe that this is the most efficient way to test our application in isolation from the services layer. To achieve this isolation we test each module individually using a sandbox developed in-house. Finally we do some End to End tests to assure the correct integration between different modules of the application.
Secondly I will talk about our approach to exploratory testing. Over the time we tried to push this testing phase to the earliest stage possible, meaning that it occurs before the code is submitted to the CI pipeline. With this change we decreased drastically the cost of fixing a bug in User Stories that haven't yet been accepted by the product owner.
Finally I would like to talk about our approach to documentation. We use Rally to manage our User Stories and Defects. This is a great tool but we sometimes felt lost in terms of documentation and didn't have a source of information with an overview of all the features of the application. To solve this problem we created a structure of interconnected mind maps representing every feature of the application, divided in the different modules. This “document”is updated every time a new User Story is developed and can now be used as an “oracle” of the behavior of the application.

Mutation testing in practice - Henry Coles (Industry & Practice, 30 minutes) [slides]
Abstract: Mutation testing is a method for assessing the strength of a test suite. It is considered to be the “gold standard” for test coverage.

Since it was first suggested in 1971 mutation testing has been the subject of considerable research and has become an essential experimental technique for assessing other testing approaches.

Until recently it was however rarely used outside of academia. This session will look at why mutation testing is now beginning to see widespread use in industry.

It will discuss the theory behind it, how to apply it successfully, and the sometimes surprising benefits it can have for development teams.

"So what DO you do if you don't do testing?!" - Sally Goble (Industry & Practice, 30 minutes) [slides]
Abstract: The new CTO was clear: the days of the tester were over. Manual Testing? Retired. Automated testing? A developer's thing. “From now on, it's all about quality!” said the CTO with a wag of the finger. The room full of testers nodded in agreement and secretly thought: “*Quality? What on earth does that even mean?”

The Guardian's Head of quality will recount stories (successful and otherwise) about adopting a holistic approach to quality, and takes attendees through experiments and lessons learned along the way.

This is a story of how and why we at the Guardian found ourselves ditching conventional approaches to testing - and instead learned to find more creative ways to improve quality, and evolved our role.

Current received wisdom is that automated testing coupled with continuous integration allows software companies to deploy and release software more frequently. On the contrary - we found that deploying more frequently and more efficiently freed us from the shackles of long suites of automated regression and allows us to think about quality of our products in a more holistic way.

This talk will outline, from a tester's point of view, how changes in our culture, our architecture, adoption of continuous integration and other technologies have changed everything about the way we work - for the better. From monitoring and alerting, from automating analysis of our users' feedback to tracking the negative impact of dodgy ads on our website, we will talk about the things we have done to make every person in our team care about quality in a more holistic way; and have more importantly changed who we are and what we do.

10.30-12.00 Refactoring cards and code, a success and many failures (F-M90.PE)
Refactoring cards and code, a success and many failures - Willem van Den Ende, Marc Evers (Teaching, 90 minutes) [slides]

We have been teaching Refactoring consciously since 1999 in one form or another. We did research on it and used automated refactoring tools several years before that. It was quite a challenging journey to discover how we could teach Code smells and Refactoring well, in a way that participants found fun and effective, and that did not have us talking for a long time.

We've found that in order to do a refactoring exercise well, participants need to know at least 5 code smells and 5 refactorings. Presenting these through slides takes at least 45 minutes. After several years of trial and error, we eventually developed a deck of refactoring cards, that allow us to let participants work on refactoring after a demonstration of about 10 minutes.

We also created a small ‘refuctored' code base that has most of the code smells in the deck. It is small enough to be understandable in a classroom situation, but looks sufficiently like ‘real-world' code. This also required a number of trials and many errors, where we tried different horrible code bases, most of which turned out to be way too complex to be used in a 2 hour workshop.

Join our presentation to see our journey, hear about what worked and what failed (spectacularly so) and learn more about what materials - both cards and code - make for effective learning for practitioners. Learn more about how you can teach code smells and refactoring effectively to students, colleagues & friends.

This might appear to be a product presentation - however, we don't sell (or expect to sell) refactoring cards in sufficient volumes to make up for the work we put in them. We use them as part of our training courses, and hand them out for free at conferences, because this is the one tangible item that explains best how we work.

10.30-12.00 Open Space (F-M90.DU)
Open Space - (Open Space, 90 minutes)

10.30-13.45 Working Effectively With Legacy Tests (F-M90.HO)
Working Effectively With Legacy Tests - Nat Pryce, Duncan McGregor (Industry & Practice, 180 minutes)
Abstract: The adoption of automated testing has locked down the behaviour of a lot of code, which can be a blessing and a curse.

These days we spend a lot of our time fighting tests which slow down our refactoring because they have failed to improve the design of the system. They often run slowly, are unreliable, and communicate little about intended behaviour or why they fail.

We can only describe these as "legacy tests".

Indeed, we go so far as to state that you have legacy tests if you usually change production code and then fix the tests to match.

We might be tempted to wonder whether these legacy tests are earning their place in our codebase.

In this workshop, we invite you to bring your unloved legacy tests to a group therapy session. We'll work together to help them change, curbing their destructive behaviours whilst improving their documentation of the system. In a non-judgemental, supportive environment we'll all help the tests to become productive members of society.

We will run the workshop as a cross between a mob programming session and a clinic. Bring some legacy tests from your own projects. We will work together, in a mob programming style, to improve them. Along the way we will share techniques for writing effective tests and refactoring tests from burdensome legacy to a strategic asset.

If you do not have a tests to share, there will be lots to learn as we work through other people's issues.

10.30-12.00 How Long Is a Piece Of String? (F-M90.SA)
How Long Is a Piece Of String? - Sean Moir (Industry & Practice, 90 minutes) [slides]
Abstract: In Lean terms, Estimating can be considered as waste since it doesn't directly contribute to product. When we have enough data, we can use Probablistic Planning techniques, but what about before we have a large set of data? What if our broad brush Estimates could be considered good enough? What if we could forecast story duration based on previous performance? What if we could answer almost every conceivable delivery forecast question to a known degree of certainty? This session aims to equip you with a simple technique to answer all of these questions using a small amount of data.

In Software Development, as with many other fields, we can gain insight from forecasting. It is tempting to think that for useful forecasting we require large numbers of data points, or we must make assumptions about the distribution of the data which is yet to emerge, or that the technique must be complicated in a mathematical sense. The technique illustrated in this session is valid from when a single data value is gathered, makes no assumption about the distribution of the data values, and is very simple.
In this session, pieces of string of varying length will be selected from a bag. Based on the measured values at each stage, we will analyse the data and consider what is likely to happen next, and how likely it is to happen. The string lengths are a metaphor for other measurements and metrics which we may be interested in, such as the length of time to complete a User Story.

Take Aways
A simple technique for making sense of recorded data, allowing us to forecast future outcomes with a known degree of certainty. The technique works for very small sample sizes so can be used to give early indication of likely project duration, or the likely performance of new teams.

10.30-12.00 Harnessing the Power of Simple Rules for Coherent Teams and Complex Teamwork (F-M90.PO)
Harnessing the Power of Simple Rules for Coherent Teams and Complex Teamwork - Diana Larsen (Industry & Practice, 90 minutes) [No slides]
Abstract: As teams of knowledge workers, Agile teams form self-organising, complex adaptive systems (CAS). In every CAS a set of Simple Rules creates coherent behaviors. Taken together these behaviors form patterns. When the patterns produce value, everyone wins. These patterns help team members build working relationships; make sound decisions; and learn from each other. When patterns produce dysfunction, everyone suffers. While Simple Rules are always present in CAS, they may not create patterns that lead to the outcomes we want. Attend this session with Diana Larsen to learn more about how to identify Simple Rules for your teams. Learn the role that Simple Rules play in Agile team chartering and ongoing development. Discover how to harness the power of Simple Rules.

10.30-12.00 Advanced Scrum (F-M90.ST)
Team Portfolio Scrum: An Action Research on Multitasking in Multi-Project Scrum Teams - Christoph Johann Stettina, Mark Smit (Research, 20 minutes) [slides]
Abstract: Multi-project agile software development is a relatively new area of research. While original Scrum caters for a sweet-spot of co-located teams working on a single project, multi-project Scrum teams are day-to-day reality, especially in small organisations. Multitasking across projects is frequently associated with loss of effectiveness, however, there is a lack of empirical evidence. In order to better understand the phenomenon, we review existing literature across scientific domains and execute an action research project. Our findings show that the designed Team Portfolio Scrum (TPS) practice to support multitasking across projects is perceived as useful, however, at expense of additional overhead.

Quality Assurance in Scrum Applied to Safety Critical Software - Geir Kjetil Hanssen, Børge Haugset, Tor Stålhane, Thor Myklebust (Research, 20 minutes) [slides]
Abstract: Agile methods, like Scrum, have several quality assurance mechanisms embedded in the process itself, without any explicit QA role. By principle, the team takes care of quality assurance during sprints and as part of daily stand-ups, sprint reviews and retrospectives. We have defined SafeScrum, a variant of Scrum that can be used to develop safety-critical software and have the software certified according to the IEC 61508 standard. This imposes a load of additional requirements on the process. In a recent industrial case, we have experienced that the quality assurance mechanisms in Scrum becomes insufficient. We have therefore analyzed the standard, consulted an independent assessor and worked with the Scrum team to identify necessary additional tasks for a team-internal QA role.

The Sprint Goal as a Business Test - Wouter Lagerweij (Industry & Practice, 45 minutes) [slides]
Abstract: Of the original XP practices, the one that seems the most difficult to get right is the on-site customer. In the original XP team, this was an actual end-user of the, internal, system that was being built. How did the Product Owner turn into a project manager simply working down a long, predefined backlog?

The Product Owner role quite often has devolved into a step in a waterfall process. A gateway, or proxy, sometimes a firewall, towards the rest of the organisation. But customer feedback is a fundamental basis of any Agile process.

In this talk, I'm proposing that the common way of working down a backlog of user stories is at best a crutch, and prevents organisations from benefiting from even the most highly performing teams. We invest in getting our development organisations as Agile as possible, but never fully capitalize on the opportunities that gives us.

I will discuss how we can use clear goals, captured in actionable metrics to guide our teams in growing the software necessary to reach those goals.

I'll show how to get development teams to demonstrate their progress based on business metrics, not just features completed. To strategically align development with the rest of the company. And how this allows you to optimally use the brightest minds in your organisation for innovation.

10.30-12.00 Open Space (F-M90.CO)
Open Space - (Open Space, 90 minutes)

10.30-12.00 Open Space (F-M90.BA)
Open Space - (Open Space, 90 minutes)

12:00 Break & Agile Clinic
12:30 Herding Cats: Coaching Techs & Execs
Katherine Kirk
Can XP Close The Gender Gap?
Clare Sudbery
Open Space
(previous session continues) Bourne Again. Bootstrap a testing framework in BASH
Rob Westgeest
Continuous Delivery Lightning 2
Open Space
Open Space
12.30-13.45 Herding Cats: Coaching Techs & Execs (F-M75.PW)
Herding Cats: Coaching Techs & Execs - Katherine Kirk (Invited, 75 minutes)
Abstract: As our context gets faster and more complex, hierarchical decision making - from strategy to technical and everything in between - is on the out. No matter how much introverts and power-interested execs may sulk, noone has the time anymore to wait for the perfect answer, from the perfect person, in the perfect format, in the perfect steps with everything perfectly considered. We gotta know yesterday, and decide with whoever is doing the work, and do it right away … that’s empowerment, right? That’s ‘continuous improvement’, right?

And so, in this environment, over the last decade Techs and Execs have been dragged out of their warm, dark corners and made to collaborate in the cold light of day for the sake of business advantage. We call that being ‘agile’ or ‘lean’.

Well… there’s few ways this can go spectacularly wrong - and one of those ways can be the way a coach or facilitator can unintentionally approach this process of herding cats.

In this talk, Katherine will draw on her experience as an ‘alternative Agile/Lean Coach’ and utilise Eastern and Tribal philosophical models to point out 3 very simple ways she keeps the ‘dark side’ of coaching in check, and consistently aspires to achieve coaching nirvana - ‘Insight Facilitation’ - unashamedly pointing out how she learned it all the hard way.

12.30-13.45 Can XP Close The Gender Gap? (F-M75.PE)
Can XP Close The Gender Gap? - Clare Sudbery (Industry & Practice, 90 minutes)
Abstract: "Women in Technology" is a hot topic, and arguably more so for teams using agile and XP practices. Are there and should there be more women in these teams?

There is still a wide belief that girls aren't as good as boys at logical problem solving. Many women, even those who have had years of success in a male-dominated industry - still find themselves fighting an inner voice which suggests that, because they are female, they are therefore inferior.

However, there is a significant will in the IT industry to increase the numbers of women working in IT. And arguably, teams practising agile and XP have the edge when it comes to tempting women into the profession. Not only that, but gender diversity may be more important for agile and XP than any other methodology. However, is this true? And if so, how can we use this to make a real difference?

This "goldfish bowl" session will provide a unique forum for anybody to get up from the floor and say their piece, in an inclusive non-judgmental environment. Obviously it is important for women to join this discussion, but we would also particularly like to encourage men to get involved: This issue cannot be addressed without the full participation and involvement of men in the industry.

The beauty of the goldfish bowl format is that it makes it uniquely easy for anyone to be involved in the discussion, whether they have a lot or a little to say.

12.30-13.45 Open Space (F-M75.DU)
Open Space - (Open Space, 75 minutes)

12.30-13.45 Bourne Again. Bootstrap a testing framework in BASH (F-M75.SA)
Bourne Again. Bootstrap a testing framework in BASH - Rob Westgeest (Industry & Practice, 60 minutes) [slides]
Abstract: Choosing a language for automating small build tasks feels like choosing a problem. For scripting languages like python and ruby you end up learning and polluting your machine with pip, virtualenv, chruby, rubygems and the like. And while bash is always around, it simply is not powerful enough!

Or is it? Am I just overly anxious about doing anything serious in bash? Do I just need a bit of courage to try and express intent in this awkward, inconsequent odd language?

I wanted to learn more about bash as a scripting language. Therefore I decided to bootstrap a test framework, as it is a great way to learn or explore a programming language in baby steps.

In this kata I will take you through the steps of bootstrapping a testing framework in baby steps, very much in the style of Kent Beck's Test Driven Development by example. In other words we'll Test Drive a bash unit testing framework.

The session is an exercise in writing your own testing framework as much as it is a learning experience in bash.

12.30-13.45 Continuous Delivery (F-M75.PO)
Testing In a Continuous Delivery World - Wouter Lagerweij (Industry & Practice, 30 minutes)
Abstract: Hey, do you remember when everyone was asking what the role of the tester would be in an agile team? It's happening again!

And things are changing again. A team that takes on the challenge to release their every commit certainly will take testing seriously. It will need to evolve new ways of testing. It will have new dynamics of testers working with developers. It will find new ways of of interacting with customers, stakeholders and product owners.

In this talk we'll look at how continuous deployment changes the dynamics of an agile team. How quality moves even more to the center of the stage. How that changes the role of the tester once again. How it changes the role of developers, too. How this practice allows you to put the customer center stage again. And how that, too, has testing competencies at its core. And we'll not forget DevOps, and how monitoring can be a continuous testing strategy.

Continuous Delivery for Embedded Software - Mike Long (Industry & Practice, 30 minutes)
Abstract: Continuous Delivery is all the rage, but many of the practices are not applied in the embedded world because the tools seem to focus on the web development community. That is a great shame, because there is a great deal we can apply on our embedded software development projects. This talk will show you how to apply some of the key techniques, such as embedded versioning and software traceability, embedded continuous delivery pipelines, acceptance testing with hardware, automatic deployment to hardware, continuous deployment. Beyond that, the talk will show some real-life examples of companies who are at the leading edge of this adoption.

12.30-13.45 Lightning 2 (F-M75.ST)
Lightning 2 - (Lightning Talks, 75 minutes) [slides]
Abstract: A selection of short presentations (of 5 minutes or less) submitted during the conference.

12.30-13.45 Open Space (F-M75.CO)
Open Space - (Open Space, 75 minutes)

12.30-13.45 Open Space (F-M75.BA)
Open Space - (Open Space, 75 minutes)

13:45 Break & Agile Clinic
14:15 Agile Transformations Learning at work 2 Open Space
Co-Facilitation for Transformation: How To Let People Let Go
Diana Larsen and Ken Power
Test Driven Debugging - The Saff Squeeze
Mark Kirschstein
Woody Zuill
Let's code like François Morellet would paint
Étienne Charignon and Jonathan Perret
Open Space
Open Space
14.15-15.45 Agile Transformations (F-A90.PW)
Agility Measurements Mismatch: A Validation Study on Three Agile Team Assessments in Software Engineering - Lucas Gren, Konstantinos Chronis (Research, 20 minutes) [slides]
Abstract: Many tools have been created for measuring the agility of software teams, thus creating a saturation in the field. Three agile measurement tools were selected in order to validate whether they will yield similar results. The tools' surveys were given to teams in Company A. The questions were grouped into agile practices which were checked for correlation in order to establish convergent validity. In addition, we checked whether the questions identified to be the same among the tools would be given the same replies by the respondents.
We could not establish convergent validity since the correlations of the data gathered were very few and low. In addition, the questions which were identified as the same among the tools did not have the same answers from the respondents. We conclude that the area of measuring agility is still immature and more work needs to be done. Not all tools are applicable to every team but they should be selected on the basis of how a team has transitioned to agile.

Agile to Eliga to Agile -- Our story of agile re-transformation - Sandeep Hublikar, Shrikanth Hampiholi (Experience Reports, 20 minutes) [slides]
Abstract: Cisco Video Technologies India started its agile transformation journey 2 years back. Journey was very challenging, but also a very interesting journey, with a lot of opportunities on the way, a lot of learning and successful results. Slowly customers were happy by improved quality of on-time deliverables.

Within the span of we had successfully transformed dealing with our real world challenges through

1. Transitioning from Component to Feature teams
2. Continuously aligning multilevel agile planning
3. Providing role clarity and setting expectations
4. Enabling technical infrastructure to implement relevant engineering practices
5. Establishing and nurturing Community of Practices based empirical learning structures
6. Establishing culture of transparency and accountability across organisation

Any transformational journey is a work in progress either we keep improving or we start declining, like wise since last few months our transformation had hit a plateau and the inefficiencies were creeping back in the organisation Motivation levels were somewhat low thanks to some unaddressed systemic obstacles. There were strong indications as to transformation would fizzle out after few quarters at this rate.

At this moment the necessity to pause and retrospect our transformational journey and transformation goal was strongly felt by the organisation. This retrospection gave birth to transformation 2.0, the objective of which was not only to sustain the agile practices but to learn from our agile implementation, implement the learning and take our agile transformation to next level.

This experience reports outlines the challenges faced by an organisation in scaling while sustaining business continuity. The report continues to discuss the journey of cisco video business unit's in overcoming these challenges in taking our transformation to next level which we very well know is NOT the final level as the journey continues.

University of Vienna's U:SPACE – Turning Around a Failed Large Project by Becoming Agile - Bernhard Pieber, Kerstin Ohler (Experience Reports, 20 minutes) [slides]
Abstract: In 2012 the University of Vienna started the SSP project, large scale software development project to implement a new service portal to be used by the university's 93.000 students and 9.000 staff.
In 2014 it became apparent that the project was going nowhere and its ambitious goals could not be reached. An important project milestone came nearer. The results so far, however, were practically unusable. Morale hit rock bottom, trust between business and IT was low, fighting with the main contractor started. The rectorate and managers responsible for the project decided they needed nothing short of a complete restart.
This time around they decided to use an Agile software development process. IT had been thinking of and experimenting with Agile methods before in a small scale project and was convinced of its potential. It was to be the first large project in that large organisation University of Vienna to which Agile would be applied for real. Could it work this time? To say the sceptics were the majority would be an understatement. But what else should they do?
So they started change2agile, an organisational change project to prepare the IT department responsible for the software development project to switch to an Agile development organisation. The business departments they worked together with and other stakeholders were invited to participate. Interestingly, the organisational change project itself was run as a Scrum project, with change teams, sprints, reviews, and retrospectives, and all.
After half a year of intense preparation, on October 27th 2014 they started four cross-functional Scrum teams, two of which were assigned to the to be restarted SSP project. To bring in real world experience they hired an external operational project manager and an external Agile coach.
After a little more than one year, the project – renamed to U:SPACE – is on a great track. Four teams are working on it now. It has delivered useful results to its users. The rectorate and managers are very pleased how the project has turned around. The relationship between business and IT has reached new levels of trust. A survey of business departments affected by the switch to Agile software development yielded great results. Enthusiasm, optimism, and fun, missing for so long, are back.
Of course, not everything went smoothly. A lot of planned functionality is still missing. Some things still need to be improved. Some dangers still await us. However, there is little doubt now that the project ultimately will be successful, that the teams will deliver, that Agile is the way to go. There is confidence that together we will succeed.
In this experience report we want to share our journey with a wider world of Agile practitioners, tell about the good, the bad, and the ugly parts of our itinerary. We would like to share with you what we learned, discuss with you what we still don't know, and – in our presentation – together with you find out which our stories are worth spreading.

Smoothing the Transition from Agile Software Development to Agile Software Maintenance - Stephen McCalden, Mark Tumilty, David Bustard (Experience Reports, 20 minutes) [slides]
Abstract: Kainos is a software company based in Belfast, Northern Ireland. As well as bespoke development, its work includes service contracts for the maintenance of software created elsewhere. This type of work is challenging because of the knowledge transition involved. The experience reported here is of tackling such projects in a way that integrates with the agile processes of the client. Background on agile practice in Kainos is discussed before focusing on a specific project for the UK Government Cabinet Office.

14.15-15.45 Learning at work 2 (F-A90.PE)
From New Hire to Team Contributor, ASAP: How Asynchrony Prepares People to Deliver - Matthew Philip (Industry & Practice, 45 minutes) [slides]
Abstract: How do you help a new hire start contributing to an agile delivery team in as little time as possible? This talk reviews how Asynchrony — an agile software-delivery firm expanding and hiring rapidly — prepares its people to deliver greatness through their Learning Team, an ongoing internal team where new hires and veterans alike can safely learn new skills like TDD, pairing, continuous delivery and forecasting without estimates so that they can hit the ground running with a customer-facing team.

Participants will learn from this experience -- itself a year-long experiment — about its short- and long-term benefits, things that have worked (and things that haven't) and how their organisations might be able to emulate this approach to safe onboarding and new-skill acquisition.

For more detail, you can read my blog post about it at:

Sharing is the new teaching! - Juliano Ribeiro, Marcelo Walter (Teaching, 45 minutes)
Abstract: The information era is gone. I remember those days, when consulting the encyclopedias given by my grandpa would push me to the top of knowledge, far ahead of my fellow colleagues. That era is long gone. The learning protagonist is no longer the one who possesses the information. Nowadays, the coach is only a conductor, who manages and coordinates a group, full of knowledge by themselves, but in need of being organised, structured and shared by everyone.

At this session, we will show the major characteristics of Learning 1.0 and 2.0. You will see that each of these models are not so bad by itself, but each of them needs to be applied at specific moments. We will show also, how much our learning model is intrinsically connected with the company's organisational structure, and how much harm it causes to agile learning.

Finally, we will present the Learning 3.0, based on the emerging learning, where the focus points to sharing ideas in order to solve real world problems. Discussions and debates enrich the learning, where the expert acts like a facilitator, mediating discussions in order to keep people focused at the original issue, searching for the best solution's idea.

14.15-15.45 Open Space (F-A90.DU)
Open Space - (Open Space, 90 minutes)

14.15-15.45 Co-Facilitation for Transformation: How To Let People Let Go (F-A90.HO)
Co-Facilitation for Transformation: How To Let People Let Go - Diana Larsen, Ken Power (Industry & Practice, 90 minutes)
Abstract: “What got us here, won't get us there.” Great facilitation enables people to embrace uncertainty, and ambiguity. Creating space for a group of people to create surprising results needs more than process and structure. For the group to emerge from the experience with a new identity, we need to create new options: new options for connecting and relating, for listening, new options for letting go so that something truly new can begin.

At the core, this kind of facilitation requires you to fully focus on your clients' needs, which means putting your own to the side. We want them to see new information, and we do not want to tell them. How do we create that kind of awareness, that kind of trust? How do we enable a group to become fully present, allow the system to see itself, so that new choices become possible?
In this workshop, we will share our magical toolbox: Facilitation for transformation is all about coherence, connecting, and modelling: listening and letting go. You will learn how to create and hold a space in which you can direct your clients' attention. How to employ your relationship to serve the people's purpose. How to focus their attention on the results they want, help responsibility and accountability grow.

From retrospective to open space, leadership offsite to team building event, the thinking, feeling and doing you take away from this workshop will help you support people discovering and execute real options.

10.30-12.00 Test Driven Debugging - The Saff Squeeze (F-A90.SA)
Test Driven Debugging - The Saff Squeeze - Mark Kirschstein (Industry & Practice, 90 minutes) [slides]
Abstract: The saff squeeze was introduced by Kent Beck as a means of hunting down bugs using tests instead of the debugger.

It is a divide and conquer technique of eliminating bugs that leaves a trail of tests in increasing granularity that can be kept or refined as appropriate after the bug has been fixed. In a legacy code base, it is a useful tool to wrestle control back.

In this session, we will wrap tests around some buggy code in an application and hone in on a bug as a mob programming session. The application is a hello world demonstration, it is some ~3k LoC big.

14.15-15.45 NoEstimates: (F-A90.PO)
NoEstimates: - Woody Zuill (Industry & Practice, 90 minutes)
Abstract: The default use of an “estimate-driven” approach is pervasive in software development efforts. While estimates can be useful, it is worthwhile to scrutinize our use of estimates, and to seek better ways to manage the development of software when estimates are not appropriate. [NOTE: For this session, I am referring to the use of estimates of cost, time, or effort for software projects, features, or tasks.]

There are a number of things to explore. For example: What do we use estimates for? Are we getting a reasonable benefit from them? Do we really need estimates for everything we currently use them for? Is it possible to manage software development without estimates of cost, time, or effort?

We'll do an exercise or two to get an idea of the nature of software development. We'll move on to some information gathering exercises to help us gain a shared idea of our current understanding of the purpose and use of estimates, and then discuss some ideas about possible other ways to approach our work.

14.15-15.45 Let's code like François Morellet would paint (F-A90.ST)
Let's code like François Morellet would paint - Étienne Charignon, Jonathan Perret (Industry & Practice, 90 minutes) [slides]
Abstract: During this 90 minutes session, the presenters will live-code the drawing of a painting inspired by François Morellet's artwork.

Starting from one painting of the artist, that we will start to recreate using Processing programming language, we will subtly drift as the audience give us wishes and instructions.

This performance has already been run at the Beaubourg Museum in Paris for "La fête du code créatif" in November 2015.

14.15-15.45 Open Space (F-A90.CO)
Open Space - (Open Space, 90 minutes)

14.15-15.45 Open Space (F-A90.BA)
Open Space - (Open Space, 90 minutes)

15:45 Break & Agile Clinic
16:15 Keynote: The Odd Couple Nat Pryce and Steve Freeman
16.15-17.30 Keynote: The Odd Couple Nat Pryce and Steve Freeman (F-A.K)
The odd couple - Steve Freeman, Nat Pryce (Keynote, 60 minutes)
Abstract: As an industry, we don’t know how good code should be. Some people say that the most important thing is rapid feedback so just get something working and move on. Others say that they’ve seen too many systems fail from code that has become too complicated to understand, so keep it clean.

Is this just a matter of personality? Steve is sensitive to the development “friction” that bad code brings with it, the effort lost in understanding what it’s supposed to do. Nat is more accepting of bad code, seeing it as a valuable source of information and a reassurance that the system is actually being used.

In this talk, Nat and Steve will work out their differences—illustrated with stories, credibility-stretching analogies, and pretentious diversions. They’ll finish with some concrete suggestions as to what you can do for poor quality code and what it can do for you.

Closing remarks - Seb Rose (Organisers, 10 minutes)
Abstract: Conference closing remarks

17:30 Close