All posts tagged: Agile

Evolution, Aliens and Agile

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” -John Gall

I first encountered that opening quote from John Gall’s Systemantics back in 2000.  At the time I thought it was an amusing, albeit cynical, assessment of how systems work.  By systems Gall was not referring to computer programs – it was 1975 and the complex, networked, firewalled, data-based systems of today were only hinted at.  But business processes and methodologies were in place and Gall’s book railed against both bad system design and the futility of trying to design complex working systems.

During the past 15 years or so, my opinion of Gall’s quote (which in systems studies is known as Gall’s Law) has changed.  It’s not cynical – it is brilliant.  Gall’s insight is a deeply important one that has ramifications; not just for corporate processes, but also for engineering, politics and biology.

When one encounters a complex working system it is often natural to assume that some clever person or persons created the system out of thin air.  Of course, this is absurd if you think about it – we all build on the knowledge of our predecessors.  And systems evolve.  Smart phones didn’t spring from Steve Jobs’s skull like Athena from Zeus.  Before the iPhone, there was an evolutionary tree from the radio car phone to the brick to the flip phone to feature phones with apps – and what about Blackberry and the Palm Treo?  These predecessors are quickly forgotten in the wake of a more successful working system, but it is the nature of the human mind to marvel at the momentary and not reflect on the complex history that led up to the present.

Gall’s insight is true for many “mysteries” of human history, such as the Antikythera mechanism.  This mysterious device is an ancient mechanical computer.  It may be two millennia old; yet, it contains precise gears that simulate complex astronomical behavior to allow date calculations to be performed.  When faced with the complexity of this ancient device, many people come to the conclusion that it was either built with the help of aliens or was the product of some amazing savant.   Using Gall’s law as guidance, the more reasonable conclusion is that before this device was built there were simpler devices.  Earlier machines used gears and earlier designers worked with mathematicians and astronomers to turn their knowledge of the solar system into machines to simulate their understanding.   There would not have been a single device such as this.  There would have been prototypes, and more primitive predecessors that worked, that were not as complex, and which have been lost to history.  But they certainly must have existed.

One of the more recent developments in software design is the adoption of a methodology known as Agile Software Development. In compliance with Gall’s law, the Agile methodology itself evolved from other software development methods – taking those parts that worked and rejecting those parts which did not.  Agile has several characteristics – more than are within the scope of this article – but the one I find most constructive is that throughout the lifecycle of the project you develop working systems first, and then elaborate on them.   Agile Software Development is Gall’s Law in action.  A software project is broken up into development segments called “sprints” during which working prototypes are built.  Developers work with users to ensure that requirements are captured.  As the project develops, clients and developers share insights into how the software can work better.  New requirements emerge. Through continuous collaboration, the project evolves and there is a much greater chance that the end product will work properly, give the customers what they need and hopefully, be the kind of complex working system that leads people to wonder, how did they come up with this?


Questions or comments? Contact Blake at


erikafulkEvolution, Aliens and Agile
read more

Is your company succeeding at listening but failing at implementing?

Is this how your company functions –

This Company has been in business for over 75 years. They started their successful business long ago and only a few of the processes have changed over the years. You work for This Company, and you love it; your job is great, the co-workers are fun, and there are lots of windows, what more could you ask for? Let’s say, every Friday, you sit at your desk filling out an Excel spreadsheet with hours worked, then you fill out a time card online, then fax the spreadsheet to a person across the room who checks it against the online time card. And you sit there, spending 2 hours a work week filling out these forms, and think – ‘There must be a better way to do this, it’s 2013!’  So you write a comment on a comment card –

comment card

And then you wait. And wait. You forget that you’ve filled out the comment card, except for Friday’s when you spend 2 hours filling out your timesheet. Then, one day, someone walks up to your desk and says “We’ve read your comment card, and we agree, can you help us improve the timecard process?” To which you ecstatically say yes! Since you’ve submitted the comment card you’ve spent a boring 2 hours a week filling out the time cards and dreaming of how this process could be better.

So you and 15 people you’ve never met go into a conference room one sunny day, all full of hope. You sit through an 8 hour day with everyone giving their best idea’s. And at the end of the day, you’re feeling particularly good about the new proposed system. The moderator tells you that it will be a month or two before they can set up the new system, and you don’t even care. Hope for a new system has you living on cloud 9.

Three months go by. You keep thinking – ‘Man! I bet this will be the coolest time card system ever!” In your head there are laser beams that appear when you hit submit, you know that’s not in the plan, but that’s how awesome this new system will be. You can’t even wait. You’ve told all your co-workers about the meeting and about how fast this new process will be.

Finally the big day arrives. You get into work, and notice that all the eyes staring at you while you walk to your cube.  Your friend across the aisle says dryly “Thanks for the work on the time sheets.” You are a bit confused, as you sit down and power up  your computer, you notice the email “NEW TIME SHEET SYSTEM” Your heart beats faster.



Suddenly you understand why everyone is staring at you. You’ve just increased their timesheet time from 2 hours to 4-6 on a good day.

You sit there and wonder why the focus group spent so much time listening to you, but not acting on any of your idea’s.


You know, if your company used Agile Methodology, this could have been prevented 3 months ago.

Now, that was a really long intro to get you into the point of this blog.  Agile.  Agile is the point. 

Agile Methodology is simple in theory, and boils down to this – clients and developers are in contact throughout the project. Iterations are made and the project is looked at over the entirety on a bi-weekly basis. If the clients needs change – so does the project work. If the developers make what they thought was right, but it’s actually adding work to the process, the client has time to step in and say ‘no, that’s not what we wanted, we were looking for __x__.” Saving both developer and client from getting something neither wants.

The Agile Manifesto is based on twelve principles:

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Sustainable development, able to maintain a constant pace
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity—the art of maximizing the amount of work not done—is essential
  • Self-organizing teams
  • Regular adaptation to changing circumstances

How does this Agile process help you and your company?

In the middle of this example, you gave your input to the moderator and never saw anything until the final product had already launched. What happened in those 3-4 months where lots of extra processes were added and a new website was created? With Agile development, someone from the team gets to meet with the development team while they are building what you wanted.

To make it simple, say you want a pizza, you can tell the waitress “I’d like a 1/2 cheese and 1/2 pepperoni pizza” What you get is a pizza with no sauce and only cheese on one side, and the other side is only pepperoni, no cheese, no sauce (this is a real life example, it happened once to me).  That is what you asked for, but it’s not what you thought you’d get.

In Agile, you say I want 1/2 pepperoni and 1/2 cheese. As you watch the chef start to make the pizza, he makes the crust, you approve. You can see he’s not adding sauce and skipping right to the toppings, you can say – “Oh, I want sauce on that.” And then when he gets to the cheese, he’ll ask you “Did you want cheese on the pepperoni half?” You have an open dialog with each other, one side talks to the other to make sure that each is getting what they want. This makes it better for the client and the developer. And what you get is the perfect pizza quicker and cheaper than if you had gotten the wrong pizza, explained what was wrong, sent the old one back and wait for a new one to be cooked.


Time is money. Money talks and so should you. Make sure you work with an Agile team.  A team like Apex.

erikafulkIs your company succeeding at listening but failing at implementing?
read more