Home Articles
Agile Journal Articles
The Agile Journal publishes original content, articles and regular columns
from industry thought leaders, analysts and software providers on a
wide variety of topics related to agile development best practices and business adoption of agile ideas. Below you will find links directly to our columns
and articles or you may use the search box to scan for a particular
topic or writer.
Subscribe to the Agile Journal RSS Feed
|
|
Articles
|
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 a means of doing this
early in the product lifecycle and with continual review that provides the
creator with the ability to adapt quickly and effectively to changes is the
marketplace.
Tags:
Click to add your tags...,
|
|
Articles
|
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.
Tags:
Click to add your tags...,
|
|
Articles
|
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 specifications as the result of a "big design
up front" (BDUF) approach, many people think that we're not doing
architecture. Nothing can be further
from the truth, and in this article I overview an agile best practice called
"architecture envisioning" which enables you to gain the value from modeling
without the cost of needless documentation.
Tags:
Click to add your tags...,
|
|
Articles
|
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.
Tags:
Click to add your tags...,
|
|
Articles
|
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 determine current needs and enable emergent design.
Tags:
Click to add your tags...,
|
|
|
The Agile Manager
|
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 inaccurate. By
comparison, on Agile projects, QA staff are dedicated team members.
Testers are co-located with business and development staff. Because they collaborate with the development
team on formulating acceptance criteria, and engage in testing continuously
through development, QA feedback is timely and relevant. In the Agile approach, QA is less of an
encumbrance and more a partner in delivery, increasing the efficiency of the
software development process and the effectiveness of solutions produced.
Tags:
Click to add your tags...,
|
|
|
From the Editor
|
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.
Tags:
Click to add your tags...,
|
|
|
From the Editor
|
Agile teams require processes and tools throughout the lifecycle. This does not mean, however, that they must create these environments from scratch. Nor does it mean that the organization’s legacy processes and tools are irrelevant. Rather, as means to achieve short iterations, Agile teams should – selectively – leverage the organization’s software development investments as a means to jumpstart their projects.
Tags:
Click to add your tags...,
|
|
|
Articles
|
In the agile space the notion of the "well formed team" (WFT) has been discussed.[i][ii] The purpose of a WFT is to have a team thrive in a direction ideally set by business vision. Unfortunately, many teams are forced into survival by organizations that push work through the team matrix, forcing teams to establish themselves as dependencies. The purpose of this article is to firmly establish the notion of WFTs so that guidance patterns for their creation can help organizations to "thrive" instead of "survive." We establish this by shifting focus away from the notion of principles, values, and other heavy language commonly found in the talked about agile arena. Instead we focus on the power of a well connected group of humans working together to address complex product development or organizational needs. A mature WFT is treated as an indivisible unit, a self-organizing, learning engine of effectiveness, not merely a collection of individuals. Such teams rarely emerge by chance; a WFT is often intentionally formed with an understanding of the inherent value of such a team in mind. Agile provides pathways that can increase the chances of such a team forming. There are many pathways to a WFT. Our desire is to elevate the notion of a WFT as being the purpose of these agile pathways and the result of these pathways when applied with care. [iii] Real value from a WFT can be rapidly achieved with proper focus.
Tags:
Click to add your tags...,
|
|
|
Articles
|
Hello, my name is Maurice Sare. (my friends call me Mo). I am a first level tech lead/engineering manager at Gameonics, Inc, a multinational developer of distributed gaming for PCs and now, it seems, "smart phones." I've only been here a few weeks. Before that, I worked for a company that developed operating systems for smart phones, so I know something about the domain, but I've never worked at the applications layer, before. I run the graphics team here - a long way from that kernel stuff I had been working on. Gameonics has decided to adopt "agile methods across the enterprise" (whatever that is), which is predicted to affect all 1,000 developers over time (including testers, project managers, docs engineering support, etc.) over time. Because of the impact it has had on me, I have decided to share my experiences of a two-day "release planning event" that I just attended. Frankly, it has changed my view of Gameonics and its future, not to mention my understanding of agility.
Tags:
Click to add your tags...,
|
|
| << Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
| | Results 41 - 50 of 248 |
|
|
Latest Issues of Agile Journal
|