This post is, as the title suggests, about agile. More specifically it’s about a journey I made to rediscover what agile actually means to me. My need for rediscovery started while I was co-presenting a four-hour tutorial on Agile Testing at the TestNet autumn event recently. As one of my co-presenters was opening with an explanation of agile I felt the following smoldering unease creeping up inside of me.

“We’re talking about agile sure enough, but why is it I mostly hear Scrum, Lean and Kanban content passing by. How agile is that? And if it is not how bad is that?”

This post will therefore take you along the route I took to rediscover agile. It will contain some information on agile, and is a sort of personal recap. It is not intended as a complete and detailed overview of the agile approach and all of its derived methods and practices. Where ever I mention them however I will try to add a link to guide you to more information or interesting blogs. So feel free to use it, if nothing else, as your (re) introduction to agile if you like.

My original journey to agile started in 2007 and I will start once more at what was then my starting point. One of my colleagues came back from EuroSTAR 2007 and was enthusiastically talking about this new thing: Agile! I had heard about it before but had never really dug into it before. So like then I will go to where agile had taken off: the declaration of the Agile Manifesto in 2001. Seventeen people came together in a ski lodge and drew up a manifesto with the four following lines and guideline:

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.

This probably still is the best known part of agile there is. No self-respecting course will bypass these lines and not show them and declare them the essence of agile. Personally I think the manifesto, once read, makes sense to almost everybody who has been in IT for more than a couple of years. Their strength lies in stating something people sense but not always come to formulate themselves.

A lot of courses on agile do not go beyond this and do not also show the additional: “Principles behind the Agile Manifesto”. They jump straight to one of the methods and often enough without mentioning the principles at all. In my opinion this does not do justice to the manifesto as a whole. Therefore let’s have a look at these twelve principles. The seventeen authors of the manifest, who are also hardly ever mentioned, are part of the second part of this small series of post on agile. The third part will be on other prominent authors, like Lisa Crispin, and popular methodologies.

The Principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

As many of us have probably experienced, changes in requirements during development and even late in development is not new to software development. To accept and embrace these changes is certainly less common. This is one of the items that differentiates agile from other approaches. Other (more traditional) approaches either deny the existence of such possibilities, are unable to cope with them or try their utmost to abolish them.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

All software projects aim to deliver working software. The difference here is that agile projects aim to deliver more than once and to do so within a (far) shorter time span.

• Business people and developers must work together daily throughout the project.

Two elements in this principle provide direction into how business people and developers should work together. Those are to do it daily and to do it throughout the project. This combination I believe is typical to good software development in any approach. A lot of the other approaches have formalized so much however that to do so amounts in a breach of process, plan or protocol.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In management theories this concept has been around for decades. For some reason however the application of these theories seems not so common place in the software development world. In this respect this principle sets the right mindset in creating self steering, responsible and trusted teams.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is a radical break to what is, or I rather would hope, was considered standard in software development. Still a lot of developers, testers and even more so managers and stakeholders consider it impossible to do without upfront and approved documentation. “How else would you know what to do.” Reality is that documentation hardly ever completely describes what the customer wants. Let alone that it completely describes how to build it. I can personally not think of a faster way to retrieve or confirm information then by asking the informant directly. And if anything needs to be recorded you can do that while talking together, in the code or on paper later.

• Working software is the primary measure of progress.

There is beauty in this principles simplicity. As a tester however I think it’s a bit to simple. What does that mean “working software”? Does the code run, does it pass all checks or is it tested also and do the customers find the value in product that they were looking for. The intent of this principle is good, but it needs enhancement on the concept of what working means in your context and to whom.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I can only adhere to and promote this. I do realize however that it often is not on the mind of project managers. PM’s regularly still steer their projects on cost, time and scope using unfounded estimates that still have to be kept even when pushes personnel to their limits and over.

• Continuous attention to technical excellence and good design enhances agility.

I suppose this applies as an enhancement to all software development and therefore also to agile. If it actually enhances agility I am not so sure. The need for short sprints, iterations, cycles, or what you call them seems to work counterproductive here. (At least for the developers and architects I know.)

• Simplicity–the art of maximizing the amount of work not done–is essential.

In order to deliver the right content swiftly you should refrain from adding self thought up features or so-called enhancements. Unless the stakeholders or users are informed before and see them as adding additional value. Otherwise these items are likely to go in unnoticed, undocumented and untested. With all the risks that come with that. As to minimizing the work on agreed upon requirements I applaud the intent, but I think most developers start of to do their best and refactor when they see possibilities. In that sense it is wisely mentioned but if it really brings benefits in practice I have doubts about. (But I will get to this when I go into Lean later.)

• The best architectures, requirements, and designs emerge from self-organizing teams.

I totally agree with the idea behind this principle. Self-organizing teams are a good breeding ground for this. It should however not limit them to seek and accept expert input if this brings even better results.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The best way to handle your faults, or any experience, is to reflect and learn. This applies to teams as much as to individuals.

This concludes the first part in which I have travelled along the Manifesto and its twelve principles. I will continue (next week) with some info about the authors. Which is actually new to me as well, so that will be a journey into largely undiscovered country.