The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?
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.
Software architects have the unique ability to provide leadership using skills gained in this role. Drawing on Kouzes and Posner's The Leadership Challenge, Patrick Bailey examines five practices that can be leveraged by the aspiring architect-as-leader.
The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.
One of the common misperceptions with agile software development is that agilists don't "do architecture." This completely ignores the 11th principle of the Agile Manifesto which states that the best architectures evolve over time. In this article Scott Ambler overviews an agile practice called "architecture envisioning" which enables you to gain the value from modeling without the cost of needless documentation.
Every system has an architecture, even systems developed using agile methodologies. Whether you attempt to define that architecture up front in detail or whether it emerges over time is up to you. My experience is that most agile teams follow a strategy somewhere between these two extremes. That strategy, combined with proving your architectural ideas as soon as possible through working code. This article summarizes a collection of strategies for addressing architectural concerns on agile projects and discusses how such strategies can be applied to scale agile methods to large development efforts.
Release management is an awesome responsibility that plays a vital role in the success of a software development project. Releasing is often considered to be an activity that happens near the end of the process—a necessary evil, perhaps, but no more.
Powerful new development technologies such as model-based code generation will overwhelm test teams that continue to create tests by hand. It's time for testers to put their own productivity into a higher gear. Harry Robinson tells you all about it in this column.
Testers are often on the critical path for getting a software release out. They must plan carefully in order to minimize the critical path, while still doing a complete job of testing. This schedule pressure is taken to an extreme when a production server must be taken offline in order to deploy the software, and everyone is waiting for the final test results before the system can go live again. Karen Johnson describes her company's carefully planned and orchestrated method for doing a final check of an installed system. Her story is relevant to e-commerce companies as well as IT shops that are under pressure to keep systems updated while minimizing downtime.