Agile methodology in pure technical terms

Question

I often hear about agility processes, but it seems to me that it is (nearly) always tied to team organization and delivery processes. It (nearly, once again) never comes to the bottom of the bottle: the development itself.

Are there any agile methods which specifically target technical issues, like development methodologies, bug/error handling, practices and ideologies while coding ? Or is it that I fail to understand what Agile is all about while coding in a team ?

Answer 1

What you hear about is mostly Scrum. And Scrum doesn't deal with technical practices. And many consider that a failing of Scrum, as adoption of Scrum without adoption of proper technical practices results in "Flaccid-Scrum".

eXtreme Programming, which is much less known and adopted Agile practice, on the other hand does deal with technical practices great deal. Technical practices like automated testing, refactoring, pair programming and continuous deployment are at heart of XP. And XP believes it is those practices that allow fast, sustainable and predictable development.

Answer 2

Short answer

The agile manifesto defines 4 values and 12 principles. None of them is technical: it's only about mindset and team work. However, each value and principle has technical implications. These are embodied in various practices that were initially promoted by the one or the other agile method.

Longer answer

Without going into any specific methodology, agile processes are all iterative and incremental:

• Iterative is about the organisation of work, regardless of how it's done technically;
• Incremental is about the delivery of successive but complete subset of functionality. This implies refining the code.

General technical implications:

• Design has to be incremental. So, no huge detailed UML models upfront.
• Code shall be properly designed and robust for each increment and from the start. This excludes quick-and-dirty throw-away code (such as e.g. prototype to verify feasibility without intent to build upon its code base). Practices such as clean code, or refactoring or the use of version control systems support well incremental coding.
• Each increment should be accepted. This implies clear acceptance criteria in the requirements, as well as proper testing of each increment. Test Driven Development and automated testing (using frameworks such as jUnit for example) are two effective practices for that purpose.
• Developers shall work in sync, so that at the end of an iteration the increment is functional (i.e. no unfinished stuff). It's not clear to me if this is an organizational or a technical aspect.
• Frequent integration and builds are required (at least once for each increment, but more often in practice). Daily builds or continuous integration are two effective practices in this regard.

Iterative and incremental development processes requires of course input that enables increments to be well identified. This is usually achieved with user stories or use cases. User story mapping or use case 2.0 are effective practices that slice the requirements into implementable chunks.

You may object that some of the above mentioned practices are not necessarily bound to agile. And you'll be right: Agile is not about technical practices. But technical practices are required to enable agility.

Answer 3

A fundamental problem with software development is that the actual requirements for systems are, in the general instance, unclear and that worse that they change (for any number of reasons). There are cases where this is not true but they are the exception not the rule.

People don't know what they want (though they usually understand what problem they're trying to address/solve) and everyone often only learns about the gap between what they want and what they ask for when the product is delivered.

"Agile" approaches to software development aim to shorten the feedback loop by delivering little and often in order to be able to learn from the feedback and adapt the requirements to match. A lot of discussions in this area are around delivering value.

So agile is not really about the technology (the same is true of "Lean" manufacturing processes which have a lot in common). That said there are any number of technical practices that facilitate being agile regardless of methodology - things that make change manageable, that make it easy to deliver at a high cadence, and so on - so it is reasonable to want to talk about technical issues in an agile context.

One last thing that arises from aiming to be agile (or lean) is the value of communication and of developing people - scrum (for example) is, or at least can be, a means to facilitate communication between engineers and, done right, to expose issues that get in the way of delivery