3 Styles of agile (part 2)

In my last entry I set out what I call “3 Styles of Agile - Iterative, Incremental and Evolutionary.” In this entry I’d like to discuss the model as a whole.

Lest anyone start “my style is better than your style” I am at pains to point out that each style has merits. Regardless of whether any of us regards one style as superior, or one style as “wrong” the model describes what I find in companies and teams. I also believe you can use Scrum, XP or Kanban in any of the three styles.

That said, I confess, I see evolutionary as “superior” to iterative and I probably don’t do a very good job of hiding my preference. Rationally I must accept that each style has its own advantages and disadvantages depending on your context.

So how should one use the model? Or rather what does the model show?

Firstly (#1) the model is useful in naming the way a team is working and resolving conflicts. I frequently find that one group of people in the organization think Agile development means one style (e.g. Evolutionary) while another group thing it means another (e.g. Iterative). The result is a conflict with each group thinking the other is stupid and doesn’t understand.

This extends to much of the writing in books, blogs and elsewhere about agile. Sometimes the writer is implicitly assuming one style but their reader may be thinking another. In the extreme subscribers to one style will see the other as “Idealistic” or “Purist”, or contra wise: thinking someone “wants to do Waterfall” or “lacks flexibility.” One person’s “Pragmatic Agile” is anthers “Flawed Agile.”

Simply recognising the model and talking about it exposes assumptions and beliefs. It can also help to recognise that different teams within the same organization will work to different models.

The second (#2) use of the model is as a change model. Typically a team with a dysfunctional (or sub-functional) process and wanting one particular style, say, evolutionary, can enter at iterative and advance up in steps. It is fairly easy to see how a team working in iterative style could become incremental. (Of course a chaotic team finding itself in a controlling environment might make the opposite transition, from evolutionary to iterative.)

Thirdly (#3) - and already implied the last paragraph: organisations might rationally choose to adopt one style in preference to others. For example, for an organization which follows a strict budgeting process, operates in a slow paced market and has no intention of changing its management approach (e.g. a large insurance company) it is probably right to adopt an Iterative approach. Adopting evolutionary would just upset too much of the organization and possibly destabilise it.

One of the things I would like to understand - and something I should devote more time to is: understanding the forces which lead an organization to adopt one style over another. There are rational reasons for attempting to freeze out change (while achieving efficiency benefits) and there are rational reasons for embracing change (and sacrificing efficiency).

Now, while it sounds rational to say “A company can choose its Agile style” I don’t believe that is how it happens. Rather the style a company operates in has more to do with where they came from - what economists call path dependency.

Companies and teams seldom rationally choose the style they want. Rather their existing mental models and assumptions leads them to understand “agile” in one of the styles listed. As a result when they encounter engineers, consultants and books which assume a different style they a) ignore them, b) get confused or c) dismiss them as “idealistic” or “not in the real world.”

The net result is that it is more important than ever to name these things. Just naming them (#1) and recognising the styles for what they are is a great step forward. What you do next is a far deeper issue tied up with the wider organization.

3 Styles: Iterative, Incremental and Evolutionary Agile (part 1)

When I’m teaching training courses (as I was this week at Skills Matter) or advising clients on the requirements side of software development (which I’m doing a lot of just now) I talk about model I call “3 Styles of Agile”. Incredibly I’ve never blogged about this - although the model is hidden inside a couple of articles over the years.

So now the day has come… I don’t claim the “3 Styles model” is the way it should be, I only claim it is the way I find the world.

While “doing agile” on the code side of software development always comes back to the same things (stand-up meetings, test/behaviour driven development, code review/pair programming, stories, boards, etc.) the requirements side is very very variable. The advice that is given is very variable and the degree to which that advice is compatible with corporate structures and working is very variable.

However I find three reoccurring styles in which the requirements side operates and interfaces to development. I call these styles: Iterative, Incremental and Evolutionary, and I usually draw this diagram:


I say style because I’m looking for a neutral word. I think you can use Scrum, XP and Kanban (or any other method) in any of the three styles. That said, I believe Kanban is a better fit for evolutionary while Scrum/XP are a better fit for Iterative and Incremental.

I try not to be judgemental, I know a lot of agile folk will see Evolutionary as superior, they may even consider Evolutionary to be the only True Agile but actually I don’t think that is always the case. There are times when the other styles are “right.”

Let me describe the three styles:

Iterative

In this style the development team are doing lots of good stuff like: stand up meetings, planning meetings, short iterations or Kanban flow, test driven development, code review, refactoring, continuous integration and so on. I say they are doing it might be better to say “I hope they are doing” because quite often some bit or other is missing. Thats not important for this model. The key thing is the dev team are doing it!

In this model requirements are arrive in a requirements document on mass. In fact, the rest of the organization carries on as if nothing has changed, indeed this may be what the organization wants. In this model you hear people say things like “Agile is a delivery mechanism” and “Agile is for developers”.

The requirement document may even have been written by a consultant or analyst who is now gone. The document is “thrown over the fence” to another analyst or project manager who is expected to deliver everything (scope, features) within some fixed time frame for some budget. Delivery is most likely one “big bang” at the end of the project (when the team may be dissolved.)

In order to do this they use a bacon slicer. I’ve written about this before and called it Salami Agile. The requirements document exists and the job of the “Product Owner” is to slice off small pieces for the team to do every iteration.

The development team is insulated from the rest of the organization. There is probably still a change review board and any increase scope is seen as a problem.

I call this iterative because the team is iterating but thats about it. This is the natural style of large corporations, companies with annual budgets, senior managers who don’t understand IT and in particular banks.

Incremental

This style is mostly the same as Iterative, it looks similar to start with. The team are still (hopefully) doing good stuff and iterating. There is still a big requirements document, the organization still expects it all delivered and it is still being salami sliced.

However in this model the team are delivering the software to customers. At a very lest they are demonstrating the software and listening to feedback. More likely they are deploying the software and (potential) users can start using it today.

As a result the customer/users give feedback about what they want in the software. Sometimes this is extra features and functionality (scope creep!) and sometimes it is about removing things that were requested (scope retreat!). The “project” is still done in the traditional sense of everything in the document is “done” but now some things are crossed out rather than ticked. Plus some additional stuff might be done over and above the requirements document.

I call this incremental because the customers/users/stakeholders are seeing the thing grow in increments - and hopefully early value is being delivered.

I actually believe this is the most common style of software development - whether that work is called agile, waterfall or anything else. However in some environments this is seen as wrong, wrong because the upfront requirements are “wrong” or because multiple deliveries need to be made, or because the team are’t delivering everything they were originally asked to deliver.

Evolutionary

Here again the development team are iterating much as before. However this time there is no requirements document. Work has begun with just an idea. Ideally I would want to see a goal, an objective, an aim, which will guide work and help inform what should be done - and this goal should be stated in a single sentence, a paragraph at most. But sometimes even this is missing, for better or worse.

In this model the requirements guy and developers both start at the beginning. They brainstorm some ideas and select something to do. While Mr Requirements runs off talk to customers and stakeholders about what the problem is and what is needed the tech team (maybe just 1 person) get started on the best idea so far.

Sometime soon (2 weeks tops) they get back together. Mr Requirements talks about what he has found and the developers demonstrate what they have built. They talk some more and decide what to do next.

With that done the developers gets on with building and Mr Requirements gets on his bike again, he shows what has been built and talks to people - some people again and some new people. As soon as possible the team start to push software out to users and customers to use. This delivers value and provides feedback.

And so it goes. It finishes, if it finishes, when the goal is met to the organization decided to use its resources somewhere else.

Evolutionary style is most at home in Palo Alto, Mountain View and anywhere else that start-ups are the norm. Evolutionary is actually a lot more common than is recognised but it is called maintenance or “bug fixing” and seen as something that shouldn’t exist.

Having set out the three styles I’ll leave discussion of how to use the model and why you might use each style to another entry. If you want to know more about each model and how I see Agile as spectrum have a look my 2011 “The Agile Spectrum” from ACCU Overload or the recently revised (expanded but unfinished) version by the same title: “Agile Spectrum” (the 2013 version I suppose, online only).

Events! - Speaking and training

With the impromptu Quality mini-series out of the way normal blog-service will now be resumed!
First up a bit of self-publicity! I’ve got a busy few months coming up and I thought I’d post a list of the events and public training courses I’m giving…

• Skills Matter In the Brain, “Xanpan - not a methodology, a personal take on Agile”, London, 16 September 2013, this is a free evening (6.30pm event) - registration required at Skills Matter site - THATS THIS MONDAY
• Skills Matter, Essential Agile for Business Analysts, this is a 3-day course at Skills Matter in London, 16-18 September (booking essential - with Skills Matter). Its called “for Business Analysis” but anyone concerned with the requirements side will benefit. I’m also thinking of renaming it and tweaking to to “Agile for Business Analysts and Project Managers”
• IIBA Business Analysis Conference, 23-25 September, 2013, “Patterns and Pattern Thinking for Analysis and Innovation - when I’m not preaching about agile, or wishing I’m an Economist, I’m a patterns guy, its my dirty little secret
• Agile Cambridge conference: "Requirements: Whose job are they anyway?" - 25-27 September 2013
• Program Utvikling, Kanban Software Development 101, Oslo, 21-22 October 2013: A semi-new 2-day course, some tried and tester material bundled into a new format and focused on Kanban
• Agile Tour London, "Xanpan (What do you get if you cross XP with Kanban?)”, London mini-conference, 1 November 2013, a chance to hear me outline Xanpan (and save on reading the book)

Looking further ahead, I’m taking on a challenge by speaking to the BCS PROMS-G group (thats the project management group) on "The End Of Projects - and what happens next" (5 February 2014) free, register with the BCS.

Still banging on about Quality

The last couple of blog entires have been a public investigation - personal think - about software quality - see What is Software Quality? and Software quality? Thanks to all those who have provided feedback and comments, they’ve all contributed to my thought process.

I think I am moving towards some kind of conclusion. I’ll write up that conclusion for Xanpan and post it elsewhere too. Right now I’d like to add some more thoughts and hint at the conclusion.

I’m starting to think it is easier to talk about how to achieve high quality and about the benefits of quality than it is to actually define quality itself. Without actually defining what quality is or what the benefits of quality are then talk of how to achieve it is unlikely to be more than opinion.

I think that defining quality is one thing, and we also need to recognise that there may be multiple ways of achieving that end point. I might not agree with all those ways, I might even think that some are misguided but I will recognise that mine is not the only way.

So far my definition of “Software Quality” has focused on two aspects: defects and maintainability (and particularly extendability).

That is a small view, Tom Gilb and Jerry Weinberg’s suggestions are much wider. Tom would - I think - say my two aspects are but two “qualities” among many. For example: speed performance, ease of use and conformance to specification might all be part of quality.

I’m now thinking of quality like an onion. Defects and maintainability are at the core of the onion, and defects is probably the core.

You, your organization, your team, your customers might choose to added additional qualities to this definition which you are quite at liberty to do. For example, this might be your onion:

I believe this model is entirely compatible with Gilb’s concept of quality as qualities and Weinberg’s “Quality is meeting some person’s requirements.” (Thanks to Mark Nilsen for this).
Points here:

• Quality is multifaceted and finding a single definition to satisfy all situations is tough. (Even if we had such a definition it might be too abstract or academic to be meaningful in everyday work.)
• Each organization/team/project/product could benefit from defining what they take to be quality. (And I would suggest that few actually do this and that this resulting difference in individuals opinion on “what is quality” is the cause of much friction and mis-aligned aims.)

Quality is itself a statement of values - not necessarily financial value, its as much about personal values. That said financial value should neither be ignored or belittled - after all, most software is developed for commercial reasons, profit is not a dirty word.

Thus let me make another statement I believe is true:

Quality results in business benefit - money saved, money made, happier customers, business aims realised

Once we accept this the statements like “Quality is free”, “High quality save money” and “Quality sells” become axiomatic. The aim of “high quality” is to produce one of these business benefits.

Consequently statements like “We can’t afford this much quality” and beliefs like “Lower quality is acceptable to customers, is faster and saves money” are the result of a mismatch in different individuals understanding of what is quality.

For example: one person believes customers are happy with buggy software as long as it is available soon while another believes that customers want bug-free software later. When such mismatched occur using the word “Quality” is itself a problem because it means different things to the different parties.

That might all be too circular for some, sorry about that, I wish it wasn’t but I suspect that is the nature of the beast.

Now back to my definition and the inner layers of my onion. I think defects and maintainability are at the heart of the onion and need to be present in every definition of software quality because…

Defects: the research I have seen (Jones and elsewhere) and personal experience (as a developer,manager and customer) tells me that defects (bugs) are not a good thing - whether absolute defects or common defects. My experience and intuition tell me Jones is right when he says: “projects with low defect potentials and high defect remove efficiency also have the shortest schedules, lowest costs, and best customer satisfaction levels.”

Maintainability, changeability, and its half-brother extendability, is life. Software which can’t change can’t live.

At a basic level if you have maintainability you can fix defects and you can add any other quality you like. If your software is maintainable but not performant you can change it to have the performance you want. If your software is hard to use but maintainable you can change it to be easy to use.

If your software lacks maintainability, changeability, you will find it hard - expensive but perhaps not impossible - to make any of these changes. When software lacks maintainability it is not soft.

Lets agree to call software which is not (easily) changeable (maintainable) sclero-ware.

Definition: Sclero-ware - software which is not practically changeable.
(Where practically is context dependent.)

“But” you might ask, “are there not some examples of software which does not need to be maintained?”. “Surely,” you say, “there is some software which does its job and it is done. Defects might be core of the onion but maintainability is just another quality you might, or might not want.”

While this I can follow the logic here I am lacking an example. Do you know any? Indeed I suspect there are no such examples.

Because: successful software is used, and because it is used it needs to change.

Software needs to change because the world changes: Windows 8 replaced Windows 7 which replaced Vista which…. the Euro replaced the Deutschmark which replaced Reichsmark, the 747 replaced the 707 which replaced the Queen Mary and Queen Elizabeth I, telephones became mobile, telephones replaced iPods which replaced Discman which replaced the Walkman and along the way iPods replace Hifi systems, Banks replaced Building Societies, Debit cards displaced cash, ….

Must I continue? - the world changes.

Software which is not used does not need to change.

Software which is not used is the past. It is dead. Look here, SourceForge has plenty of dead software projects you can download, try one (here’s a page of examples.)

Successful software lives, it changes, it moves on.

So yes, software which did its job and is no longer used doesn’t need to change. You don’t need to change if you are dead.

Also, “maintenance” starts a lot sooner than is many people recognised. Maintenance starts the day after coding, not the day after the “project” ended. If you need to go back a fix a bug - at anytime! - you are maintaining. If your software lacks maintainability you are going to have a hard time getting any bugs out (and I suspect if it is not maintainable you probably have a lot of defects).

To summarise: I consider software quality to be a function of high maintainability and a low number of defects. I focus on these to attributes because I believe these are invariant. I am happy for add more qualities in a given context.

I accept there are different views on the best way of achieving these qualities. For example:

• The approach I was taught in the 1980s and 1990s involved detailing what was required, perhaps writing a logical specification, engaging in a design process intended to minimise defects and maximise maintainability, then coding and finally testing the software. Some people call this “Waterfall”, I prefer “Traditional”.
• The approach I advocate today involves setting a goal, identifying small pieces which can help build towards the goal, setting tests, engineering to those tests and repeating the process again and again and again. Some people call this “Agile”, I believe there are actually three styles better called “Iterative”, “Incremental” and “Evolutionary”.

And I believe that if you lack quality - you have a high number of defects and sclerotic code - sclero-ware - you will fail every time.

Software quality?

Since publishing my stream of consciousness about software quality on Friday (What is a software quality?) I’ve continued to think about the subject. In part putting the thoughts down started to structure my own thinking, in part a few comments made on Twitter caused me to think more, and, simply having written something caused me to reflect.

There are four main points I’d add to Friday’s entry.

First, what I wanted, what I needed for Xanpan, was (is) a good enough working definition of software quality, I don’t need a perfect definition. But even this turns out to be surprisingly difficult. And as Steve Smith pointed out this is not confined to software quality, defining “quality” at all tends to lead you in the direction of Zen and the Art of Motorcycle Maintenance.

Next, what I really need are two things: A definition of software quality and a definition of a software defect. I think I’m starting to approach workable definitions of both. But, definitions (by definition almost) should be free of assumptions about how you achieve - or don’t achieve - that aim. In other words, the definitions should not imply or assume an Agile, Waterfall or any other approach.

Third, one of the things I was concerned about was gold plating or over engineering. Really this is part of the “how do you achieve your aim.” A definition of software quality - and low defects - need not rule out (or embrace) any particular approach. I need to separate this out. Similarly the knowledge issue, while important, needs to be put on the side here.

Finally, I’m coming to the conclusion that we need two different terms for software defects. The clue was in that Tom Gilb quote really.

• An Absolute Defect is, as Gilb says, free from personal opinion or taste. It is objective. For example, function called “Add Two Numbers” always returns 5 - whether you give it 2 and 2, 2 and 3, or 100 and 200.
• A Common Defect (and I’m prepared to find a better name and I don’t imply any link to Deming) is anything which someone at some time decided to report - or classify - as a defect.

Absolute defects are a perfect subset of common defects, i.e. all absolute defects are also common defects but only some common defects are absolute defects.

I think its important to make this distinction because so much time and energy is spent by people arguing over what is and what is not a “defect”. If we define separate terms then we can at least reason about this situation and the fact that individual, teams and organizations often have incentives for classifying something as a defect whether it is or is not.

Jon Jagger pointed out in his comment on the previous blog that “Jerry Weinberg's definition of quality is "value to someone" or "value to some persons”.” A common defect most definitely fits that description. Someone, somewhere, considers it valuable to call this thing a defect.

But I’m not sure I go along with that statement as a definition of quality as a whole. It is too open and not specific enough for me - or perhaps for the uses I want to put it to!

Some observations about defects to end:

• All defects cost time and probably money: even logging a report of a potential defect costs time (and thus money) and action taken as a result (investigation and potential fixing) costs time. Defects themselves - even when not reported - may well costs money, e.g. overpayment or lost customers. (This also implies an element of the unexpected to defects.)
• Absolute defects cost time and money; is the same true for common defects? Well maybe my opinion of something does result in a different financial outcome than someone else’s but does that make it a defect? Even then it can be surprisingly hard for some organizations to tell what makes, and what looses, money. I’d like this to be the dividing line but I don’t think it is.
• Common defects need to be administered, managed and possibly fixed just the same as absolute defects. In my opinion, if someone reports a defect it should be considered against other defects - common or not - and action (fixing) taken or not. The debate between whether a particular defect is an absolute defect or a common defect isn’t very useful, it is the software equivalent of “my Dad is bigger than your Dad.”
• If there exists some pre-code definition (specification, requirement, formula, etc.) of what the code should do it might be easier to classify something as an absolute defect but this isn’t enough reason to create that definition.
• High quality software has few defects of either sort and is perceived as having few defects.
• Software which has a lot of reported defects doesn’t quality as high quality.