The mysterious case of the anti-Agile Scrum

The last two projects I have worked on as a Scrum Master and Agile Coach, had a common ground: they were fixed scope rewrites. Wait, rewrites? Fixed scope? Isn't that in exact contradiction with the manifesto?

We are uncovering better ways of developing software by doing it and helping others do it. Through this work 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 is, while there is value in the items on the right, we value the items on the left more. (http://agilemanifesto.org)

Why call yourself agile and follow some Scrum framework when your plan is set in stone?
Why call yourself agile when there are more layers inspecting the progress of the project than developers actually doing the work?
Why call yourself agile when the contract could not be clearer: "it should be exactly like the old version, no user should have to be re-trained"?

Well, that's a question I have to keep asking myself again and again. Not for keeping my sanity, but to be sure not to have the wrong expectations in the projects I work on and fight the wrong battles.

Fixed Scope

What does fixed scope means? At one extreme end, we have true waterfall projects, where the requirements are not only known but also understood (?!) and written down extensively. On the other hand we have projects with the old running (?!) software as requirements. And what follows in this case is a wild reverse engineering. Both types can include customer collaboration, but more often than not it's doesn't. The customer, relying on those artifacts, knowingly or unknowingly extracts him/herself from the picture.

The customer

What is the role of the customer in the first place?

Help you build the most important bits and pieces first. And this regardless of you being in an agile or waterfall context. In the later, the prioritization hopefully took place during the requirement engineering phase. In an agile context, the customer would react to external factors. The only advantage of agility in this case is to better adapt to unforeseen events which will invariably happen. What if you were, hypothetically of course, a bit late toward the end of the project? Let's be honest with ourselves, when did you last see a software project land exactly on time and on scope? Would you be able to push some of the features to a later release and deliver value to your customer now? Regardless of how much waterfall drives your project, if you are able to do this, aren't you at least a bit agile?

Continuous Delivery

From there derives a second factor: regardless of how much waterfall you follow, what does it take to go toward continuous delivery? If you are able to provide value to your customer regularly and at short intervals, even if those deliveries were planed month or years in advance, and furthermore if your customer is able to influence the scope of those deliveries at least a little bit, aren't you a bit agile?

Quality

Unfortunately, this is not the reason why projects like this try to go agile. They seek the quality boost. Regardless of the context, you can follow the XP principles and gain in "code quality". This goes without saying, it is so effective that this is one of the pillars on which I build my coaching. But then only iterations will bring your "product quality" further. The short cycles and focus toward "working software" doesn't enforce quality, but makes it "almost impossible" to ignore the quality of the software you produce and thus kind of forces you into a "pit of success". This is not a silver bullet, you can still mess up, but it sure helps. If you are paying attention to the quality of the software you produce and work with the idea in mind that it should be bug-free, and ready to be released regularly, aren't you a bit agile?

People

This kind of projects tend to be heavy on the processes and tools and could lack on the people side. But what if you could create a process that allows people to craft their own work universe where they are happy to see (most of) their colleagues in the morning? What if those people could "sprint" (in the Scrum sense) for years together and not get at each other's throats too often? If you keep the people in mind and losen up the processes wherever you can and get the teams and the management working together harmoniously, aren't you a bit agile?

Management

"Management", there I said the "M-word" that doesn't exist in an agile context... or does it? Of course it does. It takes a lot of different faces depending on the projects and companies, but there is always management involvement. In the projects I describe, the management tends to be rather heavyweight, controlling and oppressing.

Fixed scope and fixed timeline means you are running against the clock. Somehow, someone is going to want to control what you are doing and report further up the food chain if and when the goal will be met. This of course can only happen when the scope was clearly enough identified, weighted and clarified upfront. It requires also the scope to be "protected" during the whole life of the project. Add some scope-creep and your plans will be obsolete even before they meet reality.

Yes, the last step to make it a full fledged waterfall project is not big. But that is mostly due to the problem definition: rewriting an existing software.

What happens in the case of a reverse engineering or a fuzzy scope? Wouldn't it be a case where agility could shine? Yes, it would prove that it works best when the scope is changing. But no, it will invariably be a nightmare for project tracking since you will be eyeballing a moving target. And that's leaving aside the problem of understanding what your teams should be doing before they overtake you and face an empty backlog. Been there, done that.

If your scope is not correctly estimated and/or if you have no ability to escape the timeline-nightmare via successive releases, you are going for a world of pain management wise.

But what if you do? What if the management knew its place as an corporate band master, gave you some guidelines to satisfy some kind of reporting and then left its fingers away from the actual software production pipeline? Wouldn't you be a bit agile?

Rewrite?

I kept the most interesting question for the end: why do a rewrite in the first place? A re-think would be way better.

Yes but what would it take to really rethink a product inside of a company? It surely needs someone that understands the processes of the domain at hand well enough, to know what the vision of the software should be, while thinking outside the box not to produce the same processes again. How likely is this to happen for battleship grey applications that are so tailored to your needs that you don't know anymore if the software follows the processes or the other way around.

The exercise is screwed in its definition. Rethinking a product from the inside is a Sisyphus task, that's why it often takes someone to disrupt your environment from the outside to get out of this deadlock.

Hit & Run

In the cases I described, the companies themselves will never become agile. At best they will integrate some agility in their processes but never will they embrace agility as a living standard.

A lot of them will quickly die in the process of being disrupted. But some will hang on tight for a few more decades. And for those, would that be enough of a reason for them to leave off agility as a whole? I don't think so. There is still a lot to be gained from following some agile practices, at least in happiness for your staffs.

Here are the two questions I invariably try to answer during an interview, a project coaching or whatever interaction I have with a project of the like:

• You say you're doing a rewrite, but do you know enough about the scope of your project to satisfy management without putting a strain on the teams?
• When do you intend to provide value to your customers? What would it take for you to release value to your customers earlier than planned?

There are of course many more questions to ask, but if I hear the right answers to those questions, I know there is a seed of agility in this project I could probably work with...

Image Source: Doing some Sisyphus work by Kristina Alexanderson (CC BY-NC-ND 2.0)