When is it Not Agile - Part One

I was working with a Fujitsu/client project team recently as they were refining their approach to developing a replacement application. My role was to help everybody appreciate what was available in Macroscope that might be useful to them, especially regarding some of the bigger challenges in this particular project.

There were differences of opinion within the client team members about how much the approach should be driven by architectures, estimates and plans vs. a highly Agile approach. We had a good idea of the right balance ourselves, but of course needed client buy-in.

Continue reading
Tags:
  307 Hits
  0 Comment

When is it Not Agile - Part Two

Just what is “Agile”

There have of course been many great successes from taking a “big A” approach. The “sweet spot” scenarios involve the need for innovation and rapid creativity, where at the start there is an incomplete vision of the end product. (There have been failures too, but we won’t talk about those here.)

Now the astute Agile practitioner will have caught my deliberate error above. There is no such thing as a “by-the-book big A” approach. There are many books! When one reads about analysis of Agile use, it is usually in the form of “which of these .. are people using?”. Different people are using different aspects of Agile. And sometimes there are great debates between thought leaders about the superiority of some aspects over others – but somehow “it’s all Agile”.

Continue reading
Tags:
  294 Hits
  0 Comment

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.

Continue reading
Tags:
  271 Hits
  1 Comment

Agile and Macroscope

I have heard quite a few people compare Agile and Macroscope during a break, on the corner of a table, coffee in hand. It is not uncommon to hear things like "Macroscope is not Agile." Such a statement sometimes comes from a cursory glance at Macroscope, often from hearsay or, this is fair game, from a competitor. I'm afraid that such a summary diagnosis might be comparing apples and oranges.Let us first compare things of similar scope

First, Agile is not a method as such, but a family of approaches and methods mainly focused on the design and implementation of the software aspect of the system. It is the same for methods such as RAD (Rapid Application Development), XP (Extreme Programming) and other SCRUM-like approaches.

Macroscope is an integrated methodology framework covering multiple "domains of intervention" from defining a business vision (Vision domain), developing business capabilities and technology (Architecture domain), designing, operating and evolving information systems (Solution domain), managing projects (Project domain) and managing portfolios of Benefits Realization programs (Benefits domain).

Continue reading
Tags:
  1845 Hits
  1 Comment