Design has often been cut off from the development side of the house, creating static images that are then handed off to developers to build. Invariably, this waterfall approach leads to unhappy designers and frustrated programmers, and often a product that misses the mark. Agile Development has solved many of the issues, but in many cases, designers still sit on the outside.

We’ll look at integrating your design team (even if it’s a team of one) into an agile development organization while still pushing user-centric design. We’ll study successes and failures from both consultancies (InfoEther, Hyphenated People, Meticulous) and product companies both large and small (LivingSocial, CargoSense). We’ll talk about strategies for getting your design and development teams aligned and working like a well-oiled machine.

This session will discuss:

* Integrating design into an agile development team

* What processes work well

* What processes lead to problems

* Things to take back and try on their teams

Design has often been cut off from the development side of the house, creating static images that are then handed off to developers to build. Invariably, this waterfall approach leads to unhappy designers and frustrated programmers, and often a product that misses the mark. Agile Development has solved many of the issues, but in many cases, designers still sit on the outside.

We’ll look at integrating your design team (even if it’s a team of one) into an agile development organization while still pushing user-centric design. We’ll study successes and failures from both consultancies (InfoEther, Hyphenated People, Meticulous) and product companies both large and small (LivingSocial, CargoSense). We’ll talk about strategies for getting your design and development teams aligned and working like a well-oiled machine.

This session will discuss:

* Integrating design into an agile development team

* What processes work well

* What processes lead to problems

* Things to take back and try on their teams

Design has often been cut off from the development side of the house, creating static images that are then handed off to developers to build. Invariably, this waterfall approach leads to unhappy designers and frustrated programmers, and often a product that misses the mark. Agile Development has solved many of the issues, but in many cases, designers still sit on the outside.

We’ll look at integrating your design team (even if it’s a team of one) into an agile development organization while still pushing user-centric design. We’ll study successes and failures from both consultancies (InfoEther, Hyphenated People, Meticulous) and product companies both large and small (LivingSocial, CargoSense). We’ll talk about strategies for getting your design and development teams aligned and working like a well-oiled machine.

This session will discuss:

* Integrating design into an agile development team

* What processes work well

* What processes lead to problems

* Things to take back and try on their teams

01:14 - Jared Richardson Introduction

01:31 - Andy Hunt Introduction

02:35 - Background, The GROWS Method

16:51 - Getting Things Done

19:18 - Transitioning to GROWS

23:45 - Experiments

28:39 - Blind Spots

30:22 - Pain Points and Benefits

35:52 - Where do I start?

43:30 - Can you do GROWS on a small team?

50:25 - Working on Stage 2 before Stage 1 is Done

54:06 - The Growth of GROWS

Announcement

Picks

Dan Wilson: Regarding Ground Rules For Collaboration (Jaim)

02:54 - How do you know when a project has gone wrong?

07:52 - Setting Expectations

13:22 - Client Relationships and Improving Communication

17:16 - Horror Stories

35:37 - Rescuing a Project (After Things Have Gone Wrong…)

37:42 - Scope, Rescoping

Picks

Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers (Collins Business Essentials) by Geoffrey A. Moore (Philip)

02:20 - Components: Angular 1.0 => Angular 2.0

07:31 - Single Components; Multiple Templates

11:37 - Common Associations with an Angular 2.0 Component

15:35 - Directives

29:54 - Styling (Separating Components and Directives)

35:38 - Inline Templates vs Separate Templates

46:11 - Components; Controllers

Picks

Joe Eames: Directives 101  (Joe)

If you’d like to sponsor any of Chuck’s Remote Conferences, please email [email protected].

ng-conf is also looking for sponsors. Email [email protected].

Check out JS Remote Conf and submit a Ruby Remote Conf CFP!

02:26 - Refactoring (Definition) and Where People Fail

03:55 - Tests and Refactoring

10:59 - Managing Scope

11:42 - Why We Refactor; The Value of Refactoring

17:13 - Refactoring Tools

20:40 - When Refactoring Gets Put Off; Establishing a Code Culture

26:23 - Refactoring Strategies

37:38 - Performance Tradeoffs

41:42 - Generative Testing

50:33 - Measurement

53:08 - Examples and Resources

Picks

Longmire (Avdi)

There’s still time! Check out and get your JS Remote Conf tickets!

JavaScript Jabber Episode #184: Web Performance with Nik Molnar (Part 1)

02:04 - Nik Molnar Introduction

02:58 - RAIL (Response, Animation, Idle, Load)

06:03 - How do you know what is being kicked off? How do you avoid it?

08:15 - Frame Rates

16:05 - Scrolling

19:09 - The Web Animation API

21:40 - Animation Accessibility, Usability, and Speed

27:14 - HTTP and Optimization

35:25 - ES6 and Performance

40:46 - Understanding the Scale

43:30 RAIL (Response, Animation, Idle, Load) Cont’d

46:15 - Navigator.sendBeacon()

47:51 - Memory Management and Garbage Collection

Picks

Hardcore History Podcast (Jamison)

Hundreds of books are available to help you write Ruby source code and there are multiple large disciplines about how to structure the concepts within your code. But when you execute your code it ceases to be source and begins life as a unix process alongside other processes on a piece of hardware somewhere in the actual world.

I'll walk us through how to reason about your process, how to know what it's doing and what resources it's using and how to determine whether it's healthy.

We'll learn about what you can add to your source to make debugging easier, how to debug your code as if it were merely a C program, and what kinds of unique behaviors MRI, Rubinius, and JRuby have that are distinct from processes written in other languages.

Hundreds of books are available to help you write Ruby source code and there are multiple large disciplines about how to structure the concepts within your code. But when you execute your code it ceases to be source and begins life as a unix process alongside other processes on a piece of hardware somewhere in the actual world.

I'll walk us through how to reason about your process, how to know what it's doing and what resources it's using and how to determine whether it's healthy.

We'll learn about what you can add to your source to make debugging easier, how to debug your code as if it were merely a C program, and what kinds of unique behaviors MRI, Rubinius, and JRuby have that are distinct from processes written in other languages.