Home  Home
Tackling Tough Topics: Architecture, Retrospectives, and Testing
Volume 3 Number 4 - April 2008
Some Agile practices are more
difficult to implement than others. This is particularly true in three areas:
testing, architecture, and retrospectives. All three of these topics are
essential for Agile development projects, yet teams' success varies. Teams are
well-aware of the need for testing early in the life cycle, yet frequently
struggle to elevate testing to the highest priority. Architecture is perhaps
the most controversial topic for Agile teams - Agile processes stress the emphasis
on lightweight requirements and design, yet acknowledge the need for robust
architectures on which to build flexible applications. Retrospectives often
fall into the "we know we can do better" category, where Agile teams conduct
these sessions but don't always take advantage of the benefits this forum can
provide. In this month's Agile Journal, our contributors explore these three
topics and share their experiences from successful projects.
Allan Kelly considers the many
reasons why Agile teams neglect retrospectives, and suggests some approaches
for feedback and knowledge transfer. Derek
Wade and Scott Barnes stress the value of emergent design and architecture, in
addition to emergent and iterative development. Scrum retrospectives offer teams
the ability to eliminate technical debt and focus on delivering business value
early in the life cycle. Hubert Smits
and Tamara Sulaiman share their experiences working with distributed teams in
the US and India, and how
retrospectives were effective in resolving issues and building team
cohesiveness.
Scott Ambler delves into the topic of
architecture - specifically, the practice of architectural envisioning - and the
ways in which Agile teams can benefit from modeling without suffering the
overhead of needless documentation. Pete Hodgkins promotes the concept of
"Tarchitecture" (technical architecture) covering not only software
architecture, but also physical and support architectures and how Agile collaboration and
continuous feedback help teams create better architected products.
Looking at the topic of testing, Ross
Pettit argues that the Quality Assurance (QA) organization can and must be
considered a value-added partner on an Agile team, and not an encumbrance to
the development process. Teams that leverage dedicated QA staff throughout the
entire life cycle will increase both their efficiency and effectiveness.
As we publish our 24th
issue of the Agile Journal, I regret to inform our readers that this is my last
issue as Editor in Chief. The demands of my consulting business have grown to
the point where I cannot manage both businesses. Beginning in May, Patrick
Egan, publisher of CMC Media (including the Agile Journal and CM Crossroads)
will take over as editor and continue to publish monthly issues. I would like
to thank our many readers for all their support, feedback, and fantastic
contributions over the past two years, and I know that the Agile Journal will
continue to be successful in the years to come.
Please continue to share your Agile
experiences in our forums, blogs, and article feedback. If you'd like to contribute an article on an
upcoming topic, go to the "Letters to the Editor" in the forum at agilejournal.com
and send us your ideas. Refer to the 2008 editorial calendar for future
themes.
Best of luck in all of your Agile
endeavors,
Liz Barnett
Editor in Chief
This email address is being protected from spam bots, you need Javascript enabled to view it
|
|
Sell Your Agile Successes
Agile
teams must be the champions of their own success. Self-promotion is not only
important to building credibility and management support, but it is also a key
component of compliance with corporate governance initiatives. By providing
transparency into projects' status, issues, and risks, Agile teams will deliver
value to IT and business partners and a vehicle for improving non-Agile teams'
management.
Read More >> |
|
|
|
|
Quality Assurance: Value Added Partner, Not Blunt Instrument
In many
IT organizations, Quality Assurance (QA) staff are not dedicated to projects,
but are "shared resources" supporting many projects
simultaneously. Vast armies of QA staff execute
defined scripts to test and certify an application once development is
complete. Because they lack application
familiarity and test only at the end of the development lifecycle, QA staff
require significant execution support, and the feedback they provide is late in
coming and often ...
Read More >> |
|
|
|
|
Emergent Design: Leveraging Agile Retrospectives to Evolve Your Architecture
Technological
debt is mistakenly thought of as a technical problem, but when system design
cannot change according to the needs of the business, it becomes a business
problem. Big Design Up-Front leads to
technological debt. Architecture must be
allowed to emerge according to the needs of the product and the business. We know iterative, emergent development
works; iterative, emergent design is no different. Agile teams should use Retrospectives as a
tool to determi...
Read More >> |
|
 | The Trouble With Retrospectives
Within
the Agile community retrospectives are widely seen as the mechanism for
promoting learning and change. But many
teams fail to hold retrospectives, or fail to act on the findings, thus they
fail to learn and improve. If we are
going to fix this we need to change our approach to retrospectives, and find
new ways to learn and create change....
Read More >> |
| |
|
|
 | Architectural Envisioning on Agile Projects
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. More importantly, when you observe
agile teams in action, you find that the majority of them do some initial
architecture modeling at the beginning of the project. But, perhaps because agilists are not
creating detailed architectural spec...
Read More >> |
| |
|
|
 | Retrospectives: A Case Study on Techniques for Incremental Improvement
In this article we
describe our work with teams that were spread between the US and India, and with the unavoidable
cultural difference. We used a facilitated retrospective to discover the most
challenging issues in the process and, just as important, to build a team and
increase trust between team members. In later work with the teams, we noticed
the immediate positive impacts on the people and the process....
Read More >> |
| |
|
|
 | Software Architecture Challenges and Significance in an Agile World
At the core of all software solutions are
underlying software architectures. The
architectures reflect initial assumptions about how products fit together,
which features are of value to customers, what are the expected integration
points, with which related technologies.
As software products find acceptance among customers, and technologies
continue to evolve, the creators (vendors) of these solutions eventually find the
need to adapt underlying architectures. Agile provides ...
Read More >> |
| |
|
|
| FEATURED BOOK |
 | FEATURED BOOK: Outside-in Software Development
A Practical Approach to Building Successful Stakeholder-based
Products, by Carl Kessler and John Sweitzer
Reviewed by Brad Appleton
Kessler
and Sweitzer's Outside-in
Software Development should resonate deeply with all those who
genuinely value the principle of customer collaboration in the Agile Manifesto,
and with anyone who has played the role of Product Manager for a software
project. This 2008 Jolt
award Finalist is not a book
about eliciting or prioritizing re...
Read More >> |
| |
|
|
|
|
Latest Issues of Agile Journal
Coming Up - Editorial Calendar
- April 08 - Tackling Tough Topics: Architecture,
Retrospectives, and Testing
- May 08 - Challenges with Distributed Agile
- June 08 - Tools for Successful Agile Projects
- July 08 - Best of the Agile Journal
See the full 2008 Editorial Calendar >
|
