It’s hard to get through 2010 without stumbling across the term ‘agile’, which is being spilt everywhere. Like most bandwagonesque ideas, the exact meaning is by turns carelessly mislaid, blithely trampled on, or deliberately stolen.
The origins of “agile software development” goes right back to 2001, published in The Agile Manifesto. In theory, anything not referencing it is either wilful, ignorant, or indifferent. But language is organic; these things will happen.
The Wikipedia definition of agile software development accords with the Manifesto. And an example of the breakout process comes from Maureen Clarry of CONNECT: “Confusing Agile with a capital A and agility is a common mistake. Agile as a methodology is a small piece compared to organizational agility. Closely related to that, we sometimes see BI organizations that use Agile methodology as an excuse so that they don’t have to define standards or document anything. This is another example of trading speed and adaptability for standardization and reuse. It does not need to be an either/or proposition.”
Ouch. The battle lines are clearly drawn; it can’t be surprising to see it in the business intelligence arena.
This current discussion will look at the capital A, which has definition. As such, the Agile Manifesto is not for everyone. Up front, they say:
“we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”.
That’s not motherhood – and it’s obviously not universally applicable. Enterprise-level organisations will necessarily favour processes and tools, simply because they need good communication, integration between parts of the body to make it work –and grow – well. In that context, the Manifesto could be seen as permission for cancer to grow: it may be successful, but out of step with the rest of the body. On the other hand, it may be good for pilots where they don’t need tight integration with the body corporate.
The Agile Principles should be viewed in full here, but a short version could be summarised as:
- Highest priority: to satisfy the customer through early and continuous delivery
of valuable software. - Embrace changing requirements, even late in development.
- Deliver working software frequently.
- Business people and developers must work together daily.
- Build projects around motivated individuals, and resource them.
- Face-to-face meetings!
- Working software is the primary measure.
- Sustainable development: the ability to maintain a constant pace indefinitely.
- Continuous attention to good design.
- Simplicity: maximise the amount of work not done.
- Self-organising teams.
- Reflect as a team at regular intervals, on how to be more effective.
MIP, an Australian data management consultancy, are the ones who first brought MicroStrategy, Brio and Informatica to Australia. Recently they gave a presentation on Agility in its formal sense, in the context of presenting RED, a data warehouse development tool from a New Zealand company called WhereScape.
WhereScape RED has:
- automatic creation of surrogate keys, load timestamps, etc;
- code generation, execution, re-execution;
- a source repository;
- change management/ version control, including comparison tools;
- generated user and technical documentation, with auto commenting, diagrams, glossaries;
- prototyping facilities;
- notification of data issues (although it is not a data quality tool per se, it uses an error mart).
MIP presented WhereScape RED as inextricably linked to Agile development; a simpler IDE than Microsoft’s Visual Studio, and an intuitive ETL tool. It has been customer-quoted as a “perfect complement” to SQL Server technology (albeit I can’t say how well it fits in with other database technology).
What I saw did look good. It makes sense that it would suit an Agile development project. I noted one caveat at the time: that with such tools and methodology, it would be easy to lose the development thread in the process of rapid reiteration. A challenge, but not an insurmountable one, for the data professional.
Update 05-Aug-10: The Data Warehouse Institute’s World Conference has Agile as its theme. Some of the adjunct discussions can be seen to muddy the waters somewhat (is it a methodology? a process? a style? – depends on who’s talking, and how loose their language is). An earlier discussion – “Being” Agile vs. “Doing” Agile – is salient, especially the comments. One of the author’s own comments is worth repeating, that promoting Agile on the basis of speed specifically is “wrong-headed”:
“When speed is the primary objective, quality and value often suffer. But when the focus is on incremental value delivery (of high quality); increased productivity occurs naturally”.
To achieve :
- Sustainable development: the ability to maintain a constant pace indefinitely.
- Continuous attention to good design.
- Simplicity: maximise the amount of work not done.
… you need your tool to support a set of engineering processes such as:
- automated unit testing so you can embrace change without fear,
- a software refactoring ethos to pay back technical debt,
- test first design to keep the design simple and to guarentee the delivery of unit tests,
- source code control branching and continuous integration to release often at low cost and low risk,
etc…