Friday, November 30, 2012

Dijkstra, tools and version control systems

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.”, Edsger W.Dijkstra

...or in other words...
"If you already have a hammer, it is very tempting to treat everything as a nail"

My views on using electronic tracking tools are already fairly well known. But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start. 

In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around

Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:

    • All developers get a copy of the current mainline code out of the VCS.
    • The developers work on the code, making a relatively small changes, including various tests, as they go.
    • Everyone regularly checks these changes in to the mainline. This happens at least once per day. Normally checkins are much more often - 5-10 checkins per developer per day is not unusual for a fast-moving team. 
    • After each checkin, the mainline code is compiled, both unit and regression/acceptance tested, and packaged. Note that assuming no problems are encountered, there is potentially deployable product each time this happens.

Regular, small checkins to the mainline branch means everyone’s code is integrated many times per day, revealing problems quickly (fail fast). The amount of change between a successful build and a problem is limited, and so makes recovery more manageable; integration issues can usually be resolved within 15 minutes. 

This way of working eliminates branching almost entirely, so avoiding the dreaded Merge Hell. Everyone always works on the mainline branch, no-one uses a separate branch to develop. Changes and bug fixes are always on the mainline, so the software is always going forward using small, manageable integrations. In the rare case that a change needs to be applied urgently to an existing release before the next formal release, then a separate branch might be created to handle this (alternatively a new copy of trunk may be deployed). Releases are, of course, fully tested at a number of levels and accepted before release, so problems should rarely occur. 

Developing this way also has “a profound (and devious) influence” on what our versioning software needs to be able to cope with. Here are just a few I can think of:

    • Each automated build needs to be uniquely identifiable with minimal effort so it could be released if needed
    • It needs to be easy to rollback individual changes/checkins. Fail fast also implies recover fast.   
    • Checkins and checkouts need to be fast and efficient so they are seamless
    • Good integration with tools to make its use virtually seamless (developer IDE, continuous integration setup and so on)
    • Easy to use. Amongst the “small changes” a developer might need to do is to rearrange the project structure as required to maintain a successful develop-and-build cycle as new requirements become understood, or new components are identified

Compromising any of these would be likely to obstruct the developers as they build software[*]. Worse still, as Dijkstra suggests, the tool will affect the way developers think and work:

    • If builds cannot be easily tagged/identified, then they won’t be tagged
    • If it is hard to roll back, then developers will not roll back
    • If it is slow to check in or check out, then developers will only do these when forced to. Frequent integration becomes less frequent, problems become harder to find
    • If it is hard to integrate, build and test, then it won’t happen very often
    • If it is hard to reorganise the project, then it won’t be refactored to a better structure counter this, suddenly you have to issue edicts, define rules and issue development documents and ticklists to ensure people work around the bad tools and make sure the “right stuff” is happening. Trust me - I have seen it happen and experienced it first hand; it is a very bad place to be!

Whenever choosing a tool to support your project, bear Edsgar Djikstra’s quote in mind. Make the tool fit your way of working. Don’t let the tail wag the dog.

* I'm looking at you, ClearCase....

Tuesday, August 07, 2012

A made up conversation[*]

Team: “Coach! Coach! This agile process stuff you sold us doesn’t work!

Coach: “Did you build working software regularly?

Team: “No, it was too difficult.

Coach: “Did you extend your definition of Done as far as you could?

Team: “No, it was too difficult.

Coach: “Did you make quality part of your process?

Team: “No, it was too difficult.

Coach: “Did you review what you were doing at all?

Team: “Yes, but we didn’t like what we discovered, so we ignored it.

Coach: “So are you absolutely sure it was the agile process that caused you to fail?

Team: “Oh yes, absolutely….

Coach: "<sigh>"

* honest....

Monday, July 30, 2012

Good, Bad, Puzzling Retrospective

By popular is a blow-by-blow run through of the simple 60 minute 'Good, Bad, Puzzling' retrospective format that I use. Have fun using it. 

Good, Bad, Puzzling Retrospective
Introductions and checkin (10 minutes)
Start off the retrospective by getting people to “check in”. That is, invite them to speak early on, focussing on what is being reviewed. This makes them feel like they are part of the meeting, and implicitly invites them to actively participate.

I normally use something like:
  • Describe the last Sprint in 3 words
  • If the last Sprint was a Star Trek/Star Wars/South Park character, which one would it be?
  • What colour was the last Sprint?
...and so on.... Get creative!

Once everyone has checked in, you need to create a “safe zone” where the Sprint can be discussed without blame. Everyone needs to agree that everyone in the Sprint always acted as best they could under the circumstances at the time, and to accept that anything that went wrong has happened, and cannot be ‘unhappened’. Or in other words, everyone needs reminding that “Hindsight is always 20:20” - you can always look back and say that “if x, y and z hadn’t happened, then something wouldn’t have broken”. I use Norman Kerth’s Prime Directive as a starting point:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Also worth remembering are the Four Freedoms (also from Kerth):
Everyone has the following freedoms:
  • Freedom to recognise and observe what is rather than what others want you to see
  • Freedom to ask about puzzles
  • Freedom to acknowledge and talk about what's coming up for you
  • Freedom to talk about not having any of the above freedoms
Often improvement is obstructed by a feeling that certain things (problems, behaviours, issues) are off-limits; the Four Freedoms are a great way to remind people that nothing is off-limits as long as it is discussed respectfully.

Brainstorm (10 minutes)
Get everyone to write down their observations and issues from the last Sprint onto Post-Its (one per issue!), and put them onto a board under one of three headings: Good, Bad or Puzzling. If possible, use a colour code - usually green for good, red for bad - this will help identify hotspots later. Also I encourage people to use a medium marker for the sake of readability, and to limit the amount that can be written.

Timebox this to 10 minutes. If everyone appears to have finished before the 10 minutes is up, wait a little longer since someone will almost always remember something. Remember: don’t be afraid of using silence.

Note that it can be worthwhile reminding people to write legibly!

Group (5 minutes)
Get the Team to organise the Post-Its into groups of related issues on the board. Exactly what constitutes a group is up to the Team. Timebox to 5 minutes max. Encourage everyone to participate - do this actually at the board, get everyone moving since it increases their energy for the discussion.

Optionally do this exercise in absolute silence apart from the final minute (to solve any disputes). The idea behind this is that speaking is controlled by the left side of the brain (the logical side), which dominates. Doing this silently is supposed to use more of the right hand brain (the creative side). Does this really work? No idea, but it’s fun....

Note that if you have used colour coding for the issues, specific areas will stand out as being predominantly good, bad or puzzling. Look out for these, and if there is one area that has a large concentration of bad comments, then consider highlighting this, skipping the vote and discussing the issue directly.

Name and Vote (5 minutes)
Once grouped, go through each and give each group a specific name. Identify what links all the issues together.

In order to pick just one topic to discuss, get the Team to do a “3-Dot Vote”. Each team member gets 3 votes to cast in the form of dots against specific issue groups. They can put all 3 against one group, 2 on one, 1 on another, or all three against different groups depending on how strongly they feel about them.

Once everyone has voted, add the totals, and the winning group has the most votes. If there is a tie, then I tend to use a simple show of hands to choose one issue to discuss.

Discuss (25 minutes)
So what we have now identified is one single issue or area that the Team has jointly agreed to discuss how to improve. Sometimes the discussion will happen quite naturally, sometimes you will need to start people off. The best way is usually to focus on what the Team believe is happening - “The Problem”. 

As specific problems emerge, get the Team to consider specific solutions. Don’t lose track of either - I tend to jot them up freeform on a whiteboard. 

As the timebox draws to an end, get the Team to agree on one or two of the solutions that will be adopted as actions in the next Sprint. Don’t allow the Team to overload themselves with change; I generally suggest a maximum of 2 retrospective actions for a two week Sprint.

Wrapup (5 minutes)
Finally, wrap up the meeting. Thank everyone for their time, and summarise the actions that were agreed.

Consider doing a Return On Time Invested (ROTI) exercise to see how people feel about the retrospective, and to provide some feedback on how effectively you ran it. 
For example, “On your way out, vote on a scale of 1-4, where 1 means this retrospective was hugely valuable, and 4 means it was a total waste of time and I may as well have been sitting at my desk working

Follow Up
Follow up the retrospective with an email stating at very least the agreed actions for the Sprint. 

Other Thoughts
I don’t recommend revisiting the other issue groups identified by the Team at a later date. The retrospective provides a snapshot of what was important to the team at that moment in time, and this will change Sprint by Sprint. If an issue continues to be important, then it will appear again in a later retrospective.

However, if you want to keep track of how retrospective issues change over time, take pictures of the grouped board. You may see recurring issue groups that has been missed by the Team.

Also you may want to take pictures of the notes (problems, solutions) discussed to serve as a reminder. A wiki is a good, informal place to store this information.


Introductions & check in    
Name and Vote

Friday, June 08, 2012

I've been nominated for an award!


Well, that’s a nice surprise! I have just received a very nice email telling me that I have been nominated in the Agile Special Recognition Award category at this year’s Agile Awards.

Wednesday, May 23, 2012

Listen to your process feedback

Paraphrasing an overheard conversation,
"This agile process is creating all sorts of problems for us. We are finding all sorts of problems that we wouldn't normally find.
"Oh. Wait. They were always there, weren't they? We just never realised..."
All agile processes are designed around regular feedback. They try and touch all phases of delivery as soon as possible, forcing issues to the surface early before they become too damaging. The process is designed makes problems visible regardless of how uncomfortable this may be. They are an unforgiving mirror on the reality that we are often too close to see.

But visibility is only the beginning. Just because something is visible does not magically change it into something better - it just means that you know it is there. To change something requires a conscious effort. Your success or failure depends entirely on how you react to the information you are provided with. This reaction has very little to do with the process, and more to do with improving the way the team is working. Denial is not just a river in Egypt....

Or in other words, agile process is only as effective as the people using it. It is entirely dependent on your reactions to the feedback it provides. A failing agile process says much more about the adaptability, reactiveness and maturity of the organisation using it than the process itself. 

To put it yet another way, you will never be agile if you refuse to be agile.

Tuesday, May 01, 2012

Energized Work: No Bull

Those jolly fine people at Energized Work are at it again with their "No Bull" paper which provides us with Simon Baker's personal view of the state of software development 12 years(-ish) after the Agile Manifesto.

Now, I know Simon and Gus, the founders of Energized Work, well. I have worked with them extensively, and I have nothing but respect for what they have achieved - quality software development with integrity. I also agree with most of what they say and do. I also know the Energized Crew pretty well - a network of committed, high quality software experts who know exactly what they are doing. They have all embraced the whole "agile" way of working. The other thing notable about Energized Work is their well stocked beer fridge.

So it is no surprise that the paper resonates with my general views on the software industry today, and the opportunities for improvement that we are missing as an industry.

I would encourage everyone to read the paper for themselves, and draw their own conclusions. But for me, the key points are:

  • Agile works. Period. They are not talking about the artificial, watered down imitation "Agile" (capital 'A') that many companies pretend to adopt to protect their internal status quo. These cargo-cult counterfeits are doomed to mediocrity and failure. Simon is talking about the full on, full fat, doing it right Real Deal - a collocated, cross-skilled, engaged team, sitting with a business representative who knows what they want, working with a build pipeline providing fast feedback, all coupled with a flexible attitude. Or, in Simon's words, the difference between "Doing Agile" and "being agile".
  • Companies are prepared to tolerate huge amounts of failure as long as it is done traditionally, but they are fearful of even a single success that is achieved unconventionally. This is arguably the biggest barrier to software delivery today - blind adherence to failing traditional techniques and an inability to innovate.
  • We need to stop talking about "agile" as if it is a separate thing, and start talking about how we deliver software that is fit for purpose and delights customers. 

Read it. You know it makes sense!

Friday, April 27, 2012

Agile posters

I am in the process of revisiting exactly what defines agility and what makes it tick, but collecting my thoughts on the subject reminded me of a couple of classic poster summaries from those jolly fine fellows at Energized Work back in 2007. Well worth a look.

Don't Compromise Your Agility poster


Monday, April 23, 2012

Certified Scrum Developer courses

I am pleased to announce that Thirsty Bear Software is now working in association with RADTAC to provide courses that lead to Certified Scrum Developer.

These are three day technical courses that cover the technical aspects of agile software development - basically the same training that I have been providing to companies outside of the Certification bunfight for years, except now formally assessed and accepted by the Scrum Alliance as satisfying the technical requirements of their new Developer Certification framework.

The next public courses are planned for the following dates, and are subject to change:
14-16 May
21-23 August
8-10 October
19-21 November 
The courses are all held at the RADTAC offices in Central London, close to St Paul's Cathedral.

For more details, and to book your place, please contact RADTAC directly.

Tuesday, April 17, 2012

On bumping down stairs

Unsurprisingly, here at Thirsty Bear Software we have a certain affinity with our bruin brethren, not only in the wild, but also in literature. I have found that one particularly famous bear can teach us a lot about how we behave, how we can improve ourselves, and even about the way we develop software. I am, of course, talking about Pooh Bear, of Winnie-the-Pooh fame. But what can the Bear of Little Brain tell us about true agility? Are you sitting comfortably? Then let's take a stroll to Hundred Acre Wood....

“Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. And then he feels that perhaps there isn't. 
Winnie-the-PoohA. A. Milne

This is the starting point for many teams, including some self-declared agile teams. They are working hard to produce quality software, but they seem to be bumping their head on each stair on the way.
Capture the requirements. <Bump!>
Write the code. <Bump!>
Test the code. <Bump!>
Build the system.<Bump!>
Commission the environments. <Bump!>
Deploy the system. <Bump!>

Everyone is left thinking that there must be a better way. If...Only...We...Could...Just...Stop...For...Long...Enough...

Yet this is often the unwitting first step to behaving with agility. Awareness. It is that thought telling you that there is a better way of doing what you do if only you could just stop long enough to take a closer look. Without awareness, you remain blissfully unaware that there is even a problem. To improve how you work you need to recognise and actively seize this fleeting realisation, allowing yourself the chance to take a cold, hard look at what is causing the problem. Once assessed, you can plan actions to improve the situation, even if it is initially simply padding each stair on the way down the stairs so that you can think more easily next time....

Awareness. Assessment. Action. Think it over, think it under...

Thanks, Pooh.

Would you like to buy an agile?

"You want to buy an agile? We sell you an agile. Very cheap. Very easy."

Doesn't make sense, does it? And yet many companies accept equally nonsensical marketing speak because they want to "do agile".

"Agile" is not a physical thing that can simply be bought or sold; it's not a commodity. It is a concept. A philosophy. A mindset. A way of thinking. You cannot just be handed one to use. It requires you to make a fundamental change in yourself. If you are not prepared to invest in that change, then you are wasting your time and money trying to achieve the goal. You have simply bought an agile, and put it on a pedestal in the corner. "Look, that's our agile. Do you like it?" (actually no. It's a dodgy colour and clashes with the curtains....)

Equally, any company claiming to be able to implement agile simply by putting in place a simple process is making the same mistake. Unless an organisation changes the way it thinks at every level, it will never see the true benefits of agile.

So beware any company prepared to sell you an agile (especially at inflated consultancy rates). Caveat Emptor.

(Thanks to David Putman for the original phrase)

Sunday, March 18, 2012

Well I never knew that....

I like Jenkins. It handles continuous integration jobs well, and is easy to learn and setup. But I have always wondered why it colours successful builds as blue out-of-the-box. To use green to indicate successful builds you need to install the Green Balls Plugin.

Well, those nice chaps at Jenkins HQ have revealed all. It's all to do with Japanese culture, and of course the original Hudkins developer, Kohsuke Kawaguchi, has a Japanese upbringing. Culturally, in Japan red implies 'stop' and blue means 'go'.

You learn something new every day....

Sunday, February 26, 2012

Keep Calm and Test First

(yes, I confess I found the Keep-Calm-o-matic for this and the previous article graphic Face-smile )

Post CALM-Alpha ponderings

Well, the CALM-Alpha event has come and gone, and some people have already been voicing their views on the conference. From my point of view, it was a bit of a curate's egg - good in places, not so great in others, although we simply got back what we as delegates put in. So what did I take away from the unconference?

This is only the beginning

There was a reason for it being called CALM-Alpha. This was the first attempt at pinning down common ground between complexity theory (in this case, the work being done by Cognitive Edge with the Cynefin framework). The organisers had no real idea where it would lead, and this was a 'fail safe probe' to test out the possibilities. So no wonder it was at times a little confused. We are only just starting down this path. Hell, I don't think we even know if there is a path there yet! So yes, it was a somewhat painful experience at times. Too much jungle, not enough machetes. But worth it? Definitely.

The software industry is painfully immature

One thing was painfully, embarrassingly obvious during the conference. There was depressing evidence of just how immature our industry still is. At various points throughout the conference I saw behaviour highlighting damaging splits across the agile and lean software communities. Some attendees were keen for "their" methodology to be seen as suitable for "Complex" problems, and so obviously far better than a methodology that operates well in the merely Complicated. And as for techniques that were well suited to Simple problems, well, that would be barely worth exploring because they were, well, simple! The inevitable Scrum vs kanban wars started, as well as debates around pure Scrum vs adaptations. Even more disappointing were damaging, passive-aggressive "not invented here" attitudes I saw around the rehashed, reinvented and rebranded.

As people who boast about our ability to cooperate, we have become remarkably insular. Come on guys, I am tired of this willy waving and chest beating, and I know others are too. Let's grow up and collaborate with the other grown ups.

There is something in there

I suspect there is something in complexity theory that we in the software community are slowly discovering. Maybe it's in Cynefin, maybe other models. But one thing's for sure - our industry needs to understand why certain techniques work in certain circumstances, and not in others. We need to understand when to apply which tools and techniques, rather than thrashing about in the dark as we currently do. But depressingly it would appear that the software community want to do it the hard way and rediscover these ideas themselves. Sadly the cynic in me suspects that this is at least partially driven by self interest - people want to brand it, sell books and create a certification pyramid.... 

So what next? Hopefully the organisers of CALM-Alpha will organise CALM-Beta, learning from the lessons of the original event. I also hope that people will recognise what happened during the original conference, and reflect on how we present ourselves as software professionals. We need to seriously reconsider the way we behave, and how our industry works if we are to be taken seriously. 

Saturday, February 11, 2012

The power of caring and smarts

Prog Just recently I have been thinking a lot about what really makes a good agile team member. The reason is that over the years I have seen some teams become incredibly successful in terms of delivering products, and other teams crash and burn even though they have the same superficial traits and abilities. I have also seen teams go from zeroes to heroes (and back again), while others remain at whichever end of that spectrum they started at and never change. There is obviously some "secret sauce" (as Jeff Sutherland calls it) that needs to be mixed in. 

Well, I think I have identified one piece of this particular puzzle that I had underestimated previously.

Recently, one of my tweets resonated with quite a few people:
"Realised that agile has one fatal flaw. It still requires motivated, smart people who care for it to succeed, same as its predecessors."
(actually I was fibbing slightly - I have suspected this for quite a while now. I haven't only just realised this)

I think these two are key ingredients for success, and not just "nice to have". They are the "secret sauce", not just for agile teams, but for software development in general.

You need people who are smart. By smart, I don't think I mean conventional intelligence and IQ, but something different. The best way I can describe it is a combination of problem solving ability and intuition. 

You also need people who care. Some people have a deep seated drive to do good work. To excel. To better themselves. To maintain their humanity and help others achieve too. You need people with a strong inner motivation who want to make things work.

When you combine these two, magic begins to happen. I believe that people who care and have exceptional problem solving abilities (who care about solving problems, maybe?) tend to have the right attributes for agile (and other) software development teams:

  • Able to communicate
  • Willing to learn 
  • Humility
  • Courage
  • Passionate about quality
  • Curiosity
  • Integrity
  • Initiative
  • Creativity
  • Imagination

But that is not all. I believe they will naturally obtain the basic technical skills to do their job as a side effect of the curiosity, the courage and...actually all of the above! Now imagine what an entire team of these self-motivated, capable people can achieve.

However, I should emphasise that creating a functional, high performing team is not as simple as simply hiring in the people with the Right Stuff. You also need to put them into an environment that will nurture them and allow them to grow. If you put caring, smart people into an environment that actively discourages the right behaviours and attitudes, whether by accidental cognitive dissonance or deliberate edict, then there will be trouble ahead. But getting the right people on the bus (and its corollary, getting the wrong people off the bus) is a good start to sorting out your delivery problems - "Lead them, follow them or get out of their way".

So it looks like agile has the same achilles heel that its predecessors - waterfall, DSDM, RUP etc - have. It does not do away with the need for good people working in a good environment. You cannot force anyone to do a job well if they do not want to. No matter how much you believe that agile provides a framework for building high performing teams, it cannot force people to inspect, adapt and learn if they do not want to. But it does provide one huge benefit. It fails fast. You find out if the project is progressing - or not - very quickly. The feedback it provides allows the rapid identification that something is going wrong, whether it is environment, design, policy or people. This has enormous implications for our industry in terms of how we need to handle hiring, team building and behaviours in the future. More on that soon.

Tuesday, February 07, 2012

How many holes are you falling into?

There’s A Hole In My Sidewalk– by Portia Nelson 
Chapter One
I walk down the street.
There is a deep hole in the sidewalk.
I fall in.
I am lost… I am helpless.
It isn’t my fault.
It takes forever to find a way out. 
Chapter Two
I walk down the same street.
There is a deep hole in the sidewalk.
I pretend I don’t see it.
I fall in again.
I can’t believe I am in the same place.
But it isn’t my fault.
It still takes a long time to get out. 
Chapter Three
I walk down the same street.
There is a deep hole in the sidewalk.
I see it is there.
I still fall in… it’s a habit.
My eyes are open.
I know where I am.
It is my fault… I get out immediately. 
Chapter Four
I walk down the same street.
There is a deep hole in the sidewalk.
I walk around it. 
Chapter Five
I walk down another street.

So which chapter is your team at? Be honest now.

Tuesday, January 17, 2012

Infamy! Infamy!

...they've all got it in for me!

Excruciating Carry On pun aside, here's the long overdue link to the talk I gave to the Limited WIP Society way back in March 2010 (my fault for not posting it here - it's been up on the SkillsMatter website for ages).

(Sorry, this is just a link. I can't work out how to embed this directly into the blog page - any ideas, anyone?)

Monday, January 16, 2012

Software development is not an assembly line

Thunderbird assembly line
Analogies are useful to a point. They allow people to relate new ideas back to something they are familiar with, giving them a safe framework from which to explore new territory. However they can also be immensely damaging and misleading. I was recently reminded of one  particularly well worn example of the latter type that needs to be laid to rest once and for all:

Building software is not the same as building a car. Developing a software product is definitely not a simple assembly line process.

When building a car on an assembly line, you make the individual components - wheels, engine, chassis, seats etc - and then construct the finished item from these. Each component has already been designed in its own right, and they have all been proven to fit together many times previously. There is absolutely no creativity involved in the construction process. There are limited opportunities for different combinations of components (and those that are possible are well tested).

Software development is a fundamentally different problem. You don't have a set of predefined components. But you do have close to an infinite number of ways to build the final product. Individual components making up the final product need to be built, and so have not been proven to work together. The whole construction process requires a huge degree of creativity to produce a final, working deliverable. The nearest you can get to a car manufacturing analogy is to think of building software as attempting to build a car from raw lumps of metal, with no existing, pre-proven designs for the components. Trying to emulate an assembly line by believing that you can build component after component and expect them to immediately bolt together without problems will inevitably lead to tears before bedtime. Yet many teams still fall into this trap.

If it can be related at all to this analogy, software development has more similarities to car research and development than manufacture.

Consider this. A new car design is first prototyped as a collection of conceptual drawings that are iterated towards a final design. Then these are fleshed out to various models and mock-ups which would never make it to the forecourt, but which are used to invite more feedback. Then working prototypes are produced, and again, more feedback obtained, and designs iterated (or the design is shelved or binned). Finally, after many, many iterations, there is a new model of car available to purchase. Sounds familiar? Iterative software development creates a simple demonstrator of the system, then keeps on adding to it, refining both the functionality and the design until it is good enough to release to users.

This is where software development fits. It has more in common with pre-manufacture prototyping than assembly lines. But this doesn't stop us from stealing relevant, useful ideas from the assembly line. Kanban, anyone?