What can others learn from how your team is organized and how it works?: 

Our goal for sharing what works for us is for others to learn and try techniques that we’ve vetted through years of trial and error, successes and failures. It’s difficult to enumerate all that’s emerged, but some highlights that come to mind include:

  • Why teams with co-located, dedicated designers work faster and are more innovative as compared to design being a floating resource or agency. We learn to speak each other’s language, and we even use our strengths and talents to provide systems and processes to keep us working most efficiently.

  • Why the “right” beneficiaries of user research on the team are the engineers and NOT just the designers or “stakeholders”.  Exluding engineers from research activities and conversations significantly decreases their value.

  • A set of tools and processes to facilitate design innovation. We’ve expanded Lean Startup methodologies past the product startup and into improving existing, mature products.

  • Why it's important to get all the right people in the room from the very beginning.  We're able to pre-validate many design possibilities by inviting other members of the organization (including customer support) to the collaborative design table.

  • How a truly Agile culture can thrive.  Holding true to the concepts of a cross-functional and self organized team (i.e. autonomy) truly does foster product innovation and the love of our jobs.

What is the composition of your team, and how was that composition determined?: 
Each scrum team consists of 3-4 engineers and 1 QA engineer, and shared across two teams are a Product Manager, UX Designer, Agile Coach and Engineering Director.  In addition to the dedicated team members, we have a support role to help the teams by facilitating user research activities as well as persona exercises, design studios, and other brainstorming activities.
Our company is growing fast, and we've applied a lean and iterative approach to our team structures and strategies.  In the end, it's important that we are mindful of our core belief that small, agile teams keep us focused. 
Please describe the manner and process by which your team collaborates over a typical iteration, feature, sprint, or any other unit of work.: 
Many champions of AgileUX advocate a concept of “Sprint 0”, where designers work ahead of the sprint to define and validate solutions up front.  We decided early on that this approach worked against the grain of our agile culture, as the end result is still a design handed down to engineers who have had little to no involvement in defining the solution.
Alternatively, we've embraced the basic concept of a "Sprint 0" but modified it so that the entire team participates.  The first full sprint of a major feature or product enhacement is focused on learning.  During this sprint, the team will talk to customers, build personas, participate in design studios, storymapping activities, and anything else we needed to do – collaboratively or independently – to define our first prototype.  By the 2nd sprint, a UX prototype is typically being tested in person with customers and prospects (observed by the entire team) while engineers begin coding and iterating on the feedback.  We eventually transition from UX prototype to working software, where ongoing testing is aimed at determining and validating the MVP we will release to all of our customers.
Upon the transition from UX prototype to working software, our designers are constantly pairing with developers on the final touches of the UI.  We've recently had great success holding "mob design" sessions, where the team gathers in a room and a high fidelity mockup is discussed and finalized collaboratively.
How has the fusion of design and engineering benefited your projects, products, services, and the company generally?: 
Our culture of collaboration fosters solutions that include ideas from every team member (including the introverts). Every idea, simple and complex, modest and grand, is put out on the table for discussion and the final decision is made by the team rather than an individual.
Our projects benefit because the process promotes clarity.  We have no need for detailed documentation because every member of the team is involved in proposing the solution from day one.  Our product benefits because our combined ideas always result in innovation, and those ideas are thoroughly vetted through user research that the entire team participates in. Our company benefits in this transparency by having teams that are empowered to make decisions without management stakeholders. We are our stakeholders, and as a result we genuinely enjoy working with each other and take great pride in building great products.
Please give one or more examples of successes your team has had that wouldn’t have been possible to achieve were design and engineering not tightly coupled.: 
Every other week our engineers participate in “Future Focused Friday”, where they are encouraged to work on anything they wish – on the backlog or off – towards improving our product. Twice a year our company also hosts 24-hour hack days. The inspiration for many projects during these events have been a direct result of observing usability tests and discovering opportunities ancillary to the actual feature or tasks being tested.
On a day-to-day basis, we are simply able to make decisions quickly without a lot of process and overhead. And, we are all aligned that if the decision cannot be made quickly, then we need to adjourn our meeting and start talking to customers.