Joined :
31 January 2012
Blogs :33
Tuesday, 09 February 2016
0/5 (0 votes)
When is it Not Agile - Part Three

A Bit More Background

To illustrate, let me tell a bit more about the circumstances of the project mentioned above.

  • This was to be a replacement system. All the existing functionality had to be preserved in the first release. There was to be innovation to enable easier extensibility, but this was mostly “under the covers”. (Later releases would add new functionality.)
  • There were to be some changes to the user interface, but these were being developed by a completely separate team, using traditional techniques of mock-ups, focus groups etc. The development team was to implement this predetermined user interface with perhaps only minor adjustments.
  • There were many non-negotiable and well documented business rules to be implemented. High product quality was essential.
  • The client wanted to see reduced costs of maintenance and enhancement going forward.
  • The client required a very firm estimate for this pre-specified functionality.

So this still left lots of room for agility. We would be prototyping iteratively all the time and we would have co-located subject matter experts to help us validate and refine important details. And we would be developing with small incremental sub-releases, with continuous integration – we would be applying all of the principles and techniques of Agile that would work within their project realities. And we would ignore those aspects of Agile that would lead to failure.

But of course, we would have to spend a certain amount of time confirming the architectures, identifying all the components that had to be in the first release and figuring out enough about them in order to develop a good estimate, and to map out our strategy of iterations/sub-releases, etc. And of course, we would have to work our architectures so the system would meet performance targets and be easy to maintain. And as we went along, a certain amount of documentation would be highly useful in later maintenance.

But one can imagine the protests, “We want to be Agile – and that isn’t Agile!”.

The client did come to appreciate why all these “non-Agile” things were important to them, and the project went forward.


I have yet to see a project team succeed or fail because of the label they “followed”. This statement also applies to Macroscope by the way.

I should clarify – in a role as coach or instructor – I never advise people to “follow Macroscope”; I encourage them to take advantage of it.

So once we are doing the work – why do we care what label is over our heads? Why don’t we just apply the best practices that fit our situation, without being a slave to one particular school of thought? To my mind, that’s what it means to work like a professional.

The real success factors in my experience lie in the intelligent use of core principles such as the Agile Manifesto as far as it goes, or the Fundamentals/Principles in Macroscope. (The Fundamentals for its Agile Solution Delivery process refer to and elaborate on the Manifesto.)

History teaches us over and over, that every project is unique. Accordingly, the very first Fundamental of Macroscope as a whole is “Adapt to your Context”.

I heard a great quote in my very first course in project management. “When the map and the terrain don’t agree, you should follow the terrain.” That doesn’t mean we should ignore the map completely, but we shouldn’t be a mindless slave to it.

As always I’d love to be challenged on anything you see here. And I’d be very interested in your own experiences.

1076 view(s)


+1 #1 Tom Handley 2016-02-24 19:41
My boss drew this to my attention:

It really fits with the theme of our posting here. As this author says, the minute you treat "Agile" (or anything comparable) as a "thing" with a proper noun you immediately reduce your agility. So as a result, she prefers to use the term "agile" - no capitals. Myself, I still prefer "agility".