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:
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.
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.
Without good architecture, agile systems cannot stand up to the rigors of the process. You need to build the system so that it can accommodate constant change. Good architecture is not just stacking software Lego blocks on one another, it starts with the needs of your end users, then builds a system that satisfies and reflects those needs.
Allen is an internationally recognized software architect, specializing in agile object-oriented systems. His books on the subject (e.g. Holub on Patterns) are highly regarded, and he regularly speaks on architectural topics at international conferences.
We welcome programming projects of any complexity. Allen can do small projects on his own, or he can put together a team dedicated to your project. We specialize in web applications, with highly interactive browser-based front ends talking to efficient server-side back ends.
Your company's organizational structure reflects your existing processes. Otherwise, it couldn't support those processes. Change the process, and the organization has to change as well, from the executive level down.
Bringing Agile into an organization can be perilous without expert guidance, and Allen is perfectly positioned to provide that guidance. He's experienced working with both startups and established companies. He can teach every level the organization how to be effective.
He can provide initial training in Agile and provide executive-level transition coaching. He can guide the entire organization though the critical early-adoption period, when catastrophic failure is possible.
With Allen's help, you can hit the ground running, rather than wasting weeks flailing around with failed experiments, or even worse, instilling bad practice.
When it comes to Agile, training is necessary, but not sufficient. You need to build experience to be effective, and if you've never done the work, before, you need someone on site who can help: a mentor. Allen can mentor at every level. He can coach the executives through the transition. He can sit down with the programmers and help them work effectively.
Similarly, many organizations get off on the wrong foot with Agile, usually because of inadequate initial training (often by "certified Scrum" trainers). Allen can tune and expend your process to make it more effective.
Allen has worked in the software industry for 30 years, often as a leading-edge analyst and journalist. He excels at recognizing emerging trends.
A people hire A people. B people hire C people. Allen excels at identifying the A-levels, and can help you with every aspect of the hiring process.
The Chief Technical Officer (CTO) guides and supports a company's software-development culture. Except in small startups, he's not the “chief programmer”. Rather, he builds and maintains a high-functioning software organization, and assures the team develops software that's coherent, maintainable, of high quality, and agile.
An effective CTO needs a wide breadth of skills, and Allen has all of them. He coaches CTOs to make them more effective—and for the right company, can take on the job himself.