How to save Agile?

My previous article raised quite a stir

and did get a lot of feedback, so thanks to every one that reacted. Some of those reactions were positive, some were not. But some of those made me realize that my message may not have been clear enough, so I will start by rephrasing it before moving on. When I say that Agile is failing, I mean that the current Agile hype will lead to a great hangover, the kind of hangover that could simply put Agile in the history books as yet another failed attempt to improve projects, next to RUP and others.

The signs are here: a lot of articles attempt to find the cause in non motivated developers, incompetent middle managers, hostile management, consultant selling scrum as the 21st century snake oil, locusts…

I mean, the end is nigh OK, but maybe not locusts. 

In any case, I do not buy into these; I am not saying they are false either, but they are missing the forest for the trees! In an era of continuous improvement, most organizations are able to address those issues. That is assuming they are in a position to identify them. Otherwise, they will just see that Agile fails and be done with it. Alternatively, they will tolerate Agile if the team can establish a road-map as well as an overall architecture design that can be reviewed and challenged. In the long run, this implies a slow death of Agile, turned into ‘Scrummerfall’.

I know that some of the radical agilists have said: we just need to beat them at their own game and be done with those who can’t adapt. This sounds both  cynical and naive as a vision. Economy does not exactly works this way, Agile methods are tools in the toolbox, nice, flexible and efficient, but they are tools!

So how to survive de fad phase?

By keeping on delivering, which implies fighting off pseudo agile, but also by augmenting agile methods so they can be actionable at a higher level.

With ‘plan based’ project methodologies, the plan is a strong steering tool to ensure the project matches the enterprise strategy, and tracking progress on the plan is sufficient to control that.

But agile methodologies starts with a set of goals and a scope, maybe a bunch of user stories, nothing really tractable at a higher level. And when the project starts, the ad hoc reporting format used is not appropriate for dissemination. At that, at a strategic level, the project is more or less opaque so not really controllable. The main, if not single, link between the project and the strategy is the product owner.

We need to make sure that actionable information can flow from the project to the strategic view. Vice versa, we need also to have a clear view of the enterprise strategy at the project level too, so that the team can position itself into this strategy.

Of course, for small/simple structure, this is probably the de facto situation, but for larger organisations, tools must be identified.

That being said, all contributions are welcomed, and I definitely think Impact Mapping shows us the way.


Why Agile is failing

Now that Agile is mainstream and that most, if not all, organizations are implementing agile methods, I hear more and more voices raising concerns and warning about how poorly those organizations perform afterward. Most often cited causes are management obstruction, poor discipline in the development team, local mutations of scrum and so on.

They are wrong, they got the root cause wrong plain and simple.

I let that notion sinks in.

At that time, you are probably suspicious, maybe a bit angry. But at least I got your attention and I can get to the message:

It is not the organizations that fail Agile, it is Agile that fails organizations. I guess that most agilists are just pissed off now, but please, keep reading. I am a convinced XP practitioner, and I feel sorry for the mess I see around me, I am just trying to do my bit. The problem is that Agile is not yet enterprise friendly:

#1 Having happy customers is not the main goal of any commercial enterprise

It’s main goal is generating value for its shareholders. Of course, having happy customers is the proper approach for that.

#2 Money does not flow directly from the customer to the project team

The typical structure will be that it will be the customer’s management that will pay the project team management. That represents a bunch of people that were not involved in the project, and who did not care about agile at all, as they were not involved in the project.

#3 Agile methods emphasis local objectives

Due to fast iterations, decisions are taken locally to the project without any interference from top management.

All those attributes make of Agile a sure path to project success, as measured in customer satisfaction. And it also generates stress by keeping the rest of the organization, especially top management at a safe distance from the project. Therefore, the organisation reacts by trying to control Agile, making sure projects stay aligned with the enterprise strategy; or it remains hostile, or simply fails to provide adequate support. And it just kills any benefits.

The good news is that it can change. Agile can change to register itself in the enterprise strategy. Gojko Adzic‘s Impact Mapping is a promising tool to integrate strategy and increase the relevance of projects by ensuring a shared and clear goal is established early on. On the other side of gap, Jurgen Appelo works on what he calls Management 3.0 aims at bringing Agile in the management world, completely transforming how team must be managed.

So, please read the work of those great guys, and raise your awareness about enterprise topics if you want to help Agile succeed.

And in the meantime, stay disciplined and keep up the good work.

The danger of microbenchmarking

Performance measurement is a hot topic

in IT, and it has always been so. How fast is the new hardware, which RDBMS has the highest TPS, which implementation has the lowest memory footprint…

Nowadays, pretty much anyone with a decent knowledge of a programming language can write some benchmark and publish his results, so benchmarks flourish everywhere.

Please read them with the colloquial grain of salt: measurement is hard and more often than not, the benchmark may include some bias favoring the author expectations. The bias will probably be accidental and of limited impact, but it will be there nonetheless.

But I wanted to discuss about microbenchmarking, with a focus on concurrency related ones.

Continue reading “The danger of microbenchmarking”

NFluent 0.5 is out

NFluent 0.5 is out

The beta version of nFluent as just been released on nuget by T.Pierrain. For those who may be wondering, nFluent aims at bringing to the C# ecosystem all the benefits provided by the FEST assertions library.

It supports english like test assertions and rely on auto-completion to guide developer into the writing of tests.

Plus it provides explicit error messages, making test driven fast and fun!

PS: for transparency, please note that I contribute to this initiative.

Multithreading and skillset

Is multithreading a complex subject that should be handled only by experts?

This is a fundamental question, that deserve proper care. If experts are mandatory, the problem is that they are hard to get by. Assuming you have enougth of those, we need to address the problem of code integration with non expert developers. Having the expert turning non multithreaded code to multithreaded one does not work; actually it can work at the algorithm level, but at the application level. And then, non experts can no longer modify the code.
The other way around would be having experts lay down some scaffolding code for the rest of the development force to fill in. It looks like a better approach because fix can be made by anyone, as long as it does not pertain to the scaffolding code.
Let’s go one step further and isolate scaffolding code from so called ‘business code’.
Et Voilà!, we have a nice framework. Which has been designed by experts from the ground up.
That is in essence my opinion: all developpers must be able to leverage multithreading. But like several others technical fields, such as databases, middlewares or 3D to name a few, we need to remove the burden from the mass of developpers.

The next question is then: how do we design such a framewok to be a pit of success.