Issue 29

Why Agile?

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works


“Real knowledge is to know the extent of one's ignorance.”




I have seen in my 15 years career as a developer, technical lead, project manager, freelancer, trainer, agile/lean/technical coach and again developer many failures of software development. I have also seen unexpected successes. 

From all industries, software development seems rather unpredictable. As a client, you can ask for a feature that looks simple and should take a day or two, (eg. Add Euro support to an accounting system designed for French Francs) and it takes two months. Or you can ask for a feature that looks awfully complex, and it takes one day. What should you expect? A 10 times budget increase for the feature set that you need, or to have the software earlier than expected?

More process

The initial human reaction to unpredictability is to add more check points, more process, more management. After all, factories can produce faster when they're better managed, optimized and automated. Why not software development?

I was working in an outsourcing company as a technical lead when the management decided to get a CMMI appraisal. CMMI, in case you're not familiar with it, is a maturity model for software development. Level 3, the one that this company was appraised for, is focused on having a standardized and measured process. Level 4 is about continuous improvement based on metrics.

Being involved in the process, I learned a lot about CMMI. CMMI is not bad at core, but its requirements can be interpreted poorly. A company could easily go bankrupt by interpreting the requirements ad litteram. The easy way out of a CMMI appraisal is to take each requirement and add a document for it. This would create so much work that either the production has to halt or the company has to hire more people just to write the documents.

Happily, the Quality Manager took a different route. She read the CMMI requirements and found the simplest ways to respond to them. To understand the context better, CMMI requires that you offer a proof for following certain practices, but it doesn't specify what kind of proof. The proof can be a document, but often it's enough to have a report from a tool, a photo or a checklist.

 The CMMI experience taught me two things:

  1. Having a structured way of work is beneficial for software development
  2. Checkpoints slow everything down

I was at this point a software developer interested in how to repeatedly execute successful projects. CMMI had some potential, but it could easily turn into a heavyweight maintenance nightmare that didn't ensure success.


At this time in my career, I was looking around for any type of knowledge that might help. How were other companies developing software? Are there fundamental principles that we could follow to create high quality software while keeping the customers happy? What are the ingredients for success?

I started by reading books and articles about the topic. 

Fred Brooks' seminal works “The Mythical Man Month” and “No silver bullet” opened my eyes to something I haven't acknowledged before: software development is different than other industries. After all, adding people to a construction project that is late will make the project end faster. Not so when developing software; adding more people to a software project that's already late will typically delay it even more (known as “Brooks' law”). 

More interesting, Brooks' law can sometimes be avoided. The reason the project is delivered later is that people joining the project need to learn what the project is about. But if they are picked so that they already have the knowledge, they might actually help instead of slowing everything down.

Steve McConnel's book “Software Estimation: Demystifying the Black Art” was yet another interesting read. The way I was doing estimates back then was basically guessing. CMMI had already exposed me to estimation methods, but the book offered more insight. The idea that we could take advantage of statistics and peer review to improve estimates was appealing and made sense from an engineering point of view.

On the other hand, software development seemed to have little to do with statistics. One of the things I've learned from my readings (I'm afraid I don't remember the source anymore) was that bugs were not distributed naturally throughout the code. My expectation was that bugs would evenly distribute in a codebase. Strangely, they aren't: they tend to cluster. This means that the areas where a bug is found should be more thoroughly checked for other bugs. But then the normal distribution doesn't apply to bugs in code; it's worth wondering: would it apply to estimates?

While the books and articles were very interesting, there wasn't much I could conclude about successful software development. What would help: more process, better estimation, more practices, better developers...? 

Nobody seemed to know.

It was at this point that I decided to move to a small product development company, to get involved in the Agile community in 7 Romanian cities and gradually turn to agile, lean and technical training and coaching.


… is unfortunately a very ambiguous, emotion-filled, marketing-bound term. Despite these challenges, I understood it as a set of principles, a set of practices and a list of potential benefits.

The benefits are on different levels:

  1. Business Agility – the ability to adapt fast as a company to the market and customer needs
  2. Development Agility – the ability to produce the feature the customer wants, faster than they need it
  3. Improved Productivity – by removing impediments, reducing the process, making developers feel better at work

The principles are stated in the Agile Manifesto; instead of quoting them, I will enumerate briefly my (certainly incomplete) interpretation:

The practices are the things most people think define Agile: daily meetings, retrospectives, continuous integration, Test Driven Development, to give only a few examples.

In my 5 years of training and coaching, I've learned about agile, lean and technical practices one thing that might come as a surprise.

Agility is More Important than Agile

Whenever a company wants to do an agile transition, the first question me and my colleagues from Mozaic Works ask is: “What do you hope to achieve with it?”. 

We get various answers to this question.  “We just heard agile is cool”, “our competitors are doing it”, “our customers asked us to do agile” are all answers that require more discussions. The best answer we're hoping for is “we need to improve X”, where X is typically: reduce release cycle, quality, productivity (based on clear criteria) or innovation. 

By defining a clear business purpose, we can then agree on the principles and introduce the practices that make sense for the company. Sometimes, they need full Scrum implementations, other times Kanban, while others just need to start with visual management and continuous improvement.

Being agile is not important; having Business Agility is a competitive advantage.

But why would agile work? How is it useful? This question led me to another interesting conclusion.

Software is Knowledge

I've learned this from a chat with Mike Beedle, one of the signatories of the Agile manifesto and co-author of one of the first books on Scrum. I felt like I've already come across this idea now and then, but that's when I finally got it.

A more accurate statement would be:

“Software is very precise, encoded knowledge”

Encoded, since it's written in computer code. Precise, because computers can't deal with ambiguity.

This simple statement has impact on every single aspect of software development. Here are some of the things I derived from it:

Why Agile?

To wrap this up: why agile? Well, because:

When isn't agile useful? There are situations, even in software development, when building knowledge doesn't play such an important role; for example customizations for existing software. There are business models that work and don't require agility; for example accountancy software. There are developers who are happier when they get the task and do it without making a lot of decisions; an agile environment will make them unhappy.

So, is agile the answer? I don't think so. We still have a long way to go to obtain predictability in software development. I believe though that one of two things can happen. The industry will either:

There's no telling yet which way we will go, but, to me, the second direction sounds very exciting and worth exploring.



  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects