Any team attempting to become agile has two fundamental problems to deal with. They have to figure out how they are going to work differently, and they have to figure out how they will interface with their surrounding organization. Much has been written about the former, but not much has been written about the latter.
In this workshop, we will attempt to discover and classify the different organizational contexts that that agile can exist within. We’ll look at culture, competitive conditions, business type, and any other variable that we can discern. At the end of the workshop, we’ll present our findings and offer them up to the community as a basis for future exploration.
The world is full of ideas. Millions of ideas are given birth every day and millions are killed just as quickly, usually before they have had a chance to make a lasting effect on our world. But some ideas do “stick” as they say. What makes those ideas successful and how can I make my idea stick? That’s a question I believe many proponents of Agile methods have asked and would like an answer. I’ve created this workshop to help the participants find an answer.
Agile is a term often (but not always) associated with the term ‘project chemistry,’ or the positive team climate that can contribute to high performance. A qualitative study of personal experiences in development teams was therefore conducted to gain a better understanding how agile methods contribute to team motivation and cohesion. Presented research findings draw from social-identity theory, self-regulating team literature, and socio-psychological literature, and explain not only how, but WHY agile methodologies support teamwork and collective progress.
Angela Martin, RachelDavies, michaelfeathers, sallyann.freudenberg, stuartblair and JamesDavison
In “Mr Smith Goes to Washington” we follow the journey of an idealistic politician as he learns to deal with the political side of Washington. Likewise, agilists undertake a journey where we learn that it takes more than working software that meets business needs for software projects to truly succeed. As with polite after-dinner conversation we do not always discuss the taboo topics of “politics” and “religion” in the agile community. If we pretend that the political dimension does not exist on agile projects then we cannot develop and share practices that help us handle these situations. This panel brings industry professionals to share their perspectives and experiences, the audience should come prepared to both ask and answer questions.
Marc Evers and willem
If you want to see software teams and organisations differently, from a people/culture/behaviour perspective, come to this session! You can reinvent the wheel, but you don't have to - therefore we based this on session on Gerald Weinberg's cultural patterns.
There are many models and frameworks that focus on 'processes', they're about maturity, about what one ought to be doing in order to be effective. In this session, we'll present a fresh perspective on software organisations, a people oriented instead of process oriented view. The model focuses on subculture and people's behaviour.
Duncan Pierce and RachelDavies
Have you ever felt like you’re surrounding by a group of crazy people making insane decisions?
Sometimes we put this down to office politics, but that doesn’t actually help us deal with it.
In this session you’ll get a chance to learn about biases that affect the way people think. We’ll use this knowledge to develop an understanding of these difficult situations. Why did they occur? What can we do to prevent them happening again? And, given that we too are people, what can we do to improve our own decisions?
I spent a good part of my career thinking that Project Managers are either well meaning idiots or bad intentioned manipulators. All that went away, of course, when I started managing projects and I discovered that most Project Managers are - just like most developers - good people trying to do a hard job. This session will explore the causes of common conflicts between the “workers” and the “managers” on software projects. We will discover a generic pattern hidden behind these these conflicts and ways around them.