Tired of the claims that Scrum, XP, and kanban don’t scale beyond a few teams? Overwhelmed by management’s resistance to the organizational changes needed to really follow agile principles? Concerned with the lack of proven practices required to scale agile methods to the next level?

In order to be successful in the ring, a sumo wrestler needs to maintain a heavy body weight and at the same time be in peak physical condition. Just as these Japanese athletes have to find the right balance through a well thought-out combination of diet and training regimen, software development organizations need a balanced approach to implementing application architecture on agile projects.

Erik Petersen explains that face-to-face communications is the best method to prevent software defects. Bringing things out of the shadows into active discussion can raise the level of quality (particularly on large or distributed teams), without a bug report in sight.

Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. Because many code modules interact with external entities-things like databases, networks, file systems, third-party frameworks, and even the clock-these entities often cause us big-time trouble during unit testing. These entities can slow down our unit tests, produce unpredictable results, and have dangerous side effects. The best unit tests are decoupled from these external entities. Rather than try to control the entities, you can create mock objects to simulate their functionality. With a tangible example in the form of a short play, Rob Myers introduces mock objects and provides a brief history of their "relatives"-stubs and fakes. Then, with an animated, nearly-worst-case example, Rob presents code he developed to "mock out" nasty dependencies and create safe, predictable unit tests.