“They are resisting the changes I am trying to implement!” It’s a common refrain when people don’t embrace a change with the speed or enthusiasm desired. Do you keep pushing, give up or call in the big guns? How you respond to resistance can doom the change to failure, or boost the chance of success.
As coaches, we introduce new ideas in many different contexts. Relying on positional authority (our role as coach), or calling on outside authority (the managers who hired us) isn't likely to get those ideas a fair hearing.
In this talk, Mike will help you see resistance from a new perspective. By understanding how much influence you have, what forces are interacting around you and seeing different ways to re-frame your issues you can still get your message across without “inflicting help” on others.

This workshop shows how Test-Driven Development (TDD) is used to enable emergent design. Using a simple but representative example in Java, the presenter will demonstrate how a low-level design naturally emerges when using the TDD cycle of test/code/refactor. The audience will be involved by suggesting the next steps and also by pairing with the presenter.

Note that the goal of the session isn't necessarily to have a complete working example at the end, but to illustrate the process of low-level design through TDD.

If we examine traditional goal setting methods, like SMART, we see that we've been encouraged for over 30 years to make sure that our goals are Specific, Measurable, Achievable, Realistic and Time Based.  The theory being that if our goals meet these criteria, we will be more like to actually achieve them.  From there, we take the actions necessary, we measure, and ta-da! we achieve our goals.

Only, in a large number of cases, we don't quite get there. A few things can end up happening:  

1. We get tired of pursuing the goal and give up
2. We pursue the goal, but can't quite seem to achieve it, even though we know what we want and how to get it
3. We achieve the goal, but find that somehow, the results are not what we thought they would be

Examples abound both in our personal lives and in organizations.  We work hard to get a promotion, only to find that we aren't satisfied with the new role.  We commit to a healthy lifestyle, only to give up on it after a couple of weeks.  Organizations set goals for improvement, and don't achieve them, even though everyone did the right thing.

What if we are actually motivated by how we think achieving a goal will make us feel, rather than by the achievement itself?  So really, when we were working for that promotion, what we actually wanted was to feel powerful and capable (even if we weren't conscious of it).  We thought that the promotion would make us feel that way, but it didn't.

Human beings are uniquely motivated by feelings -- we do things that we think will make us feel good, and avoid things that we think will make us feel bad.

What does this have to do with agile development you ask?  Well, in my experience as a coach and a ScrumMaster, I've watched teams struggle to adopt agile practices (even though they seemed to really want to) and I've watched team members resist implementing practices that have obvious, undeniable benefits, and wondered what the barriers were.  The common thread in all of these teams seems to be the lack of understanding of how they want to feel on an agile team -- ultimately the "what's in it for me?" is missing for them.  It's like leaving the "so that" off of the user story.

It's not enough to just want to "be agile".  We have to know why we want to be agile, and specifically, what we as individuals will get out of an agile transition.

In this workshop, we will use user stories as a basis for setting goals, with a particular focus on using the "so that" to identify how we as team members, want to feel when work on an agile team.

I suffer from a (sometimes debilitating) condition called "I don't feel like it" syndrome.  I know what I need to do to, or what I should do, but I just don't feel like it.  So I don't do it.  The list of things I know I need to do but just don't do is long and varied, and ranges from things like tracking my spending, to exercise, to meal planning, to cleaning my house.  I understand why I should do these things, I'd like to reap the benefits of doing these things, and yet, fairly often, I choose not to do these things, because "I don't feel like it".  I'd rather drink wine.

Does that sound at all familiar?  If so, I think you'll enjoy this session.

I'll discuss what's behind the "I don't feel like it" syndrome, and how I've used agile practices to overcome it. I'll provide specific examples from my own life that can be generalized and used by anyone to get over "I don't feel like it" syndrome.  And you can still drink wine if you want to!

Culture is often stated as the top obstacle to transforming into an agile organisation.  This misunderstood obstacle can limit teams in reaching their full potential or even expel any hopes for meaningful change. During this session, we’ll explore ways to uncover the dominant culture of your organization, identify the contrasts with an agile culture and how to empower every individual to lead change initiatives.

Agile software development has drawn from a number of disciplines to come up with good practices that work well for so many teams.  At times, these practices may seem eclectic and arbitrary yet they work really well and we don't know why.  Or, we are trying to do something but our organization is "special" so we can't do it exactly like the book says.

This discussion will peel away the "software" from Agile and look at the principles behind the practices, where they come from, and give specific examples of how they work in other disciplines.  

When we focus on the principles, it becomes much easier to get the most out of the practices and tailor them for our "special" teams without loosing the benefit.