Many agile development teams deal with restricting environments which make it impossible to “done” any feature in an iteration. These restrictions originate in external regulations (laws, norms) and internal habits of an organization.

If it is not possible to remove these impediments, how are you able to get your features done? How to strengthen agile approaches in such environments?

This workshop elaborates the Definition-of-Done in regulated environments for further transition to agile development. Participants exercise tailoring their own environments for improvement.

It seems to be a common understanding that retrospectives are the major practice that enables agility. However, conducting virtual retrospectives is often not straight forward. One possibility is to conduct a retrospective at each site and then to swap the different findings afterwards. Another one is to facilitate a joint virtual retrospective using different virtual communication channels. In this workshop we will explore practices and facilitation techniques that have helped in different global projects. Moreover we’ll indicate supporting tools and how to prepare such a workshop.

For any code base, ill- or well-structured, there comes a time when you want to change large portions of it to meet new functional requirements or a new business model. When these changes become extensive, it’s easy to get lost in a jungle of dependencies, or on a sea of broken code.

This session presents ‘The Mikado Method’, a systematic approach to large changes. It helps you visualize, prepare and perform business-value-focused refactorings, without having a broken code-base. It also enhances communication, collaboration, learning for teams and helps individuals stay on track.

This will be an interactive workshop where the Scrum Masters will be able to share their frustrations and experiences with others in a similar situation. The main purpose is to help Scrum Masters to work systematically with process improvement. One key point here is to understand the difference between “a real problem” and compliance with a model. Removing impediments may be seen as the main task of the Scrum Master, but how do we ensure that we attack the most important ones? How do we avoid sub-optimization? What kind of fact should we collect to understand the severity of the problem?

Agile has shown that doing prolonged analysis upfront bears little to no value to the customer. However, doing none means the project lacks the direction that it needs. The question is, how much analysis is enough before the project starts?

Often times, the inception activities can set a project up for success or failure. In this 3-hour workshop, we aim to give an introduction of how an intensive, focused series of activities can kickstart a project. Led by a Business Analyst and a Developer, the participants will simulate a short inception that shapes a project from concept to delivery.

Automated testing is a corner stone practice for teams practising XP yet there are multiple levels of automated testing to understand. Combined with effective Continuous Integration, automated testing offers rich level of feedback, assuming you structure them in the right way. Participants will better understand the tradeoffs you need to consider when looking at different levels of automated tests and participants will then attempt to structure them in a way to maximise the speed and quality of feedback.

The integration of usability engineering and agile software development practices is an emerging challenge. Both the agile and the HCI community have recognized the need to incorporate efficient usability practices in this domain. However it is not an easy problem to address. Two complementary paths could be marked out to achieve this goal: search strategies for the incorporation of usability and HCI techniques and activities into an agile software development process; and exploring approaches for incorporating usability heuristics that are helpful for building usable software.

Yaser Ghanam,Frank Maurer,Kendra Cooper

So you deliver perfect code with no technical debt, on time and budget using Agile methods. Yet you remain unconvinced, and the resulting system is no success with users. But why? You even had an interaction designer onboard and “great UX” was part of the requirements list.

Our experienced facilitators will use examples of project failures to show how agile can mess up the best attempts at creating great experiences. Together we’ll discover why that keeps happening and what needs to be done to fix it so that your project can deliver a great experience and real business value that matters.

Most Coding Dojos follow 2 main formats: Kata and Randori. Both formats try to give as much information as possible to the audience by evolving solutions from scratch. This is great when dealing from Novice to Competent level but tends to get slightly less interesting to people at a higher level. The Kake format goes beyond competent by adding an extra challenge. It increases dynamics by putting people into a more “real” world exercise. Participants deal with unknown code bases and have to evolve from them. This clinic will present the format and initiate a real session with the attendees.