Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Dr. Dobb's Agile Newsletter 08/08


In This Issue:

  • The Agile Adults Have Their Say
  • Book Review: Eating the IT Elephant
  • Hot Links

The Agile Adults Have Their Say

The Agile 2008 Conference was held in Toronto the first week of August and was attended by 1,600 people. The goal of the conference was for agile practitioners to share our first-hand experiences so that we could learn from one another. The conference clearly had a different feel to it than that of previous years: this was the first time that you could get a real sense that agile has truly crossed the chasm and is now mainstream. In many ways we've finally gone beyond the simplistic messages of Extreme Programming (XP) and Scrum and are now venturing into larger scale, more complex endeavors. This could clearly be seen in the plethora of "mature topics" covered by this year's speakers.

Most interesting for me were the talks around scaling issues, the kind of topics that I write about in my Disciplined Agile column, in particular how to work with large and/or distributed teams. Several people shared their experiences organizing large agile teams, describing the kind of divide-and-conquer strategies you would expect. Over the past few years the Dr. Dobb's Agile Adoption surveys have found that some organizations are applying agile approaches on teams of several hundred people and it was nice to hear confirmation at the conference. There were was also several talks describing distributed agile teams, even global ones, another issue teased out by the Dr. Dobb's surveys. A fundamental lesson when it comes to distributed teams, unfortunately one that is often ignored, is you're going to need to make significant investments to overcome the inherent communication risks. This not only means that you'll need to invest a bit more in documentation but also in flying people between sites -- you're always going to pay for travel, either explicitly or implicitly in greater levels of defects.

For developers there were several "non-coding" talks around usability, working with databases, and working with legacy systems. Usability, and user experience issues in general, is a critical topic that is often given short shift by developers. This is truly unfortunate because the user interface (UI) is the system to our users, so if we do a mediocre job of the UI then they're not going to be happy regardless of the quality of the business code. Database development is often minimized by developers, often because they mistakenly believe that if they're using an object-relational mapping (ORM) tool that they don't have to worry about database details. Needless to say I was very happy to see talks about database refactoring and database testing at this conference which explored the complexities of these topics. The conference also included an entire track focused on the issues surrounding legacy systems, also another topic given short shift by developers even though it's incredibly rare to find developers not working with legacy assets on a regular basis.

There were also several talks focused on modeling, in particular around sketching, initial requirements, initial modeling, paper prototyping, and agile architecture. This came as no surprise to me for two reasons. First, most of these speakers have been giving these talks at SD Best Practices for several years now. Second, Dr. Dobb's 2008 Modeling and Documentation survey found that agilists are just as likely to model and write documentation as traditionalists. This survey will be summarized in the November 2008 issue of DDJ.

The management-oriented talks explored some "mature issues" as well. There were several talks pertaining to metrics, echoing my experiences that you need to monitor a few simple ones to govern your projects effectively. There were a few product management talk as well, describing how to look past the single project point-of-view to a more robust product-oriented mindset. As far as I know nobody was burned at the stake, although "blatant heresy" was committed by several speakers who dared to talk about combining agile and the teachings of the Project Management Institute (PMI) or with the Capability Maturity Model Integrated (CMMI). Many organizations are in fact applying agile with PMI and CMMI and are doing so quite successfully. Naturally there were many talks on the "softer" management issues such as leadership, collaboration, and coaching.

Of course, the majority of the talks focused on the usual agile topics of quality, testing, and writing clean code. The agile community is clearly quality focused, although my fear is that there's more talk than actual action when it comes to complicated practices such as test-driven development (TDD). More on this in next month's update.

There were also a large number of talks around agile adoption, either in the form of strategies for doing so or actual real-world case studies. Large organizations such as Ericsson, IBM, Toyota, and several unnamed financial institutions and government agencies shared their experiences at applying agile techniques in practice.

I was very impressed by the Agile 2008 conference. The range, quality, and maturity of the presentations make it abundantly clear that Agile has crossed Moore's technology adoption chasm. The agile adults are finally wresting control mindshare the extreme adolescents, something that has been long in coming and will prove to be very healthy for the IT industry in the long run.

Book Review: Eating the IT Elephant

Eating the IT Elephant: Moving from Greenfield Development to Brownfield
Richard Hopkins and Kevin Jenkins
IBM Press, 2008
http://www.amazon.com/exec/obidos/ASIN/0137130120/ambysoftinc

For the sake of full disclosure I work for IBM and Eating the IT Elephant: Moving from Greenfield Development to Brownfield, by Richard Hopkins and Kevin Jenkins, is a book published by IBM Press, which is an imprint of Addison Wesley for which I've written books in the past. Having said that, I recommend this book to any senior IT professional whose goal is to find viable strategies for leveraging their existing systems and data sources. Most software development books assume that you are building a "greenfield system", one that is created from scratch which does not need to integrate with other existing systems. Yet this rarely seems to occur in practice. The authors introduce the term "brownfield system", one that leverages and often extends existing systems and other IT assets. As an aside, this is from the landscape architecture term brownfield site which refers to an existing construction project which takes an existing site which is considered unsuitable for human use, often a manufacturing property, and reworks it into something such as a park or apartment building.

The book is organized into two parts -- Part 1 which overviews the issues and strategies surrounding brownfield systems, and Part 2 which describes technical solutions for dealing with them effectively. Part 1, the more useful of the two in my opinion, starts with a discussion of why big projects fail and more importantly what to do about it. It then describes strategies for reducing the chaos within your IT endeavors, including the need to establish one version of the truth, to embrace complexity, to use your own language, to use what's around, to iteratively generate and refine what you build, and finally to bridge the business/IT gap. The most interesting concept presented was the idea of surveying the existing IT landscape to identify the existing assets and constraints upon your team, an important part of initial requirements and architecture envisioning.

Part 2 overviews existing technical strategies for building systems, including Model Driven Architecture (MDA), agile development approaches, and traditional development approaches. The authors describe how to combine and extend them to address the complexities of brownfield environments. Although the ideas are great I suspect that they are too difficult for most organizations because they require a level of discipline and maturity which are far too uncommon.

Hot Links

My June 2006 column Crossing the Chasm argues that agile software development techniques have clearly crossed Moore's technology adoption chasm.

My July 2008 column Agile and Large Teams describes how to scale agile teams to several hundred people in size.

My February 2008 newsletter Agile CMMI? summarizes results from Dr. Dobb's Process Framework adoption survey, revealing that many agile teams are in fact working within CMMI compliant environments.

Lean Development Governance, an IBM whitepaper that I co-wrote with Per Kroll, describes strategies for governing agile projects effectively. One of the practices is to organize your team around the architecture of your system.

My December 2007 column Scaling Test Driven Development describes how to enhance TDD with continuous independent testing.

My March 2008 column Scaling Scrum describes strategies for extending Scrum to meet the real-world needs most organizations face today.

My November 2007 column Governing Agile Software Development Projects describes strategies for governing agile projects and argues that it's significantly easier to govern agile projects than it is to govern traditional projects.

The article Architecture Envisioning: An Agile Best Practice describes how to go about initial architecture modeling on an agile project.

The article The Process of Database Refactoring shows how it proves quite easy to evolve the schema of an existing relational database, even when it is in production, thereby enabling data professionals to work in an agile manner.

The article Database Regression Testing describes the issues surrounding testing a relational database.

My Agility@Scale blog is here.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.