Program

Emily Bache will facilitate a tutorial where you will experience Test Driven Development in the safe environment of a Coding Dojo. Take the chance to improve . your skills and practice agile coding techniques with other programmers. We’ll spend the last part of the session discussing experiences using the Coding Dojo to teach TDD and agile programming in general. If you are already competent with TDD, you can use this tutorial as a way to learn the Coding Dojo method of teaching, and perhaps hold similar meetings at your workplace or local agile user group. http://bacheconsulting.com/

One of the key values of XP is Feedback. While teams and software development organisations focus on systemic issues and technical improvements for their Agile journey, the importance of sharing feedback amongst each other somehow falls by the wayside. Feedback in peer groups allows us to rapidly move from forming, storming and norming stages, to performing. On Agile teams that are focussed on communication, this is key to success. In this workshop, I will share with you how we approach feedback at my workplace and explain some of the principles we use to give and receive feedback every day.

It is a widely shared impression that the agile community and the critical system community live in completely different worlds. Actually, the critical system people normally develops according to standards like IEC 61508, MIL 882 or ED 109, they emphasizes well defined development processes, they often have contractually specified requirements, and detailed documentation of all activities is very important. This approach is radically different from the usual agile development approach. However, we think there are mutual benefits of bringing the two communities together. For example, agile testing approaches can most likely bring many advantages to critical system testing. These possibilities are currently not well understood and exploited.

On the one hand there are meanwhile not many projects left that are made at home without outsourcing, off- or nearshoring. Thus, global software development seems to be a fact in state-of-the-art software development. On the other hand more and more projects discover the success factor of agile software development not only since the Standish Group is recommending this approach. However, there are still a lot of people who believe agile software development is for small and collocated teams only. However, the agile value system and the principles as stated in the manifesto don’t argue about project size and distribution. Yet, agile software development requests –among other things– an emphasis on face-to-face communication, which seems to contradict with globally distributed environments. In this session, Jutta will report from her experiences in bringing the two trends –agile and global– together and on which practices help and which hinder the success of such a project. The following questions are the focal point of the tutorial: What are the possibilities to overcome the challenges global software development provides, and what are the success factors for implementing an agile software development process within such constraints? Jutta’s own experiences are mainly based on large global agile projects in embedded and commercial software development.

When I tried to learn object-oriented design, I read the classics. At least I tried to read the classics. It didn’t go that well. It wasn’t until I began practising test-driven development that I began to truly understand the principles of object-oriented design, including how to use them effectively to drive down the cost of adding features. After a while, I recognised that I had really learned the principles of modular design in general, and not just of object-oriented design in particular. Since I learned those principles this way, I also teach them this way. This is not a class in test-driven development, although we will review the fundamentals of test-driven development. Instead, in this class we focus on how to use a small number of simple rules to generate truly flexible designs: that is, designs that actually flex as you add more features. http://www.jbrains.ca http://blog.thecodewhisperer.com http://www.twitter.com/jbrains

Self-organizing Agile teams are a hallmark of Agile software development. This tutorial brings together a unique blend of research and practice as Rashina and Esther take you beyond the buzzword and explain how software development teams become self-organizing. Based on an original, industry-based PhD research and practical experience of mentoring numerous Agile teams, this tutorial provides an overview of self-organizing teams from multiple perspectives; a detailed description of what it means for Agile teams to be self-organizing; and practical tips to help software practitioners better understand their roles and responsibilities in establishing and sustaining self-organizing Agile teams.

Effective testing should be an integrated part of agile development. Various agile testing practices, such as ATDD, TDD, and exploratory testing, have been introduced. In practice it's not clear how to combine these effectively. Agile testing requires various skills and has to be done in parallel with development. Right balance between information, cost and feedback time is needed to achieve this. In this workshop we explore the testing activities required to get the feature done. We try in practice defining specifications by example, test automation and exploratory testing. We also look into how to improve based on the information gotten from testing.

Ever met a dysfunctional team mate? Then you know what we’re talking about. While coaching agile teams in different organisations we met a lot of people effectively sabotaging our agile transitions. Most of them didn’t mean to, they just behaved in a way that was dysfunctional in the team context. At the same time we started to think about what we could do about it and how to reduce this behaviour in our teams. We searched for the different causes and guess what: We found some. But what you tend to initially see is only the surface and not the real reason. Once you start to dig deeper to find the real causes you’ll find out that everything can be tracked back to four root causes. We call them “The four evil root causes from hell”: Ignorance, Fear, Indolence, Apathy. In our session we will play the Lego City Scrum Game. But instead of a full team of motivated people there will be some team mates behaving strange, trying to jeopardize our project goal. Join us to find out how to cope with such team mates to build better teams.

The integration of usability engineering and agile software development practices is an emerging challenge. Both the agile and the HCI community have recognized both the need and the difficulties to incorporate efficient usability practices in this domain. During XP 2010 a first edition of this workshop was held with about 25 attendees, who actively participated in an interesting debate about the topic and highlighted many open issues. XP 2011 workshop is aimed to keep on being a forum for discussing approximations for the intersection of agility and usability. Participation would be open to all XP2011 attendees. To present in the workshop, contributors would be required to submit a position paper or an experience report and receive advance approval of the organizing committee (to ensure relevance and quality of contributions). Those submissions should not exceed 4 pages in length in Springer's LNBIP format.http://wdua2011.eui.upm.es/

Many people have now heard of Kanban. Plenty of XP 2011 attendees will be familiar with boards to visualize work and work-in-progress limits and the concept of "pull." However, how do you go about leading a Kanban initiative in your organization? Where do you start? What goals should you set? How do you avoid resistance to change? This 180 minute tutorial will cover material that is either unpublished or available only in chapter 15 of the book Kanban - Successful Evolutionary Change for your Technology Organization. This material is normally part of the 3-day advanced workshop on Kanban Leadership & Coaching. There will be an assumption that attendees have a foundational level understanding of Kanban, its principles and practices. What they are seeking is advice on leading a Kanban initiative to success. In the first half, the tutorial will cover the principles (briefly), and then move on to discuss evolutionary change and reasons for resistance. It will look at emotional versus logical intelligence and emotional reasons for change. Avoiding emotional resistance through intentional choices of how to implement a kanban system design and introduce Kanban will be discussed. When emotional resistance does occur attendees will learn how to predict its occurrence and how to overcome it with a stronger emotion. The group will reflect on strong positive and negative emotions for motivation and how they affect an outcome. In the second half, the tutorial will cover the material from chapter 15 of the Kanban book. This looks at the specific mechanics of getting started with an initiative. At setting goals and building a consensus agreement around them. It will lay out 12 steps to go through to get started including shuttle diplomacy and how to negotiate the kanban system design, including classes of service and capacity allocation in order to get multiple competing stakeholders on-board with the implementation. Attendees will leave motivated to get started and with new insights on how to be successful. This material is normally covered on the first morning of a 3-day workshop. Over 100 people attended these workshops in 2010 paying $3000 each. Often feedback at lunch on the first day was these insights were worth the entire price of attending. For some others, further down the line with Kanban, it has given them insights into why they've struggled or what they might have done differently.

There is a lot of tacit knowledge in the industry about refactoring, but there are also some very hard cases.  Some code is so inscrutable that it defies most attempts to make it understandable.  Developers are tempted to throw it away and start over again, but as always, they are stymied by the fact that they don’t really understand what they want to replace.  In this tutorial, Michael Feathers will present a number of aggressive refactorings that can be used to move nearly intractable code up to the next level of maintainability.  The goal isn’t to make the code clean or pretty, but simply manageable. The techniques will focus on invasive changes that can be made on code with highly conditional logic and massive temporary variable usage.

For a long time, Agile literature have been focused on development practices, teamwork, processes and tools. Front-line roles like those of the Scrum Master / Agile Coach or Product Owner have been described, and some organizational guidelines have been described under the “Enterprise Scrum” or “Scaling Agility” tags. But it is only recently that the manager’s role on an Agile Environment is being deeply discussed and described. Depicted as “chickens” for more than a decade or even characterized as “the bad guy” by the most radical Agilists, their importance on the successful development of an Agile Corporate Culture and an Agile Environment where teams can strive and improve is scarcely studied. The traditional Command & Control management style must be dropped, says Agile. Teams must self-organize. Management must step aside. This kind of message is wholeheartedly embraced by Agile teams that have suffered bad management for decades, but managers are less likely to embrace a concept that, sometimes, seems to pursue the banishment of all management from earths surface. On an Agile environment, the manager’s role changes from the Command & Control system to a Servant Leadership & Role Model paradigm whose main responsibilities include impediments removal, constraints and goals definition, efforts alignment, growth management, team and individual development and, most important of all, corporate culture definition and improvement. The Agile Manager also has a leading role on change management and should act as a sponsor and a catalyst on an Agile Implementation project. On this half-day tutorial (240 mins), attendees will learn: What Agile means to a Corporate Culture and the old-style management, What to expect from a self-organized Agile Team and how Command & Control kills Agile, How to manage complex systems – or not, The Managers role on motivation, development and alignment, The Managers role on at the portfolio level: planning, measuring and executing on an Agile Environment. The intended audience include: Middle and top managers on an Agile environment or willing to launch an Agile adoption program on their organization, Project Managers on an Agile transition, Team Leaders that want to mentor their managers on the Agile Way, Agile coaches, Agile evangelists, Change Managers, Anyone interested on the Agile Corporate Culture concept, Anyone involved on an Agile transition / adoption project

This year marks 10 years since the signing of the Agile Manifesto.  In those 10 years, we've seen notable successes.  We've also seen XP-B, Scrum-but, Fragile, and just plain #FAIL.  Organizations have adopted agile methods to solve all manner of problems. But no method can solve problems unless management also changes. And that's a matter of changing minds, mindsets, and what matters to managers. 

Nowadays, Scrum is the most used Agile Methodology, while the Lean-Kanban approach is perhaps the fastest growing AM. On the other hand, traditional, waterfall-like approaches are still very used in real-life software projects, due to the ease of up-front planning and budgeting, that however are seldom matched upon project completion. In our opinion, more effort is needed to study and model the inner structure and behavior of these approaches, highlighting positive and negative feedback loops that are strategic to understand their features, and to decide on their adoption. In this paper we analyze the dynamic behavior of the adoption of Kanban and Scrum, versus a traditional software development process such as the Waterfall approach. We use a system dynamics model, based on the relationships between system variables, to assess the relative benefits of the studied approaches. The model is simulated using a commercial tool. The proposed model visualizes the relationships among these software development processes, and can be used to study their relative advantages and disadvantages.

Agile Project became real in an organizational software development environment, this paper, examines whether function points would be useful to estimate how long it would take to implement a story or to complete a release estimate how long it would take to implement a story or to complete a release on Scrum projects. Specifically, it addresses the question of whether function points would be a good measure of velocity. Though any unit of measure can be used, this paper contrasts theoretical concepts about Story Points (SP) and function points (FP) as units for measuring size. Also, was realized a statistical correlation between SPs and SPs using 2191 stories and 18 iterations in a Brazilian public agency. The conclusion drawn from this study is that function points, in that particular case, could be related with the initial value of the Story Points found after the planning poker.

In agile approaches such as Extreme Programming, time is not spent on making sure that system components can be reused in similar systems. Therefore, there is a need to investigate whether reuse can be achieved by extracting reusable assets from existing applications. This paper presents an approach that relies on refactoring and testing practices for extracting reusable assets from existing applications. The approach creates reusable APIs in a bottom-up fashion, on demand when a new application might benefit from component in an existing application. The extraction process is guided and supported by the usage examples and the testing scenarios in the existing application and the new one. The paper presents a case study, where the approach was used to extract components from the user interface of an existing application, wrap these components in an API, and use this API in the existing and new applications.

This paper presents a technique for test-driven development of GUI-based applications, as well as a pilot evaluation. In our approach, user interface prototypes are created in such a way as to allow capture/replay tools to record interactions with them. These recordings can then be replayed on the actual GUI as it is being developed in a test-driven fashion. The pilot evaluation found that developers integrated GUI tests, based on user interface prototypes, into their development process and used them as a way to determine when a feature is actually complete. Study participants felt that TDD of GUI based applications is useful.

Following her talk at XP2011, Esther will hold a facilitated discussion. In this session, we'll explore why silver bullets are so appealing, and how we can counter that appeal. We'll share stories, strategies, and tactics that really work to improve our ability to deliver valuable software.

Recently I have been asked often "we have tried this agile thing now for 1-2 years. What should we do next to improve?". People feel that agile does not bring the desired business benefits and something else is needed. Very often what is being done in practice is not very agile, though. In order for real change to happen we need to start thinking differently about many things and that is hard. Agile provides a good framework ´for improving SW development, but it is not enough when SW is only part of the product, in very large-scale development (tens of teams, systems of systems development) or when there is need to improve the way the whole organization works. Agile does not give enough framework for business management and other functions outside of R&D, something more is needed. For this "more" I recommend combining lean thinking and beyond budgeting to agile. Lean and agile complement each other in many areas, but there are also challenges in combining these two. Agile is very much team oriented and bottom-up approach works well in agile adaptation. Lean requires more top-down approach and involvement of larger organizations - or course it can be used also on team level. Another interesting difference is the role managers, which agile and lean see very differently. In this case it could be said that lean addresses the role of management which agile mostly omits. Agile and lean are not enough either, many of the traditional financial, planning and HR practices should also be changed to enable empowerment and lean way of working. For these issues we are now experimenting with bringing in some thoughts from beyond budgeting. So agile is not enough, we need a change in the whole management philosophy.

PyUseCase is a GUI-testing tool, but not like any such tool you're likely to have seen before. It aims to combine the ease of use of capture-replay tools with the maintainability of keyword-driven approaches. It works on rich client UIs, and began life working only with PyGTK. In recent years it has branched out and now also supports the Python libraries wxPython and Tkinter, and also Java SWT technology, including Eclipse RCP UIs. Although making use of a recorder, it does not record the GUI mechanics directly, but allows the user to build up an extra layer of abstraction, essentially a Domain-Specific Testing Language. Instead of an assertion mechanism, it generates a plain-text log of (in broad strokes) how the screen looks and how it changes in the course of the test: this information is then compared against previous runs of the same test. This makes it both more responsive to change and easier for a non-programmer to use.

Robot Framework [1] is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD). It has easy-to-use tabular test data syntax and utilizes the keyword-driven testing approach. Its testing capabilities can be extended by test libraries implemented either with Python or Java. Users can also create new higher level domain specific keywords from existing ones using the same syntax that is used for creating test cases. In this session we demonstrate how easily Robot Framework test cases can be created and how good reports you get after execution. We start from scratch but still manage to create several easy-to-understand test cases for a simple web based application. The tests utilize SeleniumLibrary [2], which is just one of the several ready made test libraries available for Robot Framework. [1] http://robotframework.org/ [2] http://code.google.com/p/robotframework-seleniumlibrary

The past decade has seen significant changes in systems development with many organizations adopting agile methodologies as a viable methodology for developing systems. An increasing number of research studies reveal the growing popularity and acceptance of agile methodologies. While most academic research has focused on adoption and adaptation of agile methods, there is very limited understanding of their post-adoption usage and incorporation within organizations. Have they been used effectively in the development of systems? What factors explain the effective usage of agile methodologies? A synthesis of past research in Systems Development Methodologies, Information Systems implementation, Diffusion of Innovations, and Agile Methodologies was conducted to develop a research model that identifies the main factors pertinent to the propagation and effective usage of agile methodologies in organizations. The model is validated by applying it to the usage of Kanban for Software Engineering practices at BBC Worldwide, London. Insights gained from the case study are discussed.

Learning is the bottleneck in software development. We rarely get to work on the same problem twice. Accelerating your ability to learn enables you to rapidly master skills and the Dreyfus Model of Skills Acquisition helps you understand how. In this lightning talk, we'll cover the origins, applicability to software and agile techniques and how best to speed up your learning.

To become more agile in the enterprise, all people require dependable access to up to date, linked up, transparent information. I outline some typical situations from my practical experience and the feedback I got in facilitating this topic as a presentation and workshop at three different conferences last year (HSE workshop, Munich, Scrum-Day, Berlin, XPDays Germany, Hamburg). How can agile projects be integrated into the enterprise information infrastructure? How do we get away from storing Office documents on file servers? How does information from a whiteboard get into those documents, and vice versa? How does the infrastructure (of the projects and the enterprise) need to change to enable a sustainable integration? I’ll share experiences, point out typical traps and sensible solutions. How do we make it work in practice, to change the enterprise information infrastructure in a way that it becomes useable as a base for agile process improvements? Mail: olaf.lewitz@agile42.com, Web page: http://www.agile42.com, Twitter account: @agile42 or @OlafLewitz

Discussion on the topics raised in Kati's talk with title "When agile is not enough"

ESOC (the European Space Agency’s Operation Centre) is experimenting with Agile and Scrum methodologies in its quest for improving productivity, enhancing project visibility and control, reducing time to market, improve software quality and increasing user satisfaction. In this article we present lessons learned from applying Agile in general and Scrum in particular to a number of projects, from applying a few Agile best practices to full Scrum. ESOC has traditionally developed its software using a waterfall process mostly under Firm Fixed Price contracts, in this context using Agile brings challenges from project management, contracts and quality control perspective. Using a coaching approach, the organisation has managed to accelerate its integration of Scrum, including industrial teams developing the software, and already yields positive results which are promising for the future.

Many publications in the Agile literature offer ready-made “recipes” for solving a certain problem. We believe this is way too often not helpful as the context varies a lot. Instead we offer a _story_. This is how _we_ did it in a big project. The story is told through the major events of the project, called “Release Planning” events. We hope that from our story you’ll learn some ideas on project planning and steering on a larger scale … even if it’s not promising to solve your problems ;-). The release planning method itself (based on Dean Leffingwell's Agile Release Train) is explained on a high level only (one big picture). Then we'll explain our journey with this method in a mid/big-size project (ca 120 people). We explain how the long-term planning method evolved over the course of the "Business Iterations", a higher-level cycle on the timeline that business managers are interested about. Several tough decisions had to be made as the project unfolded, from re-scoping to splitting the project. We gained better understanding of the sheer size of the content, the inherent complexity of the product and the challenges of the multi-team setup with the help of this method. We believe that without this added layer of planning many of these decisions could have happened very much later. Our case is an example on gaining visibility to project progress on a higher level and getting better chances of steering a complex and risky project.

Harvesting the Net about Agile: Hot topics, influencers, Opinions, fears and solutions: We will talk about the agile hot topics currently more commented in the Net like: UX-Agile, TDD and BDD problems, difficulties implementing scrum, agile and closed contracts and so on. We will try to show the opinions and fears about them in Internet, twitter, to analyze the data and offer the best solutions/approaches to this topics.

This talk will (quickly in 10 minutes) explain the Principles of the Kanban Method as detailed in this blog post http://agilemanagement.net/index.php/site/the_principles_of_the_kanban_method/ It will explain the principles of evolutionary change. The 5 core practices and the 9 recognized emergent behaviors observed with teams pursuing the approach. This is intended as a foundational talk for those who want to understand the theoretical framework of Kanban.

We developed an event-driven simulator of the Kanban software process – a WIP limited pull system visualized by the Kanban board. The simulator is fully object-oriented, and its design model reflects the objects of the Lean software development domain. We used this simulator to assess comparatively WIP-limited and unlimited processes. We also studied the optimum values of the working item limits in the activities, using a paradigmatic case of 4 activities and 100 work items. The cost function used is equal to the total time needed to complete the project, plus a weighted sum of the limits themselves. We performed an exhaustive search on all the admissible values of the solution, finding sensible optimal values, and a non-trivial behavior of the cost function in the optimization space. This demonstrates the feasibility and usefulness of the approach.

During our Kanban implementation at one of the biggest insurance companies in the Benelux we learned valuable lessons on what we could have done better the first time around. The adoption included more than 15 teams and more than 150 people. A Kanban adoption is different from an agile adoption. The lessons learned are presented in a top 7 list. Learn from our mistakes, so you don't have to make them.

After the excellent presentation at last years XP2010 presentation on test driven Javascript in the browser, I have used the techniques proposed in real world code and expanded it to include the ideas from Behavior Driven Development. My initial use of test driven Javascript very much followed my learning curve in other languages, i.e. first a very technical approach where test code actually tests a function. Later, with a change of tools, I learned how to drive the code from actual behavior in the web page, instead of low level technical specs for a function.The talk will shortly describe the journey from novice TDD Javascript to a more mature BDD approach. It will have live coding showing examples from both approaches focusing on the BDD part, showing how the behavior of a web page is described in a BDD fashion and how it drives the implementation. The talk will be very technical and code centric, but with a clear focus on delivering value to a stakeholder.

To be published

As Agile prescribes a "New Deal" between customers and providers based on collaboration, responding to change, short iterations delivering working software, business value based prioritization (not to mention sustainable development), many companies implementing an Agile approach are wondering how this Deal should reflect on their contracts. Join us on this session where we will try to understand which are the key points an Agile contract should address, the differences with regular contracts and a whole bunch of different contracting models other than "fixed time, fixed money, fixed scope" (and also learn how to deal whith this monster).

Scrum has been one of the most revolutionary happenings in the software development world over the last years. Its empirical approach, strikingly changes the way people face projects, and shifts the focus into improving upon development practices, while continuously delivering valuable software increments. Combined with the proper tools and practices, teams can dramatically improve their performance and fulfill customer expectations. This session makes a tour around the Scrum framework, showing how Scrum Teams work in practice, and going into details about how Visual Studio and Team Foundation Server can support and facilitate a great amount of the activities carried out by these teams in their quest for delivering value.

Agile is often criticised for doing the wrong thing faster and without considering the wider system can often do so. Systems thinking is critical in helping teams and organisations build the right thing faster. In this lightning talk, we'll cover the core elements of systems thinking and its applicability to the agile software development world.

Agile Software Development methods have caught the attention of software engineers and researchers worldwide, but scientific research on the subject still remains quite scarce. The aim of this study is to organize and facilitate future works of the Agile methods derived from manufacturing industry. This comparative review is performed from the standpoint of using Abrahamsson et al.'s analytical perspectives: project management support, life-cycle coverage, type of practical guidance, adaptability in actual use, type of research objectives and existence of empirical evidence. Our results show that Agile methods derived from manufacturing industry~(without emphasizing the process through which software development proceeds) cover various phases of the life-cycle and that most fails to provide adequate project management support. Moreover, only Critical Chain offered concrete guidance to support its solutions or adaptations in different development situations. To describe the status of research on Agile methods derived from manufacturing, we conducted a literature search in the ISI Web of Science. After ten years of application empirical evidence remains quite limited.

This talk will present my Lean Decision Filter: 1. Value trumps Flow, 2. Flow trumps Waste, 3. Reduce Waste to improve efficient, do not pursue economy of scale and discuss why it makes sense and how to use it a line, middle and senior management levels to change the culture of the organization and encourage the formation of a Lean organization and a better economic outcome for all stakeholders.

With the growth of agile software development methods we have seen an increased focus on empowerment of the software developers as a means to improve productivity and quality in software development. From other knowledge-intensive industries we also see that participation in decision making is argued to improve not only business, but also workers' job satisfaction. In this study interviews from four different types of software development organisations in Norway are collected and analysed to get more insight in how decisions are made in software development. The four types of organisations are a) small, in house software teams, b) software company with undefined development process, c) software company using unified process, and d) software company using scrum. We see that experience is a dimension that significantly influences the developer's empowerment. But there is also a clear differences among those four groups in what kind of decisions developers are participating in, and what level of participation they are admitted.

This talk is about the groups dynamics that hinder self-organization in an Agile team, seen from a behavioral perspective, and about the ways to counteract these issues. The concept of self-organization is strictly related to empowering the technical teams, which in turn may alter both the "vertical" dynamics (managers/teams) and the "horizontal" dynamics (teammate/teammate). Resistance to these changes may therefore arise both in managers and in team members. The actual source of this resistance may be rooted in the mental habits of the people involved and may come from a latent blaming culture, from confusing guidance with command, from the fear of taking responsibility (becoming visible) or losing status (becoming invisible) and finally from a misalignment of the team with the organization's business goals. We'll see some of the most common sources of resistance to self-organization, as well as techniques to loosen the blocking dynamics.

Do agile teams really still use index cards, PostItTM notes and walls for planning projects? Yes, absolutely. Even in this age of sophisticated tool support it is hard to beat the raw power and efficiency of working with physical media and using walls to display information. This Lightning Talk describes a four-day planning workshop from the perspective of the walls in the room. Through photographs, video and music we will watch the wall start off clean, and see it go through various changes as the team identifies requirements, creates user stories, organizes their backlog, builds user story maps, sizes the backlog of user stories, plans 5 releases at a high level, and plans two sprints in detail. The wall (actually four walls in a single room) goes through many changes as the team start from a blank wall and move through release planning and in to sprint planning. The last day of the workshop is the team’s sprint planning session. This fast-paced lightning talk will address the following topics: • Themes, epics, hundreds of user stories, • Release planning, • Sprint planning, • What do teams use the walls for?, • How do they move from one activity to the next, and how is this supported using walls and paper?, • Does it actually work?, • What are the advantages over using a software tool?, • Where do software tools fit with all of this?, • What are the downsides?, I will provide examples from real projects using photographs, video and music.

When we use single point estimates with our bosses or clients, we are falsely communicating that we believe in a certain estimate with 100% confidence. Managers have trained us to work this way, but then they wonder why they often can’t trust a team’s estimates? This lightning talk will focus on how to have a more honest conversation that accurately conveys risk and uncertainty. Of course it’s tough to have a more honest conversation if management does not see benefit in changing the basis of the conversation, and so we will also explore ways to convince the enterprise that it is in everyone’s best interest to consider a more honest way to communicate estimates. Outline: This will be based in part on a talk I gave at Agile2010 on how to build range estimation in Scrum practices. After delivering that talk several times at user groups, I have learned that people are interested not only in the more technical aspects of how to build a range estimate into scrum practices, but also the wider implications and how to get management buy-in. Therefore this presentation will be a little more high level and will cover a wider range of ways to use range estimates and how to get buy-in on their use. • The pitfalls of single point estimation, • Range estimates are an information radiator – they convey risk and uncertainty, • Techniques for using range estimates in Agile and Scrum, • Managing up: how range estimates help your organization to make better decisions. I will consolidate these key points into the most essential and actionable items so that they fit within the lightning talk format.

The ALE network is a group of authors, speakers, community builders, and leaders who are dedicated to promote Agile and Lean thinking in Europe, and who aim to share knowledge and experience about Agile and Lean organizations, with a pan-European interest and approach. The network was born in February 2011 and has attracted 700 interested participants from all over Europe, in a very short time. In this session we will share the purpose that has emerged out of this fledging new network. And using a world café format we will ask everyone to participate in discussions and generate ideas and plans that will help to increase collaboration of Agile & Lean people in Europe

Scrum implementation projects on high-uncertainty environment are challenged when Product Owners are asked to freeze scope for a full Sprint. On the other side, a full Kanban implementation tends to shift team focus to urgent short-term needs prioritized by business customers, thus impacting the important long- term projects and companyʼs strategic commitment. A Scrumban strategy for managing part of the Team's sprint capacity as an "uncertainty buffer" with different qualities of service will be discussed on this talk, as well as some metrics that can be used to obtain better predictions an stablish Service Level Agreements with clients.

It’s widely agreed that Agile has "crossed the chasm" to mainstream acceptance. Along the way, some of the more interesting bits have fallen off. This talk will be the latest in a multi-year effort to recover those bits, rehabilitate them, make them stranger, and encourage you to put them to work. There will be no overarching "Big Idea", but some smaller ideas will include the distinction between what I call "the stance of rationality" and "the stance of reaction" (I favor the latter), the high cost of thinking, the virtues of habit, and some criticism of the optimistic ideas about teams, enterprises, and leaders that infest our field. There may also be a tango lesson.

Agile software development has become the standard in many companies. While there are reports of major improvements with agile development over traditional development, many teams still strive to work effectively as a team. A multiple case study in two companies discovered challenges related to communication, learning and selecting the tasks according to the priority list. For example, the fact that the developers were not actively involved in the planning process, resulted in weak team orientation; even though the teams had identified and discussed recurring problems, they found it difficult to improve their teamwork practices; and because customers and support communicated tasks directly to the developers and developers chose tasks according to interest and expertise, following the priority list became difficult. We provide practical suggestions for teamwork in agile software development that intend to overcome these problems and strengthen team orientation and team learning in order to achieve effective agile teams.

There are many Scrum teams out there that are executing all the prescribed Scrum rituals but still don't benefit from it. All the meetings are taking place at the agreed dates, everybody is on time but still something is wrong. Could it be that we have to deal with a team of Scrum zombies? In my talk I'll speak about what a Scrum zombie is and how to cope with it.

Experts have the easiest job in the world. All they have to do is focus on a narrow slit of knowledge and answer questions about that field. Everything else is somebody elses problem. Most Scrum teams I have come across, cherish the idea of the cross functional team, and most claim that their team indeed is a cross functional one. Very often however, the index cards on the wall are not available to just anyone from the team. Most stories are divided into tasks, where some can only be done by the DBA, others only the backend programmers, and yet others are for the Javascript/GUI/thumbring guy only. The talk goes through in a humorous way the different kind of experts a development project generally sees, including the methodology expert. It stated the idea that expert knowledge, seen as a "I" competency, is in itself not enough. Instead teams should strive for its members to have "T" competency - meaning that they have deep knowledge in one or more fields, but also basic knowledge in all fields required by the product presently being built. This talk has been given at Agila Sverige 2010 and Smidig 2010 with very positive response. The uploaded file is mostly in Swedish, I will provide a translated version shortly.

15 years ago, programmers thought writing unit tests was a waste of their time and something to be avoided. Things have changed! Now it's test *maintenance* that's a waste of their time and something to be avoided. In the past couple of years, Brian Marick has come to love test maintenance. In this discussion, he'll claim he's not insane and justify that claim using some of the ideas from his keynote. Thereafter, the discussion will broaden to include any further thoughts anyone has about the application of keynote ideas to the technical parts of Agile development. (As a contract programmer, the technical bits are what Marick's most interested in, and this will be his chance to copy other people's ideas.)

The second great myth of software development is that it's mostly on greenfield projects. The reality is that the overwhelming majority of development is legacy work, and much of that is deep: projects 4 years or older. Technical leaders in deep legacy, whether formal or informal, need reliable techniques for helping teammates develop the necessary skills and attitudes to tame the great legacy monsters. In this talk, we explore five proven techniques geek leaders can use to grow their team's agility even in the deepest of legacy environments: * Close Reading -- teaching the skill of changing *this* code without studying *all* code; * Lottery Learning -- making regular gatherings to build a shared and ever-rising standard of excellence; * Rotator Role -- percolating new ideas and techniques throughout the team by pairing with *everyone*; * Bottlenecking Pressure -- moving to a work-in-progress limited swarm-and-pull system to eliminate planning theater; * Inch By Inch -- instilling and extending the long view by emphasizing incremental approaches. If you're a technical leader in a complex legacy setting, you'll need extra effort to bring your team to agile practices. Geek Leadership in Deep Legacy is where to start.

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 paper describes a technique called Silent Grouping that can be used to compliment Planning Poker, explaining how to apply it so that large sets of user stories can be sized in minutes. Experiences of seven Scrum teams from Cisco’s Unified Communications Business Unit are used as examples. The paper shows how to apply the technique with co-located teams, and includes an example of how it was used with distributed teams. Silent Grouping has several advantages. It is fast, which in turn leads to significant time and cost savings. It also has more subtle benefits. This paper discusses the techniques, challenges, cost savings and benefits of Silent Grouping.

Agile methods encourage producing a completely “done” increment of software at the end of every iteration or release. The problem arises when people involved in the project, either from the development team or stakeholders, don’t agree on what is considered “done” or even if there’s not any clear definition in place. This lighting talk will try to give some advice on this subject, and help assistants to get a working and useful definition of done to apply on their projects. Note: the talk can either be given in English or in Spanish, depending on the audience, or even be given twice to cover both languages.

Many agile teams are familiar with Definition of Done as a set of agreements that let everyone know when a user story (or a sprint or a release) is really done, and all necessary activities are complete. This Lightning Talk describes the Definition of Ready as applied to user stories, sprints and releases. Definition of Ready is a set of agreements that lets everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint. This lightning talk will address the following topics: • What does it mean for a User Story to be Ready?, • What does it mean for a Sprint to be Ready?, • What does it mean for a Release to be Ready?, • What effect does Definition of Ready have on the dynamic of the team and the wider organization?, • How does a Definition of Ready impact stakeholders in the project?, • What are the implications for your Product Backlog?. I will provide examples from real projects that use Definition of Ready.

This demo is for those who already have some experience with TDD. It would be valuable to those who want to jump to interpreted languages and specially useful to Python developers. We will see code: best practices on Python to work with stubs, mocks and other test doubles. We will use the Django web framework to understand how TDD applies to a Model-View-Controller architecture and to the nature of the web. Top-bottom and bottom-up techniques will be discussed with examples.

Build automation is a core practice for XP and other agile methods; using the right set of tools, developers can maintain a working set of code that is built easily and with minimum configuration overhead. Continuous Integration of the code in order to synchronize efforts between all the members of the team is the natural evolution from build automation. And with a little more effort, continuous deployment can be set up, so new features and bug fixes are seamlessly prepared to be tested or even delivered into the corresponding environment. This demonstration will show how these practices can be easily adopted by teams working in Microsoft/.NET environments. The demo is aimed to agile developers working with .NET technologies, who want to begin incorporating build automation into their projects.

Come to this discussion session chaired by Mike Hill, and talk with him and other experienced programmers. Many people have wrestled with legacy code and some have succeeded in bringing agility to situations where there was little before. We'll share some war stories and some encouraging tales and talk about what we've found to work in real life. The discussion will use a fishbowl format, so audience members are welcome to join in.

Agile software development represents a major approach that has gained increasing popularity in recent years. Economy forces agile organizations to overcome geographical distances to benefit from accessing a larger resource pool and to reduce development costs. However, agile and distributed development approaches differ significantly in their key tenets. While agile methods mainly rely on informal processes to facilitate coordination, distributed development typically relies on formal mechanisms. To address this situation, we present an agile distributed release planning approach to identify feature chunks that can be implemented co-located to minimize the communication needs between dispersed teams. The presented method demonstrates how this approach 1) necessitates less intensive communication and coordination, 2) can provide better utilization of resources, and 3) can produce higher quality feature distribution plans. Finally, the paper analyzes benefits and issues from the use of this approach.

User stories are great for planning the content of an individual iteration, but don’t help a project plan releases. By using scenario steps that describe each release as viewed from the system stakeholders, we were able to plan about twenty separate deliverable steps in a fifty man-year replacement project. One of the ultimate goals of the project is to replace a system that is currently in production. At the same time, several collaborating systems will be replaced or upgraded. A prime concern is how to create value before the whole system has been replaced. Each of our twenty scenarios describe the totality if the system with the new system, the old system and all collaborating systems working together. In this lightning talk, I will cover: How we created scenarios at an appropriate level of detail, How we prioritized the scenarios with all the project stakeholders, How working with scenarios give our development teams a clear vision of what they are trying to accomplish, How using scenarios let us communicate effectively with other projects in the organization. After going to this talk, the audience will have another alternative to consider when creating their product backlog as well as further insight into how to approach seemingly monolithic projects.

All projects strive to deliver the wanted result on time and on budget. To do that a plan is devised, often based on the budget. And the tracking becomes a matter of staying on the plan. But since they are very similar, few realise that they are trying to achieve three very different goals using the same data. The budget becomes the plan, which also becomes the wanted outcome. This lightning talk will try to help you see the reasons why this might not be an optimal project management principle and also suggest a different view which takes its basis in the three different goals that we are trying to fulfil with our budgeting, planning and tracking.

Effective communication is important for distributed Agile software development. We have conducted a Grounded Theory study to investigate the communication challenges for the distributed Agile teams in the USA and India. In this paper, we present the causes of communication challenges (time zone factor, lack of communication tools, language barriers, and lack of teamwork) and the strategies adopted by our participants to overcome communication challenges (reducing time zone factor, leveraging communication tools and techniques, addressing language barriers, developing trusted relationships, increasing formal communication, and increasing informal communication)

Scaling agile is hard to do. Pilot team does great, next few teams do well, and then the problems start. Scaling agile from the ground up is hard work and difficult. We need a different way of getting agile into big corporations. Instead of scaling agile we need to adopt agile at scale. And things at scale behave diffently. This session highlights four items in which agile at scale behaves differently from scaling agile.

We have introduced agile software development into a big distributed project at Siemens Healthcare, and have passed the first phase of transition. The goal is becoming more effective and better equipped for a competitive global environment. One important aspect enforced by Agile is the aspect of responsibilities. To develop our suppliers from an "extended workbench" only implementing exactly what they have been told, to partners willing to take over responsibilities for a complete set of features, it is a long way to go. But in special it needs a change of the mindset of headquarters, and also of the suppliers that become now partners. It is about the mindset how we see and treat each other, as well as the mindset about giving and taking responsibility. This is the most crucial point in what we defined for our Agile Transition. Andrea Heck is Agile Transition Lead for a big software development project in Siemens AG Healthcare, including suppliers on several sites. She is Certified Scrum Practicioner. She has an University degree in Computer Science and more than 15 years working experience in many different roles of the software development.

Introductory courses on Algorithms and Computer Programming typically present high failure rates. The lack of motivation and the difficulty encountered by some students are among the factors that lead to poor achievement. This paper presents a new teaching method that results from combining the virtues of Problem-Based Learning (PBL) with the flexibility of Extreme Programming, creating a more collaborative, challenging and dynamic learning experience. The method also contributes to raise the quality of code and to enhance students' abilities to analyze problems with the use of best practices in Software Engineering. In order to implement the method we developed an application called TaskBoard, which assists groups of students in the process of XP-based problem solving, also facilitating the development, management and persistence of the solutions and related artifacts.

Make my living by helping people implement and manage build and Continuous Integration systems. I did a talk at QCon 2009 on Continuous Integration (see following hyperlink). I plan to update it for 2011 (a lot has happened since I wrote it). http://www.infoq.com/presentations/ci-from-the-trenches I'd like to experiment with different ways to present this talk; I tried to make last year's QCon presentation more of a dialogue than a monologue, and this year I'd like to try the shorter lightning talk format. It seems like a good way to start a dialogue with conference participants: It's my firm belief that software only matters when it's running to help improve our world, and I'd like to exchange experiences with people on delivering software to production. My line of work is an odd niche: I don't write production or test code, but I care deeply about the quality of both, and often find myself discussing quality with developers. Sharing these experiences, and my hands-on skills in implementing Continuous Integration processes seems like the proper thing to do.

You have probably seen TDD described or presented by grabbing the keyboard and typing in the first test. Sure, tests, or descriptions of wanted behaviour comes first, but what you don’t see is what might, or even should, happen in your head before grabbing the keyboard. This session will present some simple tricks that has been shown to help you to get into TDD on the right foot, showing also that there actually is more to TDD than typing. We will also see a few tricks to keep going and some simple thoughts on how to keep your code clean from the start.

Come to this discussion session to meet experienced agile coaches: Joe Rainsberger, Olaf Lewitz, Kati Vilkki, Mike "Gee Paw" Hill, and Rachel Davies. We are not really very old or grumpy but we do have a few stories to tell about difficult situations we've faced. We hope that this session will inspire those of you new to agile coaching and give you ideas for actions that you can take yourselves. We'll be running this discussion as a "Park Bench" format, so we rely on you (in the audience) to feed the coaches with situations that you want to hear about. Simply jump into the empty chair to join the dicussion.

Many people are now familiar with BDD's scenarios, in their "Given, When, Then" format. In this talk we look at the philosophies of Deliberate Discovery and Real Options which lie behind the use of scenarios, and two conversational patterns which can help us explore our understanding of software. By applying the same concepts to three commonly used models for testing our lives (TOTE from NLP, GROW from Coaching and PDCA from Deming / Lean), we show how we can explore our lives and achieve our personal, team and process goals more quickly and with less risk than with simple positive visualisation alone!

Self-organizing Agile teams need a supportive environment to emerge and flourish. Through a Grounded Theory study of 58 Agile practitioners across 23 different software organizations in New Zealand and India, we found that senior management support is a critical environmental factor influencing self-organizing Agile teams. We describe the influence of senior management, and show how their support can create and sustain a supportive environment for self-organizing Agile teams.

Command and Control has many forms and names (old style management, micromanagement, consulting mode, military discipline) and all of them have been recognized as an anti-pattern for the emergence of complex, adaptative, cross-functional, self-organized teams that are capable of the kind of results that are not available through the sum of individual contributions. Despite the overwhelming evidence against command and control on an Agile environment, the apparent easiness of the “just give’em hell and ask for more” method and it’s misleading occasional results provide all the environmental needs for the development of an addiction to power and the compulsory behaviors that result from this addiction. In this lightning talk we will depict Command & Control managers as addicts, and we’ll see how a 12 steps program can help recover this individuals and place them on a path of facilitation, mentoring and coaching. This steps, base on the famous AA program, should provide a method that allows the addict to admit that he can’t control his addiction, recognize that there’s a higher state of performance that it’s not possible right now, examine past errors in search of improvement opportunities, plan for improvement, develop a new code of behavior and help others that suffer from the same addictions.

Why agile methodologies works well? What is the link and the key of sucess between agile methodologies and the new socialism? How ours attitudes as human beings make this things work well? How does this changes our lifes, our way to work and interact with employers and employees? What did those important and great Socialist thinkers say about? Is this the new socialism?

At XP 2010, Ivar and Johannes demonstrated how fast a pair programming team can write a web application test first. At XP2011, in the second installment of the Java EE spike kata, we demonstrate how to extend a simple test-driven web application and refactor from a simple to a more advanced design. The demonstration starts with a small and simple existing code base. We will add a requirement to this code base and test-drive the implementation. In the course of the presentation, we will demonstrate effective pairing, several TDD techniques and libraries, effective use of Java IDEs and a complex refactoring. The demonstration will take about 20 minutes, leaving plenty of time for questions. Elements demonstrated: Effective pair programming; Test-driven development approaches; WebDriver, Mockito and FEST-assert as testing tools; How to test web applications via HTTP and by mocking the Java Servlet API; Refactoring techniques - Replace Method with Method Object. Why you should care? Because XP practices are easy to talk about but hard to do; Get inspiration for attacking your own problems with tests Get inspiration for how to pair effectively and have more fun!. Who should watch? Developers with limited experience with XP coding techniques and their bosses; Developers who wonder how to apply XP techniques in realistic projects; Developers who want to see how much a modern IDE really can do for you; Project managers who wonder what it will be like if their projects use these techniques.

In the last decade there has been increasing interest in pair programming. However, despite work has been done, there is still a lack of substantial evidence of pair programming effects in industrial environments. To increase a body of evidence regarding the real benefits of pair programming, we investigate its relationship with software defects. The analysis is based on 14-months data collected from a large Italian manufacturing company. The team of 17 developers adopted a customized version of extreme programming and used pair programming on a daily basis. We explore and compare the defect rate of the code changed by doing pair and solo programming. The results show that defects appear to be lower for the code modified during pair programming. As a consequence, we formulate a hypothesis that pair programming is effective in reducing the introduction of new defects when existing code is modified.

What are the benefits of doing BDD or ATDD over just unit testing? How do you know if you are doing BDD or ATDD right? What are the most common mistakes teams make? - these are just some of the questions this panel of experts will be answering in this session. All conference participants are welcome to come and contribute questions and listen to the discussion.

Many individuals and teams involved on projects are already using agile development techniques as part of their daily work. However, we have much less experience in how to scale and manage agile practices as part of a concerted effort of improvement across an integrated supply-chain for enterprise software delivery. In this paper we discuss the scalability of agile approaches through a detailed case study in agile adoption. In the context of this example we examine how “agility at scale” is applied, describe the key scaling factors and their impact on agility, and review some of the rollout and deployment issues that can limit the adoption of agile approaches in practice.

This paper takes the readers through a real project life path to show what went well and what didn’t. The paper first lays out all the pain points of the project. Then it describes how the team has successfully handled each of the issues. The paper doesn’t stop here. Instead, it digs further by taking off the veil of success as the project looks like and focuses on the areas needing improvement. The paper elaborates on how to squeeze out nonvalue-added waste through value stream mapping. It also discusses the importance of Agile “transfer”, customer redefinition as well as running a true iterative iteration.

Pair Programming is one of the techniques of agile methods that has gained popularity both in academic and industrial environment. Many advantages and disadvantages of this technique have been identified. In this study we observe daily work of nineteen software developers of a large Italian manufacturing company for a period of ten months. Fifteen developers are existing team members and four have recently joined the team. We identify the tools the developers use, how they distribute their time among these tools when working alone and when doing Pair Programming. The data has been extracted non-invasively by means of PROM – tool for automated data collection and analysis. The preliminary results indicate that the developers working in pairs in all configurations devote significantly more time to programming activities than the developers working alone.

This paper reports on an empirical study about the mechanisms of collaboration of drivers and navigators in Pair gramming (PP) sessions. Based on video recordings of professional software developers, we analysed the mechanisms of role switches and how developers split the task of driving. We found that developers do not evenly contribute to the task of driving and that they spend on average a third of the session without any computer interaction focusing mainly on communication. In addition, our results show that most pairs switch roles frequently and that the frequency and fluidity of switches indicate the high level of engagement on the part of both developers.

Agile Methods are a set of software practices that can help to produce products faster and at the same time deliver what customers want. Despite the benefits that Agile methods can deliver, however, we found few studies from the Southeast Asia region, particularly Malaysia. As a result, less empirical evidence can be obtained in the country making its implementation harder. To use a new method, experience from other practitioners is critical, which describes what is important, what is possible and what is not possible concerning Agile. We conducted a qualitative study to understand the issues faced by early adopters in Malaysia where Agile methods are still relatively new. The initial study involves 13 participants including project managers, CEOs, founders and software developers from seven organisations. Our study has shown that social and human aspects are important when using Agile methods. While technical aspects have always been considered to exist in software development, we found these factors to be less important when using Agile methods. The results obtained can serve as guidelines to practitioners in the country and the neighbouring regions.

Do you ever struggle while addressing motivational issues with your people? Do you ever wonder how to improve the performance of your teams? Managers and coaches now get a chance to meet Miracle Mountain, a model for more effective coaching. This 5-level model is a powerful management and coaching tool to find the root cause of problems and the core of improvement opportunities. The true power of the model lies in the fact that it helps you address the intrinsic motivation of people and make them work miracles. During this lightning talk, you will be introduced to the model and be guided to using it effectively. Help people work miracles with Miracle Mountain in your backpack.

In my life as ScrumMaster I faced many things which drove me nuts. In my lightning talk I will speak about the 10 best things to drive YOUR ScrumMaster crazy.

"Experiences on promoting Agile Methodologies in our Region". This talk will be different from most because we will not talk about an idea but rather about a project we run last year 2010 on our Region in Navarre in order to promote the adoption (and use) of Agile Methodologies in any kind of development project (IT or not). We will talk (fast, promised!) ahout why we did it, how we did it, what outcomes we've had so far as well as show briefly our future (next Sprint) plans, which could greatly benefit with the ideas and contributions of any of the attendants. We think it can be a nice experience to share, this is the purpose of this Lighting Talk.

Ten years ago, at the time the Agile Manifesto has been created, most people believed that agile software development is for small projects and teams only. With the overall success of agile approaches more and more large projects, teams, and organizations also wanted to benefit from a value system that is helpful for small projects. Although in the meantime we’ve made many experiences applying agile in a large context it is still true that agile at scale differs from agile at small, because of the difference in constraints. We will discuss experiences and still open issues with agile at scale in a fishbowl, which is an open discussion for every participant. Thus, join the fishbowl and involve yourself in the discussion with speakers and other participants.

The software profession appears largely ignorant of its own history, an ignorance which has detrimental consequences. This beginner-friendly talk goes back to the forty-year old roots of "software engineering" and the "software crisis" and applies the model of "disruptive innovation" to clarify where Agile has come from and where it is headed. It debunks some Agile myths along the way, such as "Agile has gone mainstream" and the push for more certification, outlining an alternative roadmap for progress driven by the Agile community.

Physicists tell us that there are at least four dimensions that are important to us. We typically only think of the three spatial dimensions: length, width, and depth, but time is a dimension as well. It is clearly as important as the other three dimensions but we don't often think about it because it is not in front of our eyes. Time presents the same problem in refactoring. We see the current structure of our code, but what we don't see in front of us is its history. We make assumptions about how changes occur based upon conception tools like the Open/Closed Principle, but we can make our decisions based on actual data. After all, we have version control histories of our code. In this workshop, we will mine the change histories of several open source projects and use them to identify patterns that unfold in time within codebases. We will also discuss how what we've learned can inform and affect our reasoning about refactoring. Participants in this workshop should bring a laptop with Java development tools installed and Ruby 1.8.

Executable requirements neatly combine two important XP practices: user stories and acceptance testing. They enhance communication, ease following the number of running tested features during an iteration, and work as regression tests in future iterations. This workshop gives an introduction to this important process and also shows how it is used in developing a realistic system. Participants can also join the fun and get real hands-on experience. Requirements in general, and executable requirements in particular, are important for all project members (customers, developers, testers, ...) and this workshop has something to offer to all these stakeholders. The workshop is suitable for both practitioners and beginners. Beginners will get a deep introduction of executable requirements and see how the process works. Practitioners can deepen their knowledge, share their experiences and learn from others. Workshop starts with a short introduction of executable requirements and Acceptance Test Driven Development (ATDD) process. The ATDD workflow, Discuss–Develop–Deliver, is explained to provide frame for rest of the session. Additionally Robot Framework, the tool that is used to automate executable requirements, is briefly introduced. The hands-on part starts by introducing an existing, partially complete application which will be developed further during a mini-iteration. Existing acceptance tests and the development environment are introduced to show how development has been conducted earlier. We will also briefly discuss version control and continuous integration, two important pieces of the whole ATDD workflow, and participants will see these tools also in action. The actual hands-on iteration begins with the Discuss phase. The target is to gain collaborative understanding about what we want to build and document that as executable examples. This is the most important phase of the ATDD process and also the most important learning possibility in this tutorial. In the Development phace the participants automate the executable examples using Robot Framework together with the organizers. The organizers act as developers and are responsible for implementing the new features. Although we use Robot Framework for automation, everything related to ATDD process itself is generic. Learnings from this tutorial are thus applicable when using other acceptance testing tools such as Cucumber, FitNesse, TextTest, or Concordion. No previous experience about ATDD or Robot Framework is expected, but basic understanding of Agile practices is assumed.

The nature of coaching often means agile coaches work alone, so how do you get better as a coach? You work with peers to discover different coaching methods and techniques. Come along to this workshop where we will explore techniques with other agile coaches. Come along with your favourite coaching models, references and tools to share and make room in your backpack to add some new things to take away. http://www.thekua.com/atwork

This tutorial will address three critical issues in software development today: 1. Building the Right Thing – How does the software development organization fit into the overall company and provide the capabilities that are most critical to the company’s success? 2. Leadership – A Product Manager is an outward facing role, while a Product Owner is an inward-facing role; can one person manage both roles? 3. Design Thinking – Dealing with complexity is the essence of software development; how does design thinking help manage complex environments?

Organizational silos are the source of the most pernicious dysfunctions you can find within any company. These divisions serve to isolate people in the organization within hyper-specialized roles. Ostensibly, we do this in order to help people succeed. The Justification might be that no one can be equally good at everything. Therefore, we compartmentalize our lives and those around us in order to filter out the extraneous noise. Of course, it does not have to be this way. You can deliver a product successfully without compartmentalizing everyone and everything in an organization within an inch of its life. It requires a different mindset. One needs inter-disciplinary thinking that considers different skills and tries to synthesize a whole rather than divide. This requires a mindset that favors skill over roles and knowledge over assignment. As teams, we need to have the proper balance of skills, including development, quality assurance, customers, and delivery. Moreover, as an organization, we need to have the people in place to help support the teams and the people on the teams to develop themselves and to deliver the best products. In this tutorial, we explore the causes of organizational silos, their impacts, and the strategies that you can employ to help mitigate their impact on your teams and within your organization. Contact details: Tom Perry: tperry@cybersource.com and Lourdes Vidueira: lvidueira@cybersource.com

Metrics, when they are used at all, serve organizations as a way to understand where project teams stand. When it comes to software development, however, these mechanisms can sometimes backfire. As adoption of lean/agile practices and methods becomes more prevalent, organizations struggle with finding the right measures to understand team adoption and progress. In this presentation we will show that what we measure (about teams or individuals) can cause sub-optimal behavior--by beginning the session with a paper-and-scissors snowflake manufacturing game. After comparing the results, and seeing in fact that we get what we measure, we'll move on to a discussion about software measurement. We will start by talking about why we measure and the fallacy of the "measure everything" mindset. Then we'll discuss the popular metrics used today and the pitfalls of using them. We will explain the powerful concept of challenging existing norms and empowering team members to define their own standard work. Finally, we'll close with a discussion on how to avoid the lean/agile treadmill by keeping things new and exciting. Part I: Why Measure? 45 minutes Snowflake Manufacturing Teams • break into groups of five, reserving one team to play the role of "client" • alternating teams get rigid process rules or self-organizing team rules • teams are given 5 minutes to produce as many snowflakes as possible • now teams take their snowflakes to market, and see if the "clients" will buy • group retrospective: we find out that only "beautiful" snowflakes sell, and we have a lot of waste! (beautiful is defined in the client instruction page) • shuffle teams, then iterate again, with a new objective: produce the most snowflakes that are also beautiful enough to sell Part II: What Measurements are Useful? 45 minutes Why We Measure • Quantify where we are and what we need • To share best practices • Benchmarking to determine the effect of change Popular metrics (and pitfalls) • Size of code/LOC (Line of code) • Code coverage • Unplanned feature Change • Schedule and Budget Compliance • Cycle Time • Velocity (story points or story count per sprint) • Defect count (at various phases) • Return on investment • Innovations per sprint / slack time • Artifacts generated • Function points Standard Work • Taiichi Ohno says standards should be challenged constantly • Let individuals/teams define standard work so that they feel ownership. Supporting Kaizen • Metrics are to be short-lived: set a goal, define a metric, make changes and gauge whether you're going in the right direction. Discard the metric once your goals are met. • Like statistics, all metrics lie--they are a limited view of the whole story, so don't take them too seriously. Use them as indicators for further investigation. • While metrics appeal to our logical/quantitative side, not all things can be measured--and some of the most important things are not measurable. Keep a view of the whole system, and value qualitative attributes of our work too! Part III: Beyond Metrics: Get What You Really Want (90 minutes) A Brief History of Management for Knowledge Workers As Peter Drucker says, the most difficult part of management is figuring out what our goals should be. Along the same vein, Russell Ackoff says "it's better to do the right thing wronger than the wrong thing righter." XP has taught us to take baby steps, to move iteratively so we can get feedback before we go too far in the wrong direction. The Lean Startup community has pushed this to yet another extreme by finding ways to get feedback before even building a product. How to Build What The Customer Wants • Validated Learning > Working Software > Comprehensive Documentation • Baby Steps > Big Steps • End-to-end > optimizing subsystems • Self-organization > binding objectives • Team Ownership of Product > Proxy Client / Product Owners • Soft-spokenness, modeling, and coaching > High-pressure management • Smaller teams > bigger teams • Simplicity > Complexity Focus and effectiveness • Team synch points • Managing energy instead of time • Product Road Maps The Lean/Agile Treadmill • Busy, busy, busy == never get anything important done • Slack creates disruptive change == creates value • Product success makes the product obsolete (c.f. Drucker: trains -> Ford's Model T -> GM) • The most value comes from our links to people / ideas outside our context (c.f. Block: social capital) • Are we going to sprint all iteration long? The Power of Positive Modeling • Growing your influence: applying Weinberg's Law of Raspberry Jam -- small meetings! • Idea farming: planting seeds and watch them grow • Peer Feedback • Keeping it Light • Making Work Fun / Playful • All this gives you teams that go above and beyond! http://dhondtsayitsagile.blogspot.com

In this hands-on workshop we aim to simulate product teams building software and delivering it into a market. You can continue to refine and upgrade your software throughout the session, releasing new versions and testing their performance in the market. Once your software is live it will begin to accrue points, as simulated users use the software and score it against how well it fits their needs. The earlier you release your software, the sooner you will start accruing points, and the earlier you can learn something about the market, which should inform your next iteration. In the lean startup movement, this is know as the Build-Measure-Learn cycle[6]. The aim of the workshop is to simulate product development in a quickly changing environment, where agile techniques should excel. How quickly can we iterate? What are the bottlenecks? Which techniques are most valuable? Do any fall by the wayside? Robert Chatley http://chatley.com http://develogical.com Matt Wynne http://blog.mattwynne.net/

Traceability provides an essential support for developing high quality software systems. Traceability, therefore, has been traditionally strongly infuenced by the software process drivers. However, the software process is, during the last few years, considering new drivers. One of them is value. The global value of a product can be understood as the perceived benets in relation to its cost. However, the technical and business stakeholders need a close interaction to consider each other in their product value management approaches, otherwise business decisions would not consider software engineering impacts and vice versa, development decisions would not take into account business value requirements. From the perspective of traceability, the value consideration may change many assumptions. Traceability items should contain the necessary information to estimate its value under a given context. Therefore the traditional traceability schemes seem to be too limited for describing and tracing the value. To start with, it would be necessary to understand the scope, delivery and implications of value tracing. Additionally, the agile community claims for a trustworthy transparency over tiresome traceability in order to get projects which are transparent and visible in their status/accounting. Then, these traceability approaches need to provide, what is called by some authors, lean traceability. Therefore, the VALSOT workshop's main objectives are: 1) to create a forum to discuss current approaches on software value-based traceability, 2) to state a research agenda based on the above topics, highly oriented to support industrial contexts.

There are terms used in the agile software world that have their origins in complexity science, terms such as self-organisation and emergence. The problem is that when these terms are used it isn’t always correctly. This session will open the doors to complexity science, using the Cynefin framework, and give you a way of making sense of problems and how they can be approached. Email: john.mcfadyen@jime.co.uk Web: http://www.jime.co.uk Twitter: @johnmcfadyen

Agile management is an often overlooked part of Agile. There is much information available for agile developers, testers, and project managers, but very little for development managers and team leaders. However, when organizations adopt agile software development, not only developers, testers, and project managers need to learn new practices. Development managers and team leaders must also learn a new approach to leading and managing agile organizations. Several studies indicate that “old-style” managers are the biggest obstacle in transitions to agile software development. Development managers and team leaders need to learn what their new role is in agile software development organizations. This workshop will help them. The same workshop was held for the first time at the Scrum Gathering in Amsterdam in November. It was the most popular session, with the most attendees, and excellent evaluations. Most of the workshop is based on the new book "Management 3.0", published in January 2011 in Mike Cohn's Signature Series. http://www.management30.com/book/

BDD is a set of practices which help software development teams to have conversations about the behavior of their system and how it delivers value to the project stakeholders. BDD has changed from its early roots as a replacement to TDD and now works as a mini-methodology across the whole software lifecycle. Over the last few years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world., In this tutorial we look at the original reasons behind the creation of BDD, bringing the focus back to the language and conversations which lie at its heart. We look at how BDD’s patterns can be applied at multiple scales – from the initial project vision all the way to the code – to deliberately discover and address ignorance in every aspect of software development, producing reliable, maintainable software that matters., , Attendees will learn:, , • The origins of BDD and the problems it solves, • Why ignorance is the constraint on your project, • Some frequently used conversational patterns, • How BDD can be applied from analysis to code, • How to use BDD tools effectively, • How to adopt BDD incrementally on a project, and which aspects are most important, • How to create a safe learning environment in which BDD can thrive

At the heart of agile and lean thinking is the idea of change for the better. One small improvement every day is another step towards continuous improvement. In many agile teams, retrospectives are the key enabling practice to continuous improvement yet it’s often difficult to understand what an effective retrospective feels like, and what elements teams should strive for., , This tutorial offers something for everyone to learn how to use retrospectives to foster a culture of continuous improvement. People new to agile methods will learn what retrospectives are, why they are so important and some of the key elements to how to make them successful. Experienced people will refine their understanding through our exploration of the key elements and widen their toolkit by two experienced and passionate retrospective facilitators., , More importantly this tutorial encourages the most effective learning by involving all participants in a series of exercises to experience what an effective retrospective might feel like., , Participants will come away having learned:, - The key elements of a retrospective, - The responsibilities of the facilitator, - A set of exercises to be used throughout a retrospective, - The pitfalls and remedies when retrospectives go wrong, , No prior experience is required to participate in this tutorial.http://www.thekua.com/atwork