Organizational and team culture is rooted in implicit assumptions about how individuals relate to one another in getting work done.  To foster alignment or change, it’s critical to have open and frank discussions about what we assume and what we value: this workshop will demonstrate how to have that conversation using LEGO Serious Play

“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.

In many Agile environments testing is either pushed to the end of a Sprint or is handled in a separate Sprint. This “mini-waterfall” approach to testing can be the root cause for a number of problems, including stress for the testers, delays in getting to Potentially Shippable Product Increment, missed testing, and team interruptions.

During this session we will look at 8 practical techniques that teams can try to help them deliver higher quality products. We will be using Jenga blocks as a tool to explore the techniques that can be used to improve quality.

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.

Collectively, User Experience (UX) practitioners offer many promises of improved user and customer experiences, so let's go "Get some UX" on our next project!  …If only it was that simple.

There are two important things to consider. First, UX is not a single profession, rather, a cluster of areas of expertise, so you need to identify which ones are best suited to solve your unique problems. Second, these areas of expertise each need to be integrated differently on projects to make the most of them.

We'll go through an exercise in exploring facets of UX that may be new to some. Then we'll look at common design challenges, and the facets of UX best positioned to address them, and how they optimally fit in the product development process.