There are some situations where “agile” is the default mode...

Of course there are a lot of situations and places where agile approaches have become the default mode, and looking back at the history of software development with regard to iteratively-incemental approaches that is only a re-discovery anyway.

But in the big – a.k.a. Enterprise-Level – companies it’s mostly not the case. Or only in name but not in action.

Sometimes even “The Enterprise” goes into “agile”-mode

There is a situation when even Enterprise-Level software projects switch to an agile mindset. At least in most things but the name.

All of a sudden certain things start to happen:

• Business people re-prioritize on a regular basis (in short intervals even)
• Business people take the time to describe and verify the requirements
• Rollouts are allowed with very little overhead (sometomes called ‘hot-fixes’ in this context)
• Developers ask the people from whom the requirements actually came, what they want now
• etc.

Crisis-mode?

The situation I’m referring to is especially common for in-house-software that is developed for (and often in) large comapnies. Not all – only those projects that come into a crisis-mode phase at the end of the development phase.

I mean the time between the official end of the project and the time the software is actually in use. After the project has been declared finished, but before it is adopted for company wide use. When the last glitches are eliminated – which often takes up way more time than ‘planned’.
This crisis-mode is actually when everybody switches to things that work. And surprisingly these things are an interesting subset of what the agile manifesto mandates. (Of course I’m referring to the second page here)

Unfortunately some practices are not so important in crisis mode. Things like “sustainable pace” and “regular reflections” sometimes don’t seem so important in crisis-mode, but even the “continuous attention to technical excellence” is often more prevalent in crises-mode than in the day-to-day business during the run-time of the project.

So, here‘s an idea: If your enterprise shows the same crisis-mode behaviours, why not use this as a wedge to introduce more agile approaches?

’till next time
  Michael Mahlberg

Expensive Architecture Is No Architecture

Some musings on the value of architecture...
(This post is originally from 2007 but never has been published IIRC – and it's current as if i had written it today)

• Developers sometimes claim that “[this] architecture is to expensive”
• Recently several architects claimed that "[the] architecture has to be enforced because otherwise no one would pay the extra cost"
• It seems, that even some architects think that architecture leads to more cost than benefits
• From my point of view this attitude completely misses the point
• IMHO the "form follows function" mantra attributed to the Bauhaus is true for information systems as well
• An architecture that is motivated by the "right" goals it will pull more than its weight
• Architectural principles always should be a means to an end – and that end should b made explicit. They are meant to address real problems in systems development.
• The statement "It may be more expensive but it is what architecture demands" is a clear indication that either the scope of the observation is too narrow or – much more probable – the architecture is not an architecture but a bunch of rules far away from the real problems.

IMHO [as of 2015] the whole point of these musings is: If there is friction between development and architecture and the reason for this friction is that the architecture seems to be too expensive than that is an excellent opportunity to either re-evaluate the architecture (with real numbers and amounts and explicit assumptions) or to communicate the reasoning behind the architectural guidelines better.

And of course this is no one way road from architects to developers – it also sometimes pays off handsomely for development to make the incurred cost of architectural guidelines visible (of course also using real numbers and amounts and explicit assumptions)

So, how is your architecture? Does it pull it's weight?

’till next time
  Michael Mahlberg