Design and process are intimately connected. Not only do you have to design in a way that supports the process, but the process you use can change the design. Moreover, both design and process are full-team activities, involving the engineers, UI/UX experts, customers, product owners, testers, etc.

This 5-day intensive workshop not only brings you up to speed on agile theory and practice but also shows you how to design properly within that process. This workshop is for the whole team, not just the engineers.

The workshop combines the material from all three core classes. Two days of lecture and two days of hands-on get everybody up to speed on the process as quickly as possible. A fifth day is more engineering focused, but the other team members can benefit from seeing what the developers do as well.

We'll take a real-world problem, supplied by you, from inception through to code.

See component class descriptions for detail.

Next public session .   Sign Up!

Agile processes directly address the real world issues of constantly changing requirements, and the difficulty of producing truly useful software. Agile excels at getting high-quality code into the hands of your users quickly.

This seminar introduces you to practical agile development from the diverse perspectives of the entire team: programmers, product-development, UI/UX, testing, and management. The whole team should participate, not just the engineers.

There's more to Agile than Scrum. Scrum is a widely adopted subset of agile that provides one (of many) ways to plan. Planning, however, is a small—some would argue minor—part of agile development. More to the point, Scrum is primarily a management, not a practice, framework, so Scrum training typically teaches little about how to actually produce software in an agile way.

This class looks at the full panoply of agile-development techniques (including Scrum) without the rigid dogmatism often associated with Scrum training. It also introduces the parts of the design process that are performed collaboratively by the whole team.

The "user story" is central to agile development, and inadequate stories guarantee failure. Typical training curriculum, however, rarely covers the story creation process adequately.

Integrative Agile covers story-creation basics, but I've found that a lecture by itself is usually insufficient to learn how to create high-quality stories. What seems simple in lecture can be hard to implement. An intense couple of days developing stories leaves participants really knowing how to do it.

In this hands-on workshop, we start with a real-world problem, supplied by you, and develop high-quality full-blown stories that an agile development team can actually use. We create a problem statement, then derive stories from that problem statement. Along the way, we learn about CRC cards, use-case analysis, activity diagramming, and agile-focused UI/UX development.

Once we've created the stories, we'll then go through the Agile release-planning process: prioritizing the stories and creating a story board.

As with Integrative Agile, this whole team benefits from this workshop, not just the product-development people or the engineers.

This one-day add-on to Creating Effective User Stories takes the stories a step further, to the code itself. (We use UML rather than a specific language, so the class is language independent.) We talk about how to develop an object model that directly reflects the story structure—essential for code that must handle constantly changing requirements. Then, we develop that model until it’s ready to implement.

Once we have our architecture, we'll pick a high priority story and go through the iteration-planning process, constructing a task board. We won't have time to build, but it will be crystal clear how the build process would proceed.

Though this class is more engineering focused than the two prerequisites, the non-programmers can benefit by seeing how their work is actually applied.

When the transition to agile fails, it's almost always the fault of upper management. Your company is structured to support your existing process—when you change the process, you must change the way the organization works. Without those changes, the transition fails.

Organizations are agile, not individual departments or teams.

The more you know about agile, the better a job you can do, and sometimes the best way to come up to speed is a conversation, not a class. We discuss what agile actually is (hint: it's not Scrum), and develop a custom strategy for making the transition successful.

We can also help you put a dysfunctional (usually from poor Scrum training) agile shop back on track, and we can make a functional team even better.

A class gets you started, but nobody gets good at anything by just taking a class. Skill comes from doing. We provide hands-on team-level coaching services to make sure your team starts on the right track. We'll work closely with the team on a day to day basis over the course of one or more “iterations,” not only helping with process, but also helping develop an agile architecture and one-on-one programming work, as required.

Successful agile projects produce an architecture that stands up to the rigors of the process. You can't accommodate changing requirements or refactor effectively in a system not designed to accommodate those practices. This class shows how good (and bad) structure affects agility, and explores design principles that keep your design on track in an agile environment. We'll look, specifically, at:

• The SOLID principles: single-responsibility, open-closed, Liskov-substitution, dependency-inversion, and interface-segregation
• Accessor/mutator systems and their problems
• Agile UI-related architecture issues and alternatives to model/view/controller (presentation-abstraction-control, visual proxy)

We then look at the “Gang of Four” design patterns in depth. Design Patterns provide classes of solutions to common programming problems. Patterns, however, are usually presented in a catalog format that gives no feel for how the patterns apply in the real world, where the patterns interact in complex ways. This class discusses both good object oriented structure and the most-commonly used design patterns. We use in-depth analysis of real code that demonstrates how the patterns work in context. We also cover interface-based design and the make-up of a well-structured object and class hierarchy.

The extensive code examples are in Java, but should pose no problem to C++ or C# programmers.

Test Driven Development (TDD) uses acceptance tests derived from user stories to develop solid architecture while you program. That is, it's really a design activity, not a test activity—but it also produces high-quality acceptance tests. TDD, however, is also a programming practice, so you effectively design and develop simultaneously.

TDD is particularly important in agile because it produces a well-structured architecture without a heavyweight up-front design process.

TDD is one of the hardest agile practices to master. It requires extensive knowledge of good architecture (which is why the Agile Architecture class is a prerequisite) and a very disciplined approach to programming. In this two-day workshop, we start with a few well constructed stories and use TDD to turn them into functional code.

We offer a full range of Java classes. Our Java: An Intensive Introduction class covers the entire language, including generics and core libraries (threading, IO, etc.). We can add additional material to meet your needs.

Details here.

We offer a 3-day Introduction to C++. class that covers the core language and libraries. We can tailor the class based on your prior knowledge of C.