Keynotes

Tom Gilb What is missing from the conventional agile methods?

David Snowden will talk about a topic relevant to the Agile community.

Tom Gilb Master Class: Practical Extreme Project Management and Extreme Inspections

The Extreme methods need strong supplements in order to scale up and in order to keep better control of results and costs. Here are two new methods developed and tried out in practice by a master of the earlier less agile methods.

The tutorial is designed to hand over the practical tools so you can go back to work and implement the methods.

Part 1: Extreme Evolutionary Project Management (14:00 to 15:45):

• the 8 point defined XE process
• quantification of critical requirements
• matching designs quantitatively to the requirements
• tracking stepwise progress weekly towards quantified goals
• the XE Policy
• practical case experiences with the process, 'FIRM (Norway)' Web Survey Product, others.
• hints on selling the method to your organisation

Part 2: Extreme and Agile Inspection and Reviews (16:00 to 17:30):

• the quantified data that demand an agile approach to specification and code inspections
• the Agile Specification Quality Control Process Defined for a real IT Client in London
• initial quantified experiences with the method, large bank in London, others
• simple forms to drive the method
• hints on selling the idea to your organisation.

Dave Snowden Master Class: Gaining Acceptance for Change
(working from the perspective of the nut, not the sledgehammer)

People don't make rational decisions - its not he way the brain evolved. Instead they make first fit (not best fit) pattern matches with prior experience (either their own, or others conveyed through stories) and then retrospectively justify them as "rational". Because of this you either have to convey a new message in such a way that it "resonates" with an existing prior pattern of success, or disrupt those patterns so that people see things from a different perspective, with a disposition to act.

This workshop will draw on a decade of theoretical research and practical experiments to work with the reality of human decision making and will cover:

• Narrative based enquiry as an alternative to questions, interviews and expert interpretation.
• Sensing the patterns from narrative - themes, values, "archetypes" which move beyond persona based approaches to system design.
• Complex systems approaches to the forced evolution of systems - allowing applications to emerge from the interaction of objects with people and processes; avoiding end state design.
• Generating user needs and "resonance factors" bottom up, through the stimulation of informal cross silo networks to discover needs, rather than to allow them to be patterned by the analysts perspective.
• New approaches to project management based on the ideas of social complexity, which legitimize formal, rapid and agile design methods within boundaries.
• Gaining senior management acceptance to radical ideas.

Famous for Fifteen Minutes: Case Studies

Case studies of agile projects:

New Product Development at LogicaCMG using XP, Paul Grew (Logica CMG) and Sean Hanly (exoftware).
Bringing Agility to Traditional Product Management. An Ongoing Battle, Andy Mulhearn (Thomson)
Agile for Start-Ups, Sean Coughlan and Steve Quinlan (3Q Solutions).

Panel: Scaling up Agile. Are Domain Specific Languages the Answer?

A chaired debate on the following proposal, concluding with an audience vote.

Alan Cameron Wills:

How do you scale up XP? You turn a big project into several small ones. Just breaking it up into modules doesn’t do the trick – they have too many interdependencies, and the big composition isn’t agile. Instead, you make a language of your target business area, the domain, in which it’s easy to express and change the customer’s requirements; and you build a platform that implements the language, embodying the design patterns that work in that domain. That’s how SQL makes DB design 10 times easier than it used to be; how GUI editors have made huge changes to UI design in the past 15 years; and so on. The trick is to take the Language pattern, which has been so successful in these horizontal domains, and apply it to your local project.

Romilly Cocking:

MDA has severe limitations. There are other ways of improving developer productivity, portability and application quality. One such approach allows developers to use an extensible and expressive language which they can evolve into an executable domain-specific language. One great benefit of the expressive approach is that it prevents salespeople from trying "the visual conjuring trick".

John Nolan:

Scaling XP implies that a process that works for 12 people should work for 120 people. Not true. Humans are psychologically incapable of dealing with intimate processes beyond 12-15 people. However, can you get 120 people to work in an Extreme manner? Yes, but you must do it by working with the crowd and their individual behaviors. Extreme Crowds break the conventional rules of organization, which is the major limitation in "scaling XP". No tool, language or technique can solve a fundamentally human problem.

Automation: Begrudge Every Keystroke

Over the lifecycle of our project we have aggressively improved our software development process. We have a philosophy of continuously identifying bottlenecks in our development process and using automation to slash away productivity barriers. Upfront investment in the development proces can be costly, and for that reason can get left behind in favour of "real work". The presenters will show the iterative stages they have moved through , from a simplistic build to automated customer releases every half hour. Our experiences should demonstrate how to take the fast route to an agile automated process with minimimal pain.

Extreme Analysis: the Road to Business Value

A talk about a project where a team had already been sourced and implemented to deliver a solution before a set of requirements where actually available and defined to a level allowing the delivery to take place. The challenge was then for me to deliver the maximum Business Value in a given period of time and with a given budget. Describing the outcome of this project, both positive and negative, using qualitative and quantitative criteria for this purpose. Here, Business Value will be described in more details. This experience could be seen as an instance of a project that created Xtreme Business Value, in the sense that this value got discovered and produced using XP tools.

The Roots of Agility

One criticism raised with regard to agile methodologies is their scalability, or, better said, the areas of development projects to which they can successfully be applied. The continual search for a silver bullet has lead many to try a "one size fits all" approach here too. Using input from the domain of complexity theory, it becomes much easier to see where agile methodologies can be used, how soft techniques such as retrospectives and facilitation fit in, and (more importantly) why they do. This approach also provides an understandable explanation for many of the movements and theories underlying the agile solution domain, and provides new and refreshing insights into the goals of XP and agile software development, and the reason why it actually works.

The Agile Customer

This session shows how the Agile Customer fits in to the agile team. Most XP/Agile books start from the point where the stories are already known and don't tackle how we get to that point. This session aims to give an understanding of the consultation process that the onsite customer goes through with many business areas in order to collate the information and gain buy in to be able to write stories for development.

Recruiting For An Agile Team: Attracting Success

presentation will explore the important differences between successful agile recruitment and more traditional recruitment, using the metaphor of a collector - always looking, but not always buying (reflecting the high cost of getting it wrong). This can be contrasted starkly with the traditional "mail-order" style where the most important aspect is a skills match between the candidate and the role. We will also describe several techniques that we and others have used as part of the recruitment process to ensure that we are attracting and selecting the correct people for the team. These include the use of a strong practical component (paired programming or "day in the team") as well as exploring values with the candidate to assess how well he/she will adapt to the culture of the team. We believe that recruitment is as much about selling the team culture and the way we work to the candidate as it is about the candidate selling his/her skills to us.

An Introduction to Goldratt's Theory of Constraints

Goldratt’s Theory of Constraints is a close cousin of lean thinking and has powerful holistic problem solving tools for quickly finding and exploiting the leverage points within systems. These tools are helpful in understanding why agile software development works. This session will work through case studies to demonstrate some different TOC thinking tools.

XP Game

The XP Game is a playful way to familiarize the players with some of the more difficult concepts of the XP Planning Game, like velocity, story estimation, yesterday's weather and the cycle of life. Anyone can participate. The goal is to make development and business people work together, they both play both roles. It's especially useful when a company starts adopting XP. In real life Planning Game, development and business people are sitting on opposite sides of the table. Both participate, but in different roles. The XP Game makes the players switch between developer and customer roles, so that they understand each other's behaviour very well. Some of the concepts in the Planning Game are difficult to grasp, for developers and for customers. What exactly is the meaning and background of stories, iterations, consequent estimations, velocity, yesterday's weather, planning game, feedback? The XP Game is a simulation of the XP Planning Game, which includes the following phases: story estimation, story prioritization, planning, implementation and feedback. No knowledge of coding is required. This XP Game is a practical way to demonstrate how the rules of the XP Planning Game make up an environment in which it becomes possible to make predictable plans. After all, the easiest way to get a feeling for the way it works is to experience it.

Mind the Culture Gap

The IT landscape is changing, with offshore, multi-site and distributed development environments becoming more common, 75% of all IT companies will be doing some in 2003 (Gartner). Offshore outsourcing, primarily in 'less developed' countries offers a cost saving of 40-60% (Software Productivity Center ltd). Whether you agree with these proposed levels of savings or not, many companies are looking hard at moving some, or all of their IT capability to Offshore facilities. There are, as anyone who has worked in this environment will testify, substantial implications for software development as a 'co-operative game of invention & communication' . Not only do our lines of communication become 'thinner', but we also have to work with people who have a different business culture and language to ourselves. The purpose of this session is to explore how easily our preconceptions and cultural beliefs can become constraints to effective inter-cultural teamwork. You will be asked to challenge your own ideas of what is 'normal' and 'right' and consider them from another perspective. Through interaction and past experience, as a group, we will identify the areas where misunderstandings most commonly arise and discuss how theoretical approaches can be applied to overcome our own limiting belief systems. We all aim to practice 'good communication', we might need to be prepared to adapt what we think 'good' is.

Systems Thinking workshop

In our work as software development coaches,we have noticed that changing your software development method changes your organisation.We have run into questions like:why can't the customer keep up with the programming team and what can be done about it? How can we get a team to start unit testing?Is the lack of unit testing really the team ’s biggest problem?What are the underlying dynamics of adding people to a project and how can these be used to increase project velocity? We have found that systems thinking is a simple but powerful technique for finding answers to questions like these.It is a way of seeing organisations,projects,and teams as systems consisting of interrelated and interacting parts.Systems thinking focuses on relationships and on the whole, instead of focusing on the parts in isolation.It helps to identify self-reinforcing feedback loops and not-so-obvious cause-effect relations. The goal of this workshop is to apply and evaluate systems thinking as a methodology-independent tool for understanding and influencing the dynamics of software development projects,teams,and organisations.Participants will learn to apply systems thinking,and in particular the Diagram of Effects (or Causal Loop Diagrams)technique,to different situations in projects,teams,and organisations;they also have an opportunity to share experiences in a structured way. The workshop starts with a game to introduce the basics of systems thinking and causal loop diagrams.After the game,participants will be asked for ‘stories ’ from their experience that they would like to discuss.The audience is split in groups of 4 or 5.Each group will discuss and analyse a story and create a causal loop diagram for it.

Keynote

David Snowden will talk about a topic relevant to the Agile community.

Refactoring: keeping software malleable

Most software gets new requirements over time. The accumulated changes often stress the original design in unanticipated ways. When this happens, the software often gets more and more difficult to work with: development slows down, or more bugs appear. Sometimes it becomes so difficult to add new functionality or prevent new bugs creeping in that it seems easier to give up and rewrite the system from scratch. This can be avoided by refactoring. Refactoring breathes new life into code by changing the way it is written without changing what it does, keeping the code malleable and ready to accept change. It works in small, easy steps, and requires no big investment. This tutorial introduces and explains refactoring in a hands-on tutorial. After this tutorial, attendees will be able to refactor mercilessly to keep their code maintainable, ready for new functionality.

Refactoring Dysfunctional Teams

Agile software development relies on team members working effectively together. But what if the newly formed team doesn't work? Are there any early warning signs to look out for? And what corrective action can be taken? This hands-on workshop will explore some dysfunctional team behaviours, and the potential for making such teams "functional".

Agile Manager vs Project Manager

In the egroups we always have always the discussion if an agile project needs a project manager or in which way is a Scrum Master/Coach different than a project manager. Both roles are identical on the surface. The difference is the mindset of a Scrum Master or Agile Project Manager compared to an traditional project manager. This mindset leads to a different way of acting on a day to day basis. In this workshop we will work out with the attendees what differences and similarities do have both roles and in which way can we identify that we are acting agile or non agile.

Using Retrospectives to Channel Feedback

A retrospective is a meeting, in which a team to looks back on a past period of working together so that they can learn from their experience and apply lessons learned to future projects. Retrospectives can be used by teams to adapt their process to their specific project context during the project. This session presents lessons learned from running regular retrospectives with many teams using agile methods. Participants will have the opportunity to try several of the exercises adapted from Norman Kerth's book "Project Retrospectives".

Extreme Usability

As practitioners with an interest in both XP and usability, we believe that XP has certain properties that should facilitate usability. In particular, the iterative lifecycle and the increased emphasis on "soft" sciences such as psychology and sociology. However, we also recognise that its potential has not been met on many projects. There are many issues that have a real effect on XP practice, and will need to be addressed in coming years if usability is to become a core quality of XP projects; here are but a few examples: * Planning Game: Can a story on a 3x5 card capture sufficiently rich usability detail? * System Metaphor: This raises the more general issue of domain-driven design and cohesive models, an issue important to both XP and usability. How can we ensure these models are synchronised? * Test Driven Development: We can be confident the code is not broken at all times, but how do we know when usability has been broken? In a usability context, what happens to the assumption that tests are cheap? The objective if this session is to identify problems that XP poses for user-centered practice, and to explore solutions that might address these issues.

NLP for Software Development Coaches

As a developer your life is made easy. Great open source tools and IDEs make programming easier and fun. But what is in your toolbox as a Software Development Coach? What tools can you use to motivate your team to work test-first? What to do when people don't want to pair with each other? How to get the best out of a developer? Neuro Linguistic Programming (NLP) studies the structure of how people think and experience the world. It looks how successful people do what they are good in and models their behaviour. NLP contains numerous powerful models and techniques that are used by life coaches all over the world. We found out that a number of these techniques are also very useful for a Software Development Coach. During this session two NLP techniques will be explained and demonstrated. After the demonstration it is time for you to experience it your self and to play with it.

jBehave: Evolving Test-Driven Development

Test-Driven Development (TDD) is a core practice in eXtreme Programming. It emphasizes fast, incremental, requirements-driven development and the writing of unit tests before production code. One of the problems we frequently encounter with TDD is a tendency for developers to focus on testing their code, rather than using tests as a tool to drive the design of code. With this in mind, we introduce jBehave as a tool for developing simple solutions that are testable by virtue of their elegant design. jBehave helps developers take the focus away from testing and puts it firmly back on design. Programmers are forced to think clearly about an object’s roles, responsibilities and interactions, the key tenets of good OO design, whilst retaining the feedback of working code that TDD gives you. This is a practical session that will provide a hands-on introduction to jBehave. Used in conjunction with a "top-down design" approach, we will show how to construct well-designed, object-oriented software consisting of small, loosely-coupled objects with clearly defined roles, responsibilities and interactions.

Practices Make Perfect Pair Programming

Introducing XP practices into a non-XP development team can be a treacherous road to follow, yet the successful engagement of the team is key to the project's success. This workshop demonstrates a practical exercise introducing several of the XP techniques in a non-threatening manner. The key practice of the exercise is Pair Programming, although Testing, Simple Design and tool automation are also emphasized.

This workshop is aimed at:

• XP coaches or experienced XP developers looking for ways to enable non-XP teams
• Novice XP developers looking to learn the mechanics of XP development
• Anyone with a desire to be crowned XPDay 2004 Pair Programming Competition Champions! (A suitably tacky trophy will be awarded to the winning pair.)

Notes:
A laptop ready for rapid Java development (either Unix or Windows) is mandatory.
Source code will be available via CD or USB key on the day, or from http://www.corvine.org/xpday2004 one week prior to the workshop.
Try to arrange a pair programming partner prior to the workshop. Pairs will be formed from any remaining non-pairs at the workshop's commencement.

Around the World in 80 Standups

WDS have had three teams running an international agile project for six months in Seattle, Poole and Singapore. Every working day, they use internet video to run distributed stand-ups to hand over between the teams in different time zones. Starting with a case-study, Tim and Keith will present the background to their project and describe their experience of distributed agile development, including some retrospective data and video clips from the stand-ups. They will then open the session for discussion and sharing experiences.

Agile Deployment

Agile methods have helped reduce the time to code and build systems. However, a system isn't valuable to a customer until it's deployed. With a mixture of pair exercises, explanation and case studies, this session is an introduction to test-driven deployment and describes methods and tools for the testing of environments to aid the migration from development to operations.

Please note the organisers reserve the right to make changes to the programme and speakers, or to cancel sessions if enrolment criteria are not met or when conditions beyond our control prevail.