Agile Junction
by Kirk Knoernschild
What makes a software developer agile? How about a software development team? And how do traditional techniques fit in the agile world? Agile Junction explores the practices of agile developers, agile teams, and the harmonious intersection of agility and the proven practices, principles, patterns, and paradigms of software development.
Get this RSS Feed -  - Subscribe to Agile Junction by Email
|
|
Written by Kirk Knoernschild
|
|
Thursday, 15 February 2007 |
|
Introduction
The Rational Unified Process (RUP) has become a defacto standard for
many organizations as they look to improve their software development
processes. Unfortunately, transitioning to RUP is an arduous and risky
process as teams struggle with adjusting to an iterative style of
development. As a witness to many process improvement efforts utilizing
RUP, I've found most are little more than reinventions of an
organization's existing practices. The result is a pseudo-iterative
style of development that favors excessive documentation manifest as
RUP artifacts, a predictive and plan-driven approach providing no clear
barometer to gauge success, and a tendency to revert to traditionally
flawed practices as teams succumb to the pressures of project
deadlines. Certainly, RUP should not be blamed for the failure, but
often times that's the case, casting a dark shadow on iterative
development and making teams ever more leary to consider agile
development.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Wednesday, 20 December 2006 |
Agile is iterative. But iterative isn't always agile. Increased agility is not a natural by-product of iterative development, and choosing an iterative evelopment process with high degrees of ceremony inhibit agility.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Thursday, 16 November 2006 |
Software architecture is difficult to define. Ask five different developers their definition of software architecture, and you'll likely get five different answers. Arguably though, we can agree that software architecture represents the significant technical decisions spanning the breadth of the system. For instance, managing the dependencies between modules is a significant aspect of software architecture. Developing application frameworks that promote consistency across use cases is architecturally significant. Identifying application layers and the behavioral granularity of those layers is architecturally significant, as well. As Booch so eloquently states:
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Tuesday, 31 October 2006 |
I believe the Unified Modeling Languages (UML) is a wonderful and powerful modeling language. The ability to create different types of diagrams representing multiple system perspectives offers numerous advantages. A picture is worth a thousand words, and an enormous amount of information can be conveyed on a single diagram or a complete model of a system, no doubt. But what for? What problem are you trying to solve? It's possible there are other, more effective techniques that address the problem. How does UML compare to other agile practices that address the same challenges of UML? Can UML be used in an agile way?
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Friday, 20 October 2006 |
I really don't care about Scrum. I really don't care about XP. I don't care about Agile RUP, or any other Agile process. But I do care about the agile practices embedded within these processes. I find little value in debating the advantages of XP over RUP. Of course, I've had the debate before, but mostly just to argue that it's not about the process, it's about the practice, the team and the culture. I don't care if you do Use Case Realizations. I care more about why you do them and what value they bring to your team. Agility is not a process, it is an ability. The ability to remain nimble and accommodate change. Why would we want to be anything but agile? Slow, brittle, and inept are certainly not defining characteristics of success. As in life, remaining agile requires care, attention, and nurturing.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Tuesday, 03 October 2006 |
|
I know, I'm already straying from the stated purpose of Agile Junction. But I simply cannot resist. I have to say it. THE ONLY ARTIFACT THAT MATTERS IS THE SOURCE CODE. The source code, including any dependent artifacts that the source code requires, is far and away the most important artifact. Without the source code, you cannot deliver the system. Any other artifact you produce should be aimed squarely at enabling you to create the highest quality source code possible.
Tags:
Click to add your tags...,
|
|
|
Written by Kirk Knoernschild
|
|
Tuesday, 19 September 2006 |
A sub-theme of Java Design: Objects, UML, and Process (aka. JOUP) was that of convergence. Back in 2002, there was quite a bit already written about Java development, object-oriented design, software process, and UML, but very little specifically addressing the area where these worlds meet. JOUP did that, showing how each worked together and generated value that was much greater than the sum of the individual parts.
Tags:
Click to add your tags...,
|
|
|
Blogs 
