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, TDD, 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.

Many agile coaches just focus on the agile practices and skills. That's the simple part in our opinion. A good agile coach needs to be more than knowledgable in agile, but also needs competences from team coaching and personal coaching. This tutorial is about coaching skills and aimed at participants that either want or need to coach agile teams. We'll address several topics, but the focus is on how to be an excellent coach. The tutorial will be very interactive and certainly not a lean back experience.

Over the past decades we developed a very broad picture of the testing profession. In the past decade this picture has been shaken by the emergence of Agile software development processes.

On the first German Agile Testing and Exploratory Testing Workshop (GATE) in October 2011 the participants started with a definition of what Agile Testing could be. One of the biggest insights was that the practices that help a tester on an Agile team also work well for a more traditional tester.

In this workshop the participants will work out their own definition of Agile Testing. By this discussion we will explore the differences between testing on an Agile project compared to a more traditional project. The participants will leave the workshop afterwards with at least three skills that help a tester on Agile as well as on a traditional project.

Waiting for a workshop or tutorial to begin? Have a little time on your hands? The Agile Cafe is the place to hang out. Create your own conversaton on an agile topic around a table or join a group that is already under way. Come and go as you please. Bring your own beverage. [ Link ]

Web applications are ubiquitous these days and aren't going away any time soon. More and more applications are becoming AJAX heavy and logic moving to the client side. Automated testing is important and TDD can help you design better javascript. In this tutorial you'll get hands on experience how.

The Symposium aims to bring together doctoral students working in the area of agile or lean methodologies, giving them a unique opportunity to interact with renowned and experienced researchers in the field, and discuss with them about their current and proposed research. Software engineering works that are related to agile or lean are also welcome. The Doctoral Symposium also aims at establishing a supportive worldwide community of doctoral students working on multimedia, and promoting social and intellectual interactions among students and researchers from academia, industry and government.

Many agile coaches just focus on the agile practices and skills. That's the simple part in our opinion. A good agile coach needs to be more than knowledgable in agile, but also needs competences from team coaching and personal coaching. This tutorial is about coaching skills and aimed at participants that either want or need to coach agile teams. We'll address several topics, but the focus is on how to be an excellent coach. The tutorial will be very interactive and certainly not a lean back experience.

Once considered as an approach limited to small, co-located teams, agile development has evolved to a culture embraced by large, distributed organizations. Our goal is to move beyond agile teams to foster an agile organization. The transition to “agile” may be initiated within legacy-driven organizations by grassroots teams trialing agile approaches and evolve to sanctioned pilot projects. In some cases the adoption of agile may be accelerated by the acquisition of an agile company. Cultural shock and reformation may ensue when agile teams begin integration with the behemoth that is represented by the legacy-driven organization. Through a mixture of challenges and successes best practices can evolve. This workshop and the subsequent panel discussion will explore essential ingredients for success.

Waiting for a workshop or tutorial to begin? Have a little time on your hands? The Agile Cafe is the place to hang out. Create your own conversaton on an agile topic around a table or join a group that is already under way. Come and go as you please. Bring your own beverage. [ Link ]

Keeping your codebase Clean is the key to affordable long term software maintenance, but many teams struggle to prioritize good design in the face of changing requirements and looming deadlines. Everyone wants shorter lead times, increased productivity and better quality software, and this is achievable if programmers can change their minute-by-minute habits and decisions, and begin to use more effective practices.

This half day “Clean Code” seminar can help you put matters into perspective and inspire you to improve your practices and codebase

The Symposium aims to bring together doctoral students working in the area of agile or lean methodologies, giving them a unique opportunity to interact with renowned and experienced researchers in the field, and discuss with them about their current and proposed research. Software engineering works that are related to agile or lean are also welcome. The Doctoral Symposium also aims at establishing a supportive worldwide community of doctoral students working on multimedia, and promoting social and intellectual interactions among students and researchers from academia, industry and government.

Welcome and opening of the XP2012 conference

Welcome to Open Space at XP2012! Open Space’s self-directed learning environment will help you integrate and extend the information and experiences you gain during the rest of XP2012. Open Space provides an opportunity to meet in self-organizing groups to share your latest ideas, challenges, questions, hopes, experiences and experiments. The Open Space format gives just enough structure to foster collaboration and the content is determined by those who choose to participate. Make this conference your own. Attend attending the opening on Tuesday morning, offer your ideas about important topics to explore, and attend sessions Tuesday, Wednesday and Thursday.

During this opening session, I'll give a brief (15 minute) explanation of how Open Space works. Then, everyone will be invited to announce the sessions they are willing to host. Take note of the sessions you want to attend. As you listen, you may be inspired to present a session yourself. There are no deadlines or time limits: simply step up and describe your idea for a session as we create the schedule for a conference-within-the-conference right on the wall!

Every agile approach takes place within a given context - the corporation. Agile product or project development, especially within large corporation are facing here specific challenges provided by the larger framework. The common departmental structure is often experienced more like a burden than support. As well the organization's structure (yes, and of course as well its culture) can be experiences as being more or less helpful. Yet still, in order to become successful the agile undertaking has to deal with these challenges.

In this session, I want to explore how departments like Human Resources, Legal, Marketing, Sales, yet as well Quality Control, or Operations can support and how can they hinder agility. Despite the challenges, the focus is on leveraging the departments in order to become successful. Thus, involving everyone who is affected early on and making them part of the agile approach is crucial. This session is based on my experiences working in large and distributed corporations, yet the variety of the participants' experience will make all the difference.

We have been running coding dojos at Nokia Berlin for almost a year now. During this time we have used them as a tool to:

• Share opinions on what we consider good code
• Cross pollinate ideas and approaches between teams at Nokia
• Experiment with new (at least for our team) languages (Scala, JavaScript) and tools (Jasmine)
• Have (even more) fun at work

In this session we will cover

• What a coding dojo is and how we do it at Nokia
• Why coding dojo is important and needed
• What have we tried at Nokia so far
• How to organize one: ideas to try, what makes a successful dojo and what to avoid when organizing a dojo

The target audience for this presentation includes developers unfamiliar with the coding dojo concept, anyone interested in organizing a dojo and those interested to hear about the dojos that we have been running for a year now.

There seem to be one big question in the Agile community these days: “How to change people?” or “How to make people unlearn what they learnt?”. Well, for the past year together with two other guys, we've given some of our time to talk with students, and do some Agile stuff with them. Lectures, interactive workshops, pair programmingsessions, etc… I'd like to tell you our story, the things we did, those that worked those that didn't, but I'll also suggest different things you could do in your local communities to help universities be more Agile. Because if one problem of Agile coaches is to change the way people think or learnt to think, maybe we should just open students minds before they get corrupted. That might not dissolve the problem but would probably contribute toit don't you think?

If you care about Agile, and want to help creating a more Agile generation for the next 10 years, come and share your thoughts and experiences.

This panel will discuss issues related to agile contracting – including approaches to product specification, evaluation, and acceptance testing – contrasting with established contracting practices such as “fixed price” and “time and material”. Panelists – including agile practitioners and legal experts employed in a software milieu – will share their experiences and expose barriers to success.

Everybody agrees these days that communication is one of the key success factors in any project, regardless of their size and complexity. During the agile adoption process, many teams and managers are blind to communication issues and believe everything is working just fine. However, experience suggests that communication is failing at many levels: managers don't really understand their developers, testers and other geeks, who on the other hand often fail to effectively sell their point back to management. The fact is that speaking the same language doesn't guarantee the understanding of each other's points. This highly-interactive talk shows typical communication patterns, behaviors and provides eye-opening insights into the ways communication can be improved.

People, particularly people in groups, often act in ways we couldn’t predict and don’t understand. Human systems, like teams and organizations, display the most complex dynamics of all complex adaptive systems. In this interactive session, Diana Larsen will introduce models and methods from the Human Systems Dynamics Institute that leaders like you can use to gain a deeper understanding of the dynamics in your own teams and organizations and choose next steps to influence them toward true greatness.

What is geek feminism? Why should you care? This lightning talk outlines some experiences I've had that made me wonder, and caused me to care. My hope is to improve the situation for women in our industry by raising some issues and offering ideas.

Ever since software engineering was born, over 40 years ago, hundreds of “fundamental principles” for software engineering have been proposed. It is hard to believe that such a young discipline—in fact, any discipline—would rest on such a large number of “fundamental” principles. A few years ago, Séguin and Abran indeed showed, through a detailed analysis of the various principles proposed in the software engineering literature during the 1970–2003 period, that many—in fact most!—of the statements proposed as “fundamental principles” could not be considered as software engineering principles. The analysis method proposed by Séguin and Abran provides, among other things, a rigorous definition of term principle along with a set of criteria allowing to verify whether or not a statement is a software engineering principle. In this paper, we apply this method to the agile principles. More specifically, we examine the principles proposed by the Agile Manifesto as well as those from three well-known agile methods: XP, Scrum, and DSDM. Our analysis results show that many of the statements proposed as agile principles are in fact also software engineering principles.

Agile methodologies are often not used “out of the box” by practitioners, instead they select the practices that fit their needs best. However, little is known which agile practices the practitioners choose. This study investigates agile practice adoption by asking practitioners which practices they are using on project and organizational level. We investigated how commonly used individual agile practices are, combinations of practices and their frequency of usage, as well as the degree of compliance to agile methodologies (Scrum and XP), and as how successful practitioners perceive the adoption. The research method used is survey. The survey has been sent to over 600 respondents, and has been posted on LinkedIn, Yahoo, and Google groups. In total 109 answers have been received. Practitioners can use the knowledge of the commonality of individual practices and combinations of practices as support in focusing future research efforts, and as decision support in selecting agile practices.

The paper presents a method to manage critical interactions to manage when introducing agile software development in mass-produced embedded systems. The method consists of a context model together with a set of measures, and is validated by empirical evidence from three cases. From an industrial perspective, the paper provides a prescription on how to implement agile software development outside the typical domains for agile, in this case for mass-produced products with embedded software governed by a stage-gate process for mechanics and hardware. From a research perspective, the paper provides an analysis of the software development cycle for products with embedded software, especially where product development as a whole is driven by a plan-driven process. The main contribution is a method for introducing agile in areas where by necessity the full R&D process cannot be agile.

Old habits are hard to change. This also stands true when adopting TDD practices. One of the main reasons for TDD relatively slowpenetration is the so called need to first make the production codes fit specific design patterns, or in other words design the code for testability.However, in today’s world of testing tools, there is no true need for these changes to occur. Isolation frameworks have grown beyond the needto refit the code to their needs and are able to isolate any part of any given design. A major part of the community is advocating that these kinds of design changes are beneficial, while this may hold true, it is not relevant to any real testability issues. If these design patterns makes a better design, please take it up with the design “department”. Don’t make a testing issue out of it. Presenting redesign as a prerequisite for TDD, add another significant barrier for most companies out there. This talk will demonstrate how one barrier on your way to happy TDDing can be removed using the proper tooling, and prove once and for all that Design for Testability is not much more than a fraud.

Agile models are more effective than traditional models because they key is that they don't have to be complete but just good enough to move on. In traditional software development the modeling phase is time consuming and implies formalisms like UML that represent one of the anti-agile patterns. A key point of agile modeling is to create a model with pairs and when possible to create more than one model in parallel; a model has to be understandable as much as possible from all the stakeholders involved in the project.

A simple and direct communication is the key to make the modeling phase understandable for the end customer and valuable for the team. During this session you will learn how to address this goal and, even more important, you will see how create a model open to changes and able to evolve duringthe software development cycle.

In order to address these points you don't need a specific tool but there are several tools that can help like index cards, crc cards, post it, shared dashboard, pseudocode tools, etc. The open source market offers several tools to help to discuss models also without sitting in the same room, between these we'll take a look to crcpro, agilo, envision-apdt, icescrum, etc.

ABSTRACT

Do you hope that one day all the office politics will be replaced by a common and worthwhile cause? Do you wish you could be partof a winning team? Do you dream of working in a place where you belong? Every organisation is made up of tribes, naturally occurring groups of between 20 – 150 people. And even though each tribe is different they have one thing in common: organisational culture. Join us to learn about Tribal Leadership, a practical model for leveraging natural groups to create organisations that thrive. Learn how you can help transform your work experience into what you want it to be by focusing on language and behaviour within a culture. You’ll get the chance to identify the stage you and your tribe are in and the next stage you want to move towards. Working in pairs, triads and as a whole group, you’ll leave the session with a roadmap of your own to take your tribe towards “Innocent Wonderment”.

The Five Stages of Tribal Leadership:

• Stage 5 – Innocent Wonderment: “We’re great and so are they”
• Stage 4 – Tribal Pride: “We’re great they’re not”
• Stage 3 – Lone Warrior: “I’m great you’re not”
• Stage 2 – Apathetic Victim: “My life sucks”
• Stage 1 – Despairing Hostility: “Life sucks”

Come for a surprising talk about... who knows?

Experience report about adopting agile principles on huge, conservative, and inflexible environment of hi-performing apps - on mainframes. Working for critical bank and insurance projects, supporting airport infrastructures, security governmental processes, the mainframes are the core back-bone part of the infrastructure of many Fortune 500 companies. Such constellation itself brings unique challenges and not only the technical ones. Can you for example imagine bringing such customer into the team, letting them interfere with the final product? And that’s not the only challenge. You are facing tuns of old legacy code, working with huge amount of data which comes with testing challenges along. Last but not least,there is only a limited set of tools at hand.

Mainframe development has never been easy, universities do not teach about mainframe as a platform and using languages such as assembler and COBOL aligned with a year long release cycles do not support agility out of the box. We would argue though that such conservative environment is an idealplace to implement agile practices and achieve an immediate impact on the quality, productivity, and flexibility. In addition, nowadays the mainframecompanies are facing a challenge of exchanging generations of developers so new processes and techniques are being introduced to this stringent environment just on time.

An "Elephant in the room" is an English metaphorical idiom for an obvious truth that is being ignored or goes unaddressed. The idiomatic expression also applies to an obvious problem or risk no one wants to discuss. What are some of the Elephants in the Agile Room?

Last year on the 10th anniversary of the penning of the Agile Manifesto, a group of Agile thought leaders met at the Lodge at Snowbird to celebrate and reflect on 10 years of Agility. During the morning of reflection, David Andersen noted that there was an elephant in the room that was not being discussed--notably the role of the Agile Alliance. There was some debate over whether this was really an elephant, and it got some people thinking about what some of the other elephants might be. While some of the group went off for an afternoon ski, a small group gathered and decided to go hunting for elephants. What emerged was a healthy list of potential elephants that deserve more attention in the agile community.

Team dynamics are patterns of interaction among team members that determine the performance of the team. Success of Agile software development depends on team interaction. Team interactions are, however, affected in distributed teams. Through a Grounded Theory study that involved 40 Agile practitioners from 24 different software companies in the USA, India, and Australia, we investigate the key concerns of distributed Agile teams. We found Agile teams depend significantly on team interaction, and adopt six strategies that promote effective team interaction in distributed software development.

One of the hallmarks of a co-located agile team is the simple and open flow of information between its members. In a co-located setting, peripheral awareness, osmotic communication and simple information radiators support agile principles such as collective ownership, minimal documentation and simple design, and facilitate smooth collaboration. However in a dispersed agile team, where individual team members are distributed across several sites, these mechanisms are not available and information sharing has to be more explicit. Research into distributed software development has been tackling similar issues, but little work has been reported into dispersed agile teams. This paper reports on a field study of one successful partially dispersed agile team. Using a distributed cognition analysis which focuses on information propagation and transformation within the team we investigate how the team collaborates and compare our findings with those from co-located teams.

Agile/Lean software development teams are by definition striving for high performance. However, it is not straightforward to recognize and cultivate those high-performing teams. Sometimes the team members perceive their internal performance differently than their externally observed outcomes really are. This paper addresses those issues by proposing an instrument for self- monitoring and analyzing software development team performance. The key goal is that practicing teams can use it even on a daily basis to indicate and steer their own performance excellence. This is supported by certain principal performance analysis guidelines. A prototype implementation of the instrument is demonstrated with some empirical cases. The cases indicate that the instrument can indicate noticeable differences in the perceived performance of individual team members and the team external outcomes. It helps detecting potential performance problems and impediments as well as improving even high- performers, and explaining team performance differences.

The way developers and testers approach automated testing is qualitatively different in agile teams, and many struggle with practices like TDD and automated functional testing. In this panel discussion, four industry thought leaders discuss their experiences around testing, as teams transition to new and more effective ways of working. Many teams struggle to write useful automated tests, and it can happen that test suites become so slow and broken that they are just thrown out. This panel discussion aims to draw out what successful teams are doing, and some ideas about how test automation can provide useful feedback to the team in a timely manner.

We'll be discussing questions like:

• What's the best way to teach a team TDD?
• How should you get started with automated functional/system testing?
• Do testers need to learn coding skills before they can be useful in an agile team?
• Do you need to write your own system-specific testing framework for functional tests?
• Which functional testing frameworks have you seen working well?
• Should you use "stateist" or "mockist" TDD?
• Is it possible to consistently deliver working code every sprint or do you eventually need a "testing" or "transition" sprint before final deployment?

We hope for active involvement of the audience, and after an initial period with the four invited panelists, we will invite audience members to step up and join the discussion via a "park bench" or "fishbowl" format.

State-of-the-art agile practices come with a heavy emphasis on process. But do they really work, do they make us truly agile where responses to change are quick and effortless? In many cases the bottleneck is the architecture, design and general quality of the code base. What is the relationship between design and agility? What are the business consequences of an agile code base? And how do we know if we are moving in the right direction? In this workshop we will pose some provocative questions, propose a few possible approaches and together discuss how they measure up to real world experience.

ABSTRACT

Just for fun, conference delegates are welcome to gather for an early morning 5km run along the seafront. The route should be easy to follow, and we aim to record the times taken by participants.

Enjoy a refreshingly brisk start to the day, and the extra adrenalin that comes with racing against your peers.

Design Thinking isn't new. But of course it's story continues to evolve. Sally will start by exploring the IDEO notion of Design Thinking, where its come from in it's days of designing great products, through some thoughts on current service design and working with start-ups. She will then focus on how Design Thinking is being used to transform organisations themselves into becoming more agile and innovative in their internal cultures and ways of operating. Through sharing a couple of case studies, she'll talk about the role a clear purpose plays (the Why), innovation strategies and processes (the What) and finally, designing triggers for organisational change (the How).

You work for a Big Company. You want to do Agile, and you want to do it well. Good luck to you! Big companies are different. They're still using windows XP. They don't wanna know about XP. This session is about HOW TO sell Agile to a Big Company, when you work inside that big company. It's not about commercial selling. We'll cover the financial reasons - because no business will buy an idea unless it makes them more money. We'll cover the personal reasons - because if it doesn't make people happier in their work, it'll never stick. We'll cover the blatant tactics. We'll cover the subtle tactics.

Clarke “sells Agile”, quite well, inside General Electric, one of the world's biggest software-development companies. He will present a few proven (but not well known) influence models combined with his own personal experiences.

The Innova Method is an iterative and structured approach for repeatable innovation introduced in the IP and Broadband Development Unit of Ericsson. The method is based on behaviors including empathizing with people, radical collaboration, quick and iterative experimentation.

Usability is a critical quality factor. Therefore, like traditional software teams, agile teams have to address usability to properly catch their users experience. There exists an interesting debate in the agile and usability communities about how to achieve this integration. Our aim is to contribute to this debate by discussing the incorporation of particular usability recommendations into user stories, one of the most popular artifacts for communicating agile requirements. In this paper, we explore the implications of usability for both the structure of and the process for defining user stories. We discuss what changes the incorporation of particular usability issues may introduce in a user story. Although our findings require more empirical validation, we think that they are a good starting point for further research on this line.

Retrospective analysis of agile projects can support identification of issues through team reflection and may enable learning and process improvements. Basing retrospectives primarily on experiences poses a risk of memory bias as people may remember events differently, which can lead to incorrect conclusions. This bias is enhanced in project retrospectives which cover a longer period compared to iteration retrospectives. To support teams in recalling accurate and joint views of projects, we propose using an evidence-based timeline with historical data as input to project retrospectives. The proposed method was developed together with a large software development company in the telecommunications domain. This paper outlines a method for visualizing an evidence-based project timeline by illustrating aspects such as business priority, iterations and test activities. Our method complements an experience-based approach by providing objective data as a starting point for reflection and aims to support objective analysis of issues and root causes.

Many studies and industrial reports have demonstrated the tendency towards the increasing number of organizations, interested in agile software development. With the transition from intentions to actions, the question that naturally arises is how the deployment process should be approached. In this paper we argue that shared organizational values, which we call organizational Superego, should be the main drivers for the deployment and post-deployment assessment of agile methods and techniques. Along with that we propose a new organizational classification technique, which assesses the power of the Superego to shape organizational behavior, together with an organizational value framework to be used for strengthening it. We further discuss how a strong Superego would approach the deployment of agile methods and techniques, and outline a future agile deployment framework, based on organizational values.

Agile software development methods are harder to adopt by third-party software developers than by in-house software development teams, since traditional contractual frameworks can easily lead to unfair risk distributions between client and supplier when applied to agile projects. We therefore present a pricing model for agile software projects that distributes risks evenly between the partners, and encourages efficient, high-quality contributions on both sides.

Not a new idea, but a classic: show how a well-known architecture style can emerge from focusing on removing duplication first, then improving names afterward. If you want to show your skeptical colleagues the potential of TDD, this kata could definitely help, and I relish the opportunity to do it as a Tech Demo with a surprise partner.

User stories are used to describe the functionality delivered in a product or system. Planning Poker is a common technique for sizing user stories, however it has challenges. It can be time consuming and teams can get bogged down in unnecessary discussion. This session describes a technique called Silent Grouping that can be used to complement Planning Poker, explaining how to apply it so that large sets of user stories can be sized in minutes. Silent Grouping has several advantages. It is fast, which in turn leads to significant time and cost savings. It also has more subtle benefits. The technique has been used with large teams to size hundreds of user stories in minutes for Release Planning sessions. This talk demonstrate the technique and show you how to apply it in your teams.

Don’t become another failed Agile adoption statistic. Do you know the most common reasons organizations fail to adopt Agile successfully? During this interactive session you’ll learn about the most costly mistakes made by many organizations during Agile adoption.At the end of this session, we’ll explore the techniques to avoid these deadly mistakes to make your Agile adoption journey smoother.

During this session we’ll discuss

• What are the biggest mistakes made in enterprise Agile adoption? Common enterprise Agile adoption anti-patterns and how to avoid the pitfalls.
• How do companies stifle Agility by planning and running projects in counterproductive ways? Common project and programme setup anti-patterns and how to avoid the pitfalls.
• How and why do teams fail to embrace Agility? Common Agileteams anti-patterns and how to avoid the pitfalls.
• How do Product Owners fail to play their crucial part in making Agile a success? What are some of the Product Owner anti-patterns?
• How some of the Scrum Masters constrain Agility instead of becoming agents of change? What are common Scrum Master ant-patterns and how to avoid these.

Change is complicated. Most organisational change initiatives involve not only newer practices and processes, but a shift in the company's culture. This is particularly the case when introducing agile and lean methodologies for software development. Some of the common approaches to organisational change are training and coaching, with the promise of bringing external knowledge to a company, so that its employees can apply new skills to their work environment. While these approaches certainly have value, we believe that alone they do not bring about sustainable change in an organisations behaviour. This presentation will introduce a hands on approach to learning that not only introduces new practices but has a strong focus on providing sustainable change in the way people work. Originally designed as an internal training program for ThoughtWorks, this model has been running for more than one year with much success at introducing new employees to the culture and practices used within the company. The focus of this approach is to expose participants to real problems. Participants are taught theory and practices which are then applied and reflected upon in a real project. This model, like training, can be effective at providing people with the knowledge they need, however it allows them the opportunity to apply that knowledge to their own work challenges, within their own working environment, over an extended period of time. We're aiming this presentation at managers, trainers, coaches and anyone who is interested in implementing change. We'll introduce you to the model and also share our ideas in how you can apply it for organisational change and learning.

Product Development can be viewed as a Complex Adaptive System. Different people, groups, organizations and systems collaborate in a complex network of relationships and dependencies to produce something of value - generally a product or service. Identifying waste in this value network is a critical step towards creating a truly lean and agile organization. This session will (1) show how to apply exercises that identify waste, (2) provide a framework for managing waste, and (3) provide some concrete strategies and practices for eliminating waste in your organization.

How to create a vivid and attractive product vision in3 hours! One way to do it is to sit down in quiet loneliless and dream up the product vision. A better way is to walk a team through a series of steps that creates a solid background for understanding, envisioning and strategizing the product. This talk describes a workshop, originally developed and used at a large danish insurance company, that in a big push moved the whole IT-organization towards agile development. A part of this transition was to guide newly appointed Product Owners through a visioning process.

This lighting talk aims to explore, from an holistic point of view as opposed to the reductionist thinking, how the Lean Agile methodologies can be considered as part of the “turning point” in the crisis of Western reductionist way of thinking. Recent scientific discoveries indicate that all life – from the most primitive cells, up to human societies, corporations and nation-states, even the global economy – is organized along the same basic patterns and principles: those of the network. Both (Lean & Agile) offer a thinking tool set that allow us to create new models and different approaches. Hence, in this lighting talk I would like to affirm how tightly humans are connected with the fabric of life and make it clear that it is imperative to organize our world according to a different set of values and beliefs.

I have never been in a project with stable velocity. I find it really hard to measure the impact of changes in process. I find myself cringing everytime anyone compares programming to a car factory. I don't think I am alone. With the help of Medium Number Systems and the Cynefin Framework I will show why a complex and-non deterministic process cannot use the same feedback process as a deterministic one.

In larger development efforts, business analysis, architecture and other activities, traditionally performed in “early phases”, still seems important. And there is much confusion about how they relate to agile, team based, incremental development. Based on a real world experiences this talk discusses a strategy to work with multiple, long and short running, preparatory tasks to create “Ready for development” stories and taking care of the feedback continuously.

Changing a habit or trying something new? Struggling to make it stick? Let me illustrate a deceptively simple concept - the best things always are - that gets results @play, @home and @work. This talk will help you change your life and help you to inspire others. I promise.

When Agile is introduced in an organization it often means that focus is put on the development teams. The development teams are coached to self-organize, improve continuously and work closely with their product owner. Often this leaves the managers confused and frustrated as they are left with the same responsibilities but are expected to exert a lot less authority and influence on their employees. In this lightning talk I will show how I try to create an environment where both managers and employees become empowered.

Once considered as an approach limited to small, co-located teams, agile development has evolved to a culture embraced by large, distributed organizations. The goal is to move beyond agile teams to foster an agile organization. The transition to “agile” may be initiated within legacy-driven organizations - by grassroots teams trialing agile approaches - and evolve to sanctioned pilot projects. In some cases the adoption of agile may be accelerated by the acquisition of an agile company. Cultural shock and reformation may ensue when agile teams begin integration with the behemoth that is represented by the legacy-driven organization. Through a mixture of challenges and successes - best practices evolve. This panel will explore essential ingredients for a success transition – “a shock to the system”.

Note: Additional panelists will be selected from participants in the "Shock to the System" workshop, held on Monday.

There is no agreement in the community about when to deal with usability and UX during the agile process. Two possible alternatives come out, a proactive vs. a reactive approach. In the proactive approach product owner, developers and usability experts, if any, discuss which usability practices should be interesting either at the beginning of the agile process or the iterations, while a reactive approach might wait for the corresponding usability needs to emerge from the user and would be considered in future iterations. This session's aim is to discuss about the pros and cons of these aproximations as well as other that could combine both alternatives.

ABSTRACT

The business unit 'Support solutions' within Ericsson has been implementing agile and as a part of this continuous integration since 2007. When implementing continuous integration in the smaller products (~20-50 developers/product) this was a challenge that could be managed with iterative investments during 1-2 years. For example, in the first product I was part of implementing this is in, we after 6 months improvement work knew within minutes if we had broken any legacy and were able to deliver working software every day.

But when scaling this to larger products, things started getting more complicated. What do you do when it's not enough to add more servers to speed up the build loops? How do you implement continuous integration in a product where you have huge amounts of legacy code and legacy tests that needs to be maintained for a very large installed customer base? This at the same time as having a constant market pressure to not decrease the throughput while investing in such improvements. This talk will present results and experiences from the implementations described above. This includes describing how the test execution time was brought down, e.g. by restructuring test suites and implementing cloud-based build environments. The presentation will also include ongoing work to shorten the feedback loops even further through test avoidance, i.e. by applying test selection algorithms that dynamically determines which test cases that need to be re-executed after each code change. Finally, the presentation will touch upon how the concept of "continuous delivery" can be applied in a large-scale environment, e.g. the largest of the products mentioned above provide the latest version of the software to the market once every 6 weeks.

Large companies like Ericsson increasingly often adopt the principles of Agile and Lean software development and develop large software products in iterative manner – in order to quickly respond to customer needs. In this paper we present the main indicator which is sufficient for a mature software development organization in order to predict the time in weeks to release the product. In our research project we collaborated closely with a large Agile+Lean software development project at Ericsson in Sweden. This large and mature software development project and organization has found this main indicator – release readiness – to be so important that it was used as a key performance indicator and is used in controlling the development of the product and improving organizational performance. The indicator was developed and validated in an action research project at one of the units of Ericsson AB in Sweden in one of its largest projects.

Software maintenance is a key activity in software development requiring considerable effort and time. Hence, it is important to increase the efficiency and effectiveness of the maintenance process. The objective of this article is to introduce a palette of indicators to assess the maintenance process based on indicators lean indicators. Four indicators aiming at detecting waste have been proposed, namely the inflow of maintenance requests, the flow of maintenance requests through the maintenance process with regard to continuous value creation and high throughput, the analysis of lead-times, and the analysis of workload. The research method is case study in which the proposed indicators were applied on the maintenance process of one case company (Ericsson AB).

We present the application of software process modeling and simulation using an agent-based approach to a real case study of software maintenance. The original process used PSP/TSP; it spent a large amount of time estimating in advance maintenance requests, and needed to be greatly improved. To this purpose, a Kanban system was successfully implemented, that demonstrated to be able to substantially improve the process without giving up PSP/TSP. We customized the simulator and, using input data with the same characteristics of the real ones, we were able to obtain results very similar to that of the processes of the case study, in particular of the original process. We also simulated, using the same input data, the possible application of the Scrum process to the same data, showing results comparable to the Kanban process.

When an organization makes a real effort to be Agile, they set in motion a series of changes that ripple throughout the entire organization. The side-effects are often surprising, and dealing with them can be challenging.

At the Agile Alliance's “Supporting Agile Adoption” workshop in December 2011, Jutta Eckstein, Diana Larsen, and James Shore tackled this problem with a new change model targeted at Agile transformations. The model gives change leaders a tool for understanding the context of their transformation, for choosing which changes to focus on, and deciding whether to take a deterministic or adaptive approach to each one.

The change model is new and experimental. In this workshop, Diana and Jutta will present the model, invite you to apply it to your situation, and use your feedback to further improve the model.

Have you and your team ever been in a state that would best be described as ‘teamwork flow’? Everything just works, things you have only dreamed of comes out of your collaboration and it is the coolest thing you have ever experienced. Then again, there were also these other situations where it just felt awkward, nothing worked and it felt like you were working solo but sat together. Much like trying to work on public transportation. Noisy, unpredictable and quite a bumpy ride.

During the course of a day, or a whole project many tasks needs completion and how you interact with others have a big effect on both the result and on how you get there. Some people pair up on difficult tasks, some prefer to prototype alone to validate something while others have conversations. In short, different situations call for different modes of interaction as well as different types of activities. By being able to quickly switch between the different modes, a team as a whole will become much more effective.

We will present a simple model over these modes of action and interaction. To switch modes effectively we use what we call gestures and responses as positive catalysts. During the session, which will be highly practical, you will practice using such gestures and responses.

Does this sound weird? Bring a laptop and maybe a friend, there will be pair coding/developing!

• Why do we separate development from maintenance and operations?
• Why do system architects chose frameworks and write UML diagrams but do not write any code?
• Why do we measure how many lines of code a developer writes?

"Good girl" syndrome makes people take all feedback as personal. Negative feedback becomes devastating for our self esteem, and we try our best to avoid it. How does this affect an organization where learning is key? We know that learning requires a fair amount of failing. So how much failure can we stand?

In order to create a true learning organization we need to get rid of the good girl syndrome! In this talk we mix theory with experience to explore some techniques that will help us separate feedback on results and on behaviour.

Find a description of Agile development that doesn’t mention the “waterfall” nature of the the software development lifecycle. It’s hard to do. Our community presents business organizations with the choice between adopting (and hopefully adapting) a set of rules for joining the world of Agile development on the one hand and remaining with the traditional *waterfall* approach on the other. Studies show that traditional project managers are increasingly receptive to reducing the “waterfall” with concepts borrowed from Agile, in fact you can totally remove the waterfall and not be agile. This lightning talk is a challenge to pinpoint the real change that Agile must bring.

Sign up to give a lightning talk - first come first served!

Sign up to give a lightning talk - first come first served!

Research partnerships between academia and industry are grown through relationships, a mutual desire for innovation, and needs for funding. Challenges include matching industry sponsors with university research programs and setting expectation for research outcomes (publications, intellectual property - e.g. tools/processes, mentoring students and fostering academic excellence). The intent of the panel is to share perspectives from industry and academia to outline synergies and gaps.

Would you like to do pair programming with someone you don’t know yet? Are you interested in improving your skills and learning something new? Do you want to experience a coding dojo? Attend this hands-on session!

We will start by picking a goal for this dojo. That might be practicing TDD or learning Erlang (we will decide as a group). Then we will spend about 40 minutes coding. We will focus on practicing whatever we have chosen as our goal. We will follow the Randori dojo format.

We will spent last 10 minutes reflecting on our session. What have we learned? Did the format work well? What should we try next time?

Many Swedes that started with agile had the TV-show “What’s in your fridge?” (“Här är ditt kylskåp”) as a metaphor(!) for how to innovate and to deliver a great product on time, in a very small timebox, utilizing whatever is available adding generous amount of engineering skill, insightfulness and creativity to make it on time every time.

The early 1990s TV-show starred Jan Boris-Möller, an electrical engineer turned chef, who showed up at the home of a person of some public recognition. The celebrity had been told that they would get interviewed by a TV-host. They did not know that at the same time Jan would go through their fridge and cupboards to create, in their very own kitchen with whatever was available, an original three course meal in just a few hours. Jan basically just showed up with some sharp knives and did everything on the spot, delivering every time in front of running TV cameras.

We are very proud to have an agile inspiration to so many of us early Agile/XP-ers in Sweden, Jan Boris-Möller, creating our conference dinner. Jan will also give a talk during the day about how Agile Development compares to what happens in a great kitchen.

Agile development approaches are increasingly being followed and favored by the industry. Test Driven Development (TDD) is a key agile practice and recent research results suggest that the successful adoption of TDD depends on different limiting factors, one of them being insufficient developer testing skills. The goal of this paper is to investigate if developers who are educated on general testing knowledge will be able to utilize TDD more effectively. We conducted a controlled experiment with master students during the course on Software Verification & Validation (V&V) where source code and test cases created by each participant during the labs as well as their answers on a survey questionnaire were collected and analyzed. Descriptive statistics indicate improvements in statement coverage. However, no statistically significant differences could be established between the pre- and post-course groups of students. By qualitative analysis of students’ tests, we noticed a lack of test cases for non-stated requirements (“negative” tests) resulting in a non-detection of bugs. Students did show preference towards TDD in surveys. Although further research is required to fully establish this, we believe that identifying specific testing knowledge which is complementary to the testing skills of a new TDD developer would enable developers to perform their tasks in a more efficient manner.

Escalating commitment is a common and costly phenomenon in software projects in which decision-makers continue to invest resources to a failing course of action. We conducted a longitudinal case study exploring the effect of daily meetings on escalating commitment. This was done in an agile project building software for the oil and gas industry. By analyzing data collected over a period of four years, and drawing on concepts from self-justification theory we found that daily meetings contributed to maintain a situation of escalating commitment. This especially occurs if the meeting becomes a place for reporting and defending decisions with team members feeling that they have to justify their choices towards the project management or fellow team members. Early signs of escalation such as rationalizing continuation of a chosen course of action must therefore be taken seriously.

Lindahl is one of the largest corporate law firms in Sweden with a marked focus on advisory services to knowledge oriented, innovative and technology intensive companies. Attorney Lars Arrhed in the Gothenburg office has during the last years worked with direction towards new forms of cooperation for project management within both the contract area and the IT sector. Lars has drawn up and negotiated contracts for agile system development mainly for purchasing parties, not least as a part of specifications for public procurement of IT systems. Lars has also been counsel in disputes in which badly formulated conditions for agile projects has been the central problem. In light of these experiences, Lars will give us firm suggestions of how an agile system development contract should be formulated in order to work all the way and he will also highlight certain risks, common pitfalls and opportunities. With a background as a leader in the media sector, Lars will explain in an entertaining way the conditions for well functioning agile contracts using metaphors from the world of theater.

This is quick description and “live” application of Lean-StartUp principles and their beneficial outcomes for the 21st century enterprise and global sharing knowledge. I have given this talk a couple of times in France, and the current version reflects the audience's updates. It is an experiment of giving a talk using Lean-StartUp practices.

The agile transition effort at Cisco is both daunting and exciting. It has produced many successes, however the journey is not without challenges. Through a series of stories and examples this talk will focus on these challenges from four perspectives: enterprise, management, team and individual. We describe the types of challenges faced, with specific examples from each perspective. This talk offers insights into how we deal with these challenges, and also provides tangible examples from which others can learn.

At Siemens Healthcare syngo, we accomplished an agile transition with a big product development distributed to several countries. How we did that, and what we experienced throughout the first real agile project, what we gained there, which obstacles we had to overcome, where we are now and what we are still working on.

The migration process from Mainstream and Waterfall approaches to Agile Methodologies, at a broad and full company level, is a complex challenge that requires courage, dedication and ability to face difficulties and errors.

This short paper is the real story (hence the sub title: “Enterprise Challenges”) of my long experience as a CTO and Senior Manager, which has been committed and involved into spreading agile methodologies in Italy at Enterprise level (in particular by adopting Agile Modeling, eXtreme Programming, Scrum, Kanban and Lean Development methodologies), thus involving all levels of the company, starting from the organization structure and vision to the strategic operational details (eg: open source tools for project management and full life-cycle).

The first xUnit frameworks allowed us to write simple tests, which supplied all their own data internally. As time went on, many frameworks added parameterized (aka data-driven) tests, where the test arguments could be supplied externally. Theories, as implemented in JUnit and NUnit are the next evolutionary step, combining external data sourcing with internal validation of the data to select only those test cases that are relevant to what we are seeking to test. While parameterized tests are generally little more than a notational convenience, Theories amount to a new way of looking at tests.

This demo will start with a single test and then expand it to a set of parameterized test cases using several different approaches. Finally, we'll create several Theories that capture and extend the notions in the earlier tests. Examples will be shown in both Java/JUnit and C#/NUnit and will illustrate ways of using the Theory concept as a part of your toolkit.

The GUI is usually the most volatile part of an application, so if your automated tests rely on it, they are often fragile. The usual advice is therefore to prefer tests that use a more stable API just under the GUI layer. That is not always a useful approach - the application I’m testing at present has a very complex GUI, and it’s important that it works, as well as the code underneath. StoryText lets me test through the GUI, and has several features that allow me to manage the fact that the GUI is volatile.

In this demo, I’ll show how StoryText works on a simple GUI application, and explain how we’re using it to test an enterprise system for planning and optimizing airline crew rosters.

A test with StoryText has two parts. The first part is a description of what the user does: a series of action steps written in a domain-language. The second part is the “story” of what the GUI does in response - a plain-text version of what happens on the screen. You can sketch out both parts of the test before the UI even exists - for example when doing BDD or ATDD. The test is refined and made executable once the GUI is built - a little like adding “step definitions” in Cucumber or “fixtures” for Fitnesse. If you’re writing tests for an existing GUI - for example when retrofitting regression tests to an existing application - you can record both parts of the test directly in this domain language.

StoryText aims to tell the "story" of what happens in the GUI, by generating a plain-text description of (in broad strokes) how it looks and how it changes over time. You keep a "golden copy" of how the GUI should look, and if it changes, you may have found a regression bug, or just that the GUI has been improved in some visible way. It’s then easy to update the golden copies for many tests in bulk, or filter the output to ignore parts you don’t want to assert on.

StoryText was previously called "PyUseCase" is an open source tool, currently used to test applications written using SWT/Eclipse Rich Client Platform and Swing on the JVM, and PyGTK, Tkinter and wxPython for Python.

Configuration as code using devops tools like Puppet and Chef allows for a stable, predictable and automated server setup and configuration process. But just like any other code, it needs to be developed in a local safe environment.

This hands on demo shows how to run Chef recipes on local virtual Linux machines using Vagrant.

For agile researches it is often difficult to find statistically significant evidence for their hypotheses. Large scale coding contests with hundreds of participants provide an opportunity to observe the participants -– how they approach on solving the problem as well as their solution. These contests provide a lot of data points like various participants backgrounds, different experience levels, individuals and teams, etc. This workshop shall bring researchers and practitioners together to brainstorm possible experiments and how to set them up in the context of coding contests. The outcome shall be to increase the amount of usable data for empirical studies by using programming contests as experiments. We encourage agile researchers to present a case study or experience report of an experiment as well as practitioners and researchers without specific experience to participate at the workshop.

Some systems are simply too big, too monolithic to be delivered in small increments by small teams – right? You couldn’t upgrade an oil refinery’s controls incrementally, or redeploy a bank’s computing infrastructure in 2-week segments. Some endeavors are too risky and too inherently monolithic for that. So they say. This is the wilderness; the Everest that Agile hasn’t scaled, yet traditional development methods are failing here.

Early leaders in the Agile movement were careful to restrict their claims of improvements: “XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.”¹ But a lot has happened since 2000 and real teams are scaling those peaks – and keeping their methodology light-weight. We’ll hear first-hand about some of the most difficult challenges to Agile methods and how real companies are discovering that Agile works in places where we thought it shouldn’t.

¹ Kent Beck, Preface to “Extreme Programming Explained”, Addison Wesley, 2000

This workshop is a chance to learn about automated testing in the second quadrant, that is, business-facing tests that support the team. The workshop leaders will provide a sandbox environment with suitable testing tools, and an application to test. It is up to the participants to work out what to test, and how to write good, readable, maintainable tests in the tools they choose to work with.

You can use it as a chance to try out some tools you maybe havn’t seen before, and compare at least a couple of different ones. There’ll be a chance to discuss good test style and review other people’s efforts. There is no single “right” answer for whattests to write.

A crucial aspect of agile development is to work effectively in small teams. How do you organize a team to work effectively? The purpose of this workshop is to share and discuss experiencewith what fosters and hinders effective teamwork. The workshop will also give participants insight in a research-based model of team effectiveness, which can be applied in improving the practice of agile teams.

On many of our clients the estimation process proves to be both one of the most hyped and stressfull parts of project management and a complete waste of time and resources when it comes to actual customervalue. Still, the estimations are seen as something unevitable, even more important than improving performance or reducing time to market.

Trying to just quit the estimation process is usually not a good idea, as the Status Quo will react agressively. Instead, this talk will provide a real step-by-step guide used on our clients to reduce the stress on estimations and, paradoxically, provide better predictability and higher performance. The talk will include a practical excercise used on our training courses to teach both Agile planning and the nonsense of discussing estimations with the team.

To create a safe environment for people to challenge the status quo, we might need to pioneer new ideas while at the same time stay connected to the old ones. Guarding transitions like these, we are supposed to support people, as they lean on us. And while we are there, supporting them, we have to move and inspire them to keep on moving… We need tools and methods to support us in keeping our balance.

In this workshop Ivana and Bent together with you will look at perspectives of balance we need to sustain as change agents. In particular, we will dig into:

1. Teaching vs. Coaching
   Teaching and coaching are both valuable to support a team to improve. But it is the balance between these two - knowing when to coach and when to inject knowledge - that separates the great change agents from the good.
2. Validated Influencing - a term and concept Ivana coined during the preparation of this session.
   You will get an introduction to the concept of validating your influencing. In addition, we present a common language for the concept as well as inspiration to improve your skills as change agent by focusing on awareness and validation of your assumptions while influencing.

Prepare to validate your balance!

This presentation looks at the business of software development from an overall risk management perspective.

Two industries that extensively deal with risk are Investment Banking and Oil Exploration. As a seasoned veteran involved in developing software in these industries, Todd will introduce a number of theories, tools and practices surrounding risk and risk management. He will share practical experience using these techniques and approaches, explaining what works and what does not based on his experience and that of his colleagues.

Come for a surprising talk about... who knows?

Adopting agile when you have the enterprise backing and is always easier, however many finds themselves asking how to create an Agile context in their teams when the entire organization is not going to change. After all agile processes and values are alien to classical management concepts and on the surface they do not mesh well. Using an Agile process and mindset inside a waterfall organization ishard, but not impossible. In this session we will lay out the main challenges for adopting an agile in parts of an organization (maybe even a single team). We will discuss how this can affect the rest of the company and describe several possibilities in making such a combination work. The goal of this talk is to open up options for everyone to try out in his immediate surroundings, even when the rest will stay the same.

Everybody likes metaphors, especially when they help people understand complex things but even more when they do it in an unexpected way. This session compares an Agile process to a hamburger. Yes, a hamburger, a multi-layered hamburger where each layer has it's own properties andpurpose. If that burger is an agile process and I'm the company, what are the different ways I could “eat that burger”, how can I introduce agile in that company and how would all layers of that burger react to those different ways. This session will reveal one of the greatest secrets in the history of hamburger eating and will give you leads on what to avoid and what to do when you implement agile in your company. If you're a hamburger fan as I am, you'll love it.

It is easy to get energy and attention from the peopleinvolved when the agile process is a novelty. But, how maintain the team's ability to improve continuously four years into the project? The talk will present the key learning points on the subject on continuous improvement a team has gained from working together in more than four years.

Whether you've tried to launch a new organization wide program to change the way you deliver software to your customers, or just innocently suggested to your team mates that you should perhaps try a new tool or technique. You know that change is hard! Reactions might range from ignoring you to getting downright angry.I firmly believe that no matter how sound your idea is, you need to consider the mechanisms of change and resistance if you want a successful transformation. In this presentation I discuss change, the patterns that seems to be common to successful transformation efforts, and how you can use that knowledge to create real, sustainable change in your organization.

Most material you read or hear about agile testing is theoretical. Nothing wrong with that but I am missing hands-on stories of what testers do in actual projects. Having talked to colleagues about my time in several agile projects they agreed that they were missing this too. So I would like to give this talk to share my experience with the testing community. This talk is about the real life experience of being an agile tester in a scrum project.

Sign up to give a lightning talk - first come first served!

We’ll describe or play the best Agile learning games from the April, 2012 Boston Agile Games conference. Shorter games will be played in full. Attendees may participate or just observe. Longer games will be described (rather than played), and photos shown.

For each game presented, you’ll take away: Game name, and brief summary description Link to full details (if available) Insights the game provides Situations where the game should be used.

This is an excellent session for managers looking for a more effective way to inspire new behaviors. Agile practices only work when employees are willing participants, yet most organizations operate on a “command and control” model. Under time pressure, it’s so easy to “tell” rather than “inspire” new behaviors in your employees – get a first-hand look at a better way.

Test-Driven Development is the core of the XP technical practices. With TDD, programmers get instant feedback that their code does what they intend. Rumor has it that TDD cannot be used for developing C, let alone embedded C. The rumor is wrong! TDD can be used effectively for all forms of C. In this tutorial attendees get first-hand experience at TDD, writing well tested code in the challenging world of C. Attendees see how to break dependencies on the target execution environment enabling embedded code to be effectively test-driven. You will see how TDD helps to prevent many bugs and memory leaks from ever making the bug list. We'll use CppUTest, an open source test harness, is used to collect, organize and automate C++ unit tests.

Many of the challenges in embedded development stem from the target hardware bottleneck. The bottleneck slows progress of the embedded software due to non-existent or buggy hardware, and the inefficiencies of cross-platform development. The tutorial shows how to effectively use TDD and object oriented design techniques to overcome the target hardware bottleneck.

Bring your laptop or pair with one of the other attendees. We'll help you get ready at the tutorial, but it would be best if you did some setup before. Please register at www.renaissancesofteware.net using course code XP2012. You will find computer and setup instructions under Resources in Conference Attendee Extras.

Audience: This tutorial is designed for embedded software developers, technical leaders, software architects, firmware developers. They should attend to see how this valuable development practice is used to create high-quality embedded software at a predictable pace. If you program in C or C++, but not embedded, come anyway. No embedded experience necessary.

There’s a lot of material available on how to write and flesh out a user story - framing the story statement, what to include, how to write good acceptance criteria, etc. There is less written about how to carve out good, playable user stories from a complex feature or epic story in the first place. This workshop uses 3 case studies drawn from real projects to focus on this latter skill, and demonstrates how close collaboration between analysts, customers, developers, testers, and UX designers can result in user stories that help iteratively evolve features, reducedelivery risk, and support continuous delivery.

Using role-play, participants will try to 'solve' 3 case studies of increasing complexity, working in groups of 4 to 5. Each case study presents a different kind of application feature that needs to be broken down - one workflow-based, one involving data manipulation and reporting, and one an interaction-rich graphical visualization, allowing users to discover different approaches for and types of splitting dimensions to think about. Each case study will also feature a 'school solution' to provide additional insights to participants.

Waiting for a workshop or tutorial to begin? Have a little time on your hands? The Agile Cafe is the place to hang out. Create your own conversaton on an agile topic around a table or join a group that is already under way. Come and go as you please. Bring your own beverage. [ Link ]

The ability to rapidly respond to customer interest and to effectively prioritize development effort has been a long-standing challenge for mass-market software intensive products. In this session, we discuss these challenges; present a case study, Intuit’s Quickbooks productline that combined agile software development, design thinking and self-organizing teams in a successful approach; and discuss a generalized approachand implications from employing the techniques in your organization.

Eventually, a code base must change, but just steaming ahead making changes that break the code and then fixing errors often leads to creating more errors! It’s like a fight with the Software Hydra - for every scary head cut off, two more grow out! Instead, come to this workshop to learn The Mikado Method, a systematic approach to beat the Hydra and change your code in a safe way.

The method helps visualize, prepare and perform business-value-focused changes while delivering continuously, without having a broken code-base in the process. It enhances team communication, collaboration and learning, and helps individuals stay on track.

This is a BYOL (Bring Your Own Laptop) workshop with hands on coding. The exercises will be mainly in Java, with the first smaller exercise also available in C#. Participants can also bring their own troubled code to work on in the second half of the workshop.

Hardware development work has a physical aspect that makes controlling the flow especially difficult, such as deep specializations, and having outside vendors build custom components. This extension of the “getKanban” game models the hardware development workflow. As a player, you can change task priorities, expedite key items, or help other departments, but you must obey the WIP limits!

You'll see how these rules drive behaviors that you never would have expected by analysis alone. The game lets you live the action and make the decisions. Participants track daily progress along each workstream using a Control Chart, a Cumulative Flow Diagram, and Financial Summary chart. The effect of your choices such as increase queue sizes, reduce work-in-progress limits, expedite certain work – are seen graphically in the charts. This is a very engaging way to experience core lean ideas.

The problem with Continuous Integration is that you still have to integrate. Pair Programming is also constrained: You can’t have more than two, you can’t have fewer than two, and actually you don’t quite have two. Maybe we can do better.

Using a dynamic language, it is possible to create an environment where we are no longer limited by the number of people who can comfortably fitaround a single workstation. An entire team of programmers can collaboratesimultaneously on the same live code base; they never need to integrate because they always are. In this hands-on workshop, we will borrow from the hunting strategies of wolves to take Extreme Programming practices and turn them all the way up to 11.

To facilitate the exercise, we will use a web-based development environment. The focus of the workshop, however, is not on the technology but rather on the benefits and challenges of real-time collaboration. Does this practice make conventional Agile approaches look cumbersome or does it lead to disaster? To evaluate the effectiveness of this approach, we will ask our wolf packs to complete a series of tasks following the process.

This is a hands-on session; every participant should bring a laptop!

Waiting for a workshop or tutorial to begin? Have a little time on your hands? The Agile Cafe is the place to hang out. Create your own conversaton on an agile topic around a table or join a group that is already under way. Come and go as you please. Bring your own beverage. [ Link ]

Integrated tests are a scam: a self-replicating virus that threatens your code base, your sanity, your life! Your unit tests pass 100%, but you still have bugs, so you write integrated tests to make sure that things work together correctly… this way leads to pain and suffering. You need clearer interactions between objects, and more big tests make that problem *worse*, not better! In this session you'll learn the master design technique that can help you have arbitrarily high confidence in the correctness of your objects while testing 99.9% of your system with fast, tiny, crystal clear tests.

Liftoff - it's the unexplored, often ignored, Agile software development project practice. Liftoff gives impetus to your projects in a way that starts the project team, and the business, on the trajectory to success. Project sponsors, product managers, and product owners use these critical meetings to inform, inspire, and align the people who do the work with the definition of the work to be done.

As the first act of the flight, a rocket launch requires an entire set of systems to successfully lift the vehicle into orbit - not just the vehicle itself, but all the systems needed for smoothly moving off the ground into space. Likewise, your project needs its entire set of supporting systems in place to begin a successful journey to high performance, hyper-productivity, and high value delivery.

In this talk, Diana Larsen explores ways to accomplish Liftoff, including the vital step of chartering the project. She'll share real-life stories of how others have effectively started their projects; a varietyof team activities to fuel your Liftoff; and a framework for effective, "just enough" Agile chartering.