It was a foregone conclusion
that Dovetail Software would come to call itself an agile developer:
you had only to know its nimble products to see that they must have
come from a group of engineers who were open to getting it right, and
who wanted to work towards this end, rather than coming from an
entrenched position of how things had to be.
Dovetail CRM
became, and remains, the leading means of integrating and extending the
Amdocs Clarify database throughout the legacy systems and new installs
of the modern enterprise. This happened only from the quality of the
product.
Process and product are indivisible. They say you
don’t want to watch the process of politics or sausage making, and
software development may run close to this sometimes too, but the fact
is that you know the tree by its fruit. Process and product are
indivisible, with each the perfect mirror of the other.
Exposing the processes by which Dovetail’s software is created has been held
to be an admirable thing, but it stems not so much from nobility as
from the overarching desire to get it right. All that matters is to
build the best for the customer. The greater the light of day the
process can be exposed to, the more chance for the perfect ideas to
fall into the mix.
Steven "Doc" List has been describing the
process of agile development in working detail in recent weeks,
offering a view into a high-tech shop that used only to be available in
retrospective books like “The Soul of a New Machine”.
The scale of sheer effort that it takes, even between willing and smart
professionals, to reach the perfect pitch of skill, is daunting:
“Yes, there’s pairing going on. It’s not consistent,
the changes of partners is sometimes-yes-sometimes-no, sometimes pairs
stay together for a full iteration or more, and I’m convinced that
we’re losing some of the learning-value of pairing in the process.
“My understanding – and belief – is that all members
of the team will benefit from more frequent changes of pairs. Knowledge
and skill will thereby get passed around, and the resulting increase in
quality and productivity will benefit all. I don’t see that happening
yet. So I asked for a discussion.” – Exploring ‘Done’ and Pairing
Enterprise architect Michael Hugos, whose sensible view of agile development we’ve quoted a time or two,
talks about the rigorous nature of agile development. He likens it to
training as an athlete. Agile makes you sore at first too, he says, but
you get better at it. Eventually comes the joy of skill. Before this of
course, come the excuses and the grumpiness.
“People want to be agile but they don’t like the
tight constraints that come with being agile. They offer all sorts of
reasons and excuses; they want more time to create quality software;
they want more time to do system testing; or they want more time to
investigate system requirements
“My response is to remind people that the constraints
are actually their friend, not their enemy. Accept the constraints and
use them to structure the development work; set project scope to make
best use of time available.” – Agile Is Not Easy
We see with Steven List’s development team at Dovetail Software that his experience concurs.
“My commitment to the team was that this week’s
meeting would stay well within the scheduled time. We finished in 1
hour 45 minutes. Close-out done, planning done, and had room for some
discussion in there. That’s well within our timebox (which was three
hours). It’s getting better. And shorter. The team was happier.” – Shrinking Iteration Close-out and Planning meetings
