What's an architect? We can take it to mean a technical lead. By the book, we can call an architect the one who owns non-functional requirements and balances “-ilities” to meet service level agreements. Architects can be liaisons between business need and technological capability. The term architect is fuzzy at best. Adding ambiguity to the Agile notion of architect (embedded in teams, in the trenches) yields yet more ambiguity and ambiguity is anathema to value delivery.

It's time to stop the madness.

We need leaders that can get down and dirty with technology while mentoring and leading people while staying true to product vision. We need an embedded role in software teams like Toyota’s Chief Engineer: someone who brings skill and experience to bare in all areas of product development, product design, user experience, coaching, software craftsmanship, et. al.

Over the course of two days we'll engage in a diverse array of discussions, exercises, and summary talks aimed toward aspiring and existing technical leads, senior developers, coaches and architects. Participants will leave with actionable techniques and tools for leading their teams toward greater throughput and technical excellence.

Leading the Product

• Product Vision and Chartering
• Epics, MMFs, Stories
• Rolling Wave Planning
• Service-Level Agreements
• User Experience Fundamentals
• Designing as a Group: Diverge/Converge

Process Design

• Collaborative, Emergent DesignValue Stream Mapping
• Iterative/Incremental Development (Scrum/XP)
• Pull Systems and Kanban
• Grafting Kanban to eXtreme Programming
• Strategies for Continuos Improvement

Software Craftsmanship

• Behavior-Driven Development
• Pair Programming Patterns
• DDD: Developers working with experts
• Pairing with Testers, Designers and Analysts
• Modular/Composite Application Architectures
• Recovering from Technical Debt