Agile Semiotics

Own brand agile. What is in a name?

It is quite a few years ago (2000) when I first put some notes together on what was our methodology. It was at a time when the team I was working with were feeling around for a way of using agile that fitted them rather than them fitting into a defined agile process.

SemioticaNM evolved from Semiotica as a new web software engineering start up. With 5 founders, the newness, lack of hierarchy and rawness of the web gave us an opportunity to adopt agile principles quite fully in a short (2 year) time frame. Emerging technology in the form of applications available on Macs helped.


We all liked some aspects of XP but it was a bit like someone trying too hard to be cool. It was also very USA. But hold on, the book I had then just read Planning Extreme Programming was co-authored by a Brit. Martin Fowler may have appeared Americanised in those days but working in the north of England would keep us pure Limey.

So we took XP as a starter and invented some of our own terms. When I say ‘we’ it was actually one of us, not the coolest (that was Tom) but possible the smartest (Ollie), who came up with name equivalent, such as Tiger Traps to describe spikes and so on. Ollie had creative aspiration outside of programing and was given to a literary bent.


Now we had a set of our own names to match all of the XP methods. These names belonged to us. The next step was to set about making agile belong to us, or visa versa. Short iterations and frequent releases were as natural to us as eating breakfast. Release planning of short releases worked well and modularised code was a good side effect.

Stand Up

Daily stand ups were a sitting down, or net comms (we often worked remotely) thing. The thought of us all standing alone in front of our macs talking into a headset amuses but the important bit was to keep the meeting short. Instant messaging kept meetings short as it started as text only. When a year later iChat AV added voice the short meeting to kick off the day was established ritual.


Pairing worked through well, virtue of Hydra and Rendezvous (now known as SubEthaEdit and Bonjour), collaborative editing code was even better than two in front of the same screen. We also had the three core principles  (feedback, simplicity and welcoming change) of XP in place.


Frequent code reviews, walkthroughs and retrospections were most enjoyable and frequently accompanied rewards such as lunch from the chippy. They were a good opportunity for face to face, for remote workers a reward in itself. If the customer gave good feedback a visit to the pub followed the chippy.


The complex made simple was our company strapline. It evolved as a way of surviving, we took on a lot of jobs that encompassed complex processes. Many were ports to the web of installed applications running on LAN or WAN. These had a tendency to bloat and there was a lot of opportunity to YANGI. The network connections speeds available and the limited memory and processing power of servers encouraged simplicity and the frugal use of resources.

Welcome change

Embracing change came with some difficulty, feature creep and change were at first difficult to distinguish. Delivering working software early did give customers access to  small sets of functionality and refactoring or adding features as needs evolved made sense and removed much pain. It also encouraged a pragmatic approach based upon value which came with the the need for increased flexibility/


Unit testing, even any form of testing was not universally embraced but I pulled rank and insisted it be a universal. Programmers have a disdain of testing that needs a lot of coaxing to get over. Telling them good coders love testing and that it makes life so much easier helps as did another two books Testing Extreme Programming and Test Driven Development. Tools such as Junit and the ports for other languages eventually won the day.

We liked some of parts of TDD, specifically automated and programmatic testing of both code inputs and outputs and especially we likes the idea of having these automatically built into integrations. Unit tests alone missed some of the things out that testers wanted.

Workflows using version control (CVS and SNV) and build tools (ANT, MAVEN and Phing) could incorporate tests but did not qualify the quality of the tests. Selenium provided more opportunities to incorporate UAT’s (user acceptance tests). What we were seeking was automated testing and a dependable set of tests to automate.

Red to green lights were not enough and some tests should be thrown away. These are the tests that duplicate, the ones that use too many mocks, the ones with no assert’s and the ones that. The tests that should be kept are the ones that give confidence, document the code well and break problems down into manageable chunks.

Other brands



We kind of thought parts of Scrum were OK but it felt too much like a strange cult and not everyone fits into the strange cult way of thinking. All teams are different and the methodology needs to be relaxed enough to fit the team not the other way around.


We liked some bits of FDD, as features appeared like a good way of delivering bits of functionality that made sense to customers as well as geeks. A list of features is a really good place to start. We dropped the non agile bits of FDD.

We kept the feature bit, we kept unit testing but not at the exclusion of other tests, we kept the fact we were driven and that systems have to be designed. It gave us a loose, light yet useful and agile way of working. It was really good to enjoy making good software.


Lean with its less software biased methodology was a very useful source of agile principles. They could be wrapped around different aspects of producing software and formed a way of joining management and production. Too often seen as opposing drivers within many business. Agile should not anti the ‘m’ word. The manifesto states “Business people and developers must work together.”

Own Brand

The only thing I never liked about our own way of doing software development was the possible names that were possible. AFATDD suggests nothing and ‘Agile Feature And Test Driven Development’ and is not the best of sounding phrases on the ear. Agile Feature And Test Driven Application Design comes out as AFATDAD {AFatDad} which some say describes me but I am not sure if I like that very much or those who say it. So I named it after the bit we liked (agile) and after our company (Semiotica); Agile Semiotics (AS).

The process of understanding and capturing a requirement is of itself a semiotic endeavour as is the process of converting the resulting ‘requirement artifact’ into programmatic code: think of it as the understanding one form of language as another form of language.


 The AS Framework

Agile Semiotics is derived from other agile frameworks. From XP we took the short regular meeting, the stand up, we had them every morning and irreverently called them morning prayers. Later in the day we had evensong; again what they are called matters little.

A short, start to the day meeting around the “What are we going to achieve today? What will prevent us?” couplet is very useful. As is the later in the day couplet “What did we get done today? If it was not what we planned this morning why not?”. and to end the meeting “What are we going to do tomorrow?”

While TDD fitted well with FDD, and XP embraced it, with FDD it was never clear exactly where the testing process fitted in . Natural places to incorporate tests are; at the requirements, the engineering stage (where acceptance tests are another way of describing requirements) and at the build stage where User Acceptance Tests (UAT)  could be a part of continual integration procedure and running Unit Tests could be a condition of the build.

The problem however was that the lack of formal and/or natural testing stages within some frameworks left much to the individual’s interpretation and in some ways this appears contrary to a good project management process. For this reason we looked at placing testing at distinct points within the project life cycle and from TDD we took the notion of writing tests as early in the design process as we could.

Our testers at the time were a bit put out at having to join in at the fumbled foreplay stage: they wanted to start work from a set requirements doc, but as I kept telling them, a good test case is as good a description of the business case as you get. It may not be presented in a form that the customer is used to but at this point that does not matter, a good use case will fill that need.

From XP and other Scrum we took the idea of the story but reverse engineered it back to fit the label ‘Use Case’. We split Use Cases into two types business and technical.  The business use case is an informal description of a feature illustrated by a narrative, a story as in “make a list of products” .

The technical use case is where, while not being explicit about the how it was to be achieved, we referred to an example of how it might be achieved, e.g. “store product list in a RDMS”.

We believe that agile methodology should be as agile as, well the methodology itself, the methodology should be iterative. AS is the result of these thoughts. As a methodology it can be used throughout the whole development life cycle.  It can be used as a stand alone project management tool for; requirements engineering, for procuring Off The Shelf Software (OTS), for a new application build, for updates and change management and for regression management.

Agile principles are as well suited to enterprise solutions as to small quick application builds. It responds to the needs of changes within the team, it responds to the needs of the customer. Imagine you have customer where your subject matter expert is fluent in UML (such as the IT department) , sequence diagrams describing the exchange of messages accompanied by the class code are good for them.

The customer then involves another department (QA) that is fluent in data flows, activity diagrams are good for them. Sequence diagrams lend themselves to a narrative description of the mechanics of getting data from here to there; activity diagrams lend themselves to a narrative description of the structural results of getting data from here to there.

The value of describing process over describing relationships will depend on the audience. The methodology needs to respond to the customer and the needs of the developers, for instance pair programming may well work with some customers but be impossible to even commence with others – do you choose customers to suit the methodology or choose methodologies to suit the customer?

Equally you may have excellent developers who only speak only Klingon and a customer where the domain experts (accountancy?)  are totally fluent in Klingon, in such a case change the methodology from writing use cases to swapping charters.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s