In software development, Agile’s practices have the advantage of encouraging teamwork by breaking down barriers between various teams in sales, development, business consulting, operations, and IT.

1. Agile or how to break down barriers between teams
In software development, Agile’s practices have the advantage of encouraging teamwork by breaking
down barriers between various teams in sales, development, business consulting, operations, and IT.
Google defines it as “relating to or denoting a method of project management, used especially for
software development, that is characterized by the division of tasks into short phases of work and
frequent reassessment and adaptation of plans.'agile methods replace high-level design with frequent
redesign'”. If that sounds a little confusing, here's another way of explaining it. When a software
company is developing an application, they use agile software development – or ASD – as a creative
process that is able to anticipate the need for both flexibility between teams and a pragmatic approach to
the technical debt that produces the finished product as expected by the client.
As Martin Fowler, agile software development “guru,” and CTO of Thoughtworks has said about this,
“The beauty of agile approaches is they recognize the value of refactoring, and have the automated, test-
driven discipline to make this low risk.”
In a previous article, I wrote about Balancing Technical Debt with Business Constraints. ASD is
perhaps THE key to successfully reaching this balance.
What do I mean by that?
In traditional software development, a client approaches with a problem they need a software solution
for. The software company sales department tells the client when to expect delivery, then hands the
order to the CTO, who then has to decide how in the world he can get his busy engineers to get it
finished in time. After much protesting and arguing with the sales manager, he takes the order to his
engineers and tells them what they have to do and when it has to be finished. They grumble and grump
about the pressure they're already under, then get to work on it as soon as they finish what they're
already doing. When the software is finally finished, often late, it's a huge and possibly still very buggy
solution, but it works fairly well, and they promise to give their client great customer support – aka –
removing the bugs at no charge as they come in...

2. Enter ASD. The idea for agile software development came from the dynamic systems development
method (DSDM) from the 1990s, and the DSDM Consortium, founded in 1994, which was intended to
help bring some order to rapid application development, which greatly decreased the time from order to
delivery, compared to prior methods with a strong emphasis on rigorous planning and specifications, but
had the unfortunate side effect of created sometimes massive tech debt by putting too much emphasis on
getting the finished product delivered quickly.
In early 2001, at a ski lodge in Utah, seventeen representatives from Adaptive Software Development,
Crystal, DSDM, Extreme Programming, Feature-Driven Development, Pragmatic Programming,
SCRUM, and others who recognized the need for an alternative to the old "waterfall" software
development processes got together to talk.
Out of that meeting came what is known as The Manifesto for Agile Software Development, or Agile
Manifesto.
The idea of the Agile method, in a nutshell, is twofold.
One – for all the teams involved in software development to work together, including the client, the
sales department, the research and development team, business consultants, operations people and IT
guys, so that they all understand and agree with each other about the vision, the backlog of features and
the roadmap.
Two – to continuously deliver in small, “digestible” and working applications, with continuous input
from the client, rather than in one large, cumbersome and potentially tech-debt-laden monstrosity. This
allows management to make changes, because the client and its users can use each new version earlier,
step by step, find the bugs and correct them, or even change priorities entirely.
The manifesto, wisely, while keeping these two principles in mind, makes customer satisfaction the
highest priority, by offering early and continuous delivery of valuable software. Again, rather than
trying to solve every single problem of the customer in one grand (and probably buggy) solution, we
deliver solutions to smaller, individually and recognizable problems that are an important part of the
whole. In doing this, the customer's life and confidence begins to improve very early in the relationship,
which is almost priceless in the even that we DO happen to run into a major bug later.
Rather than freaking out when the customer changes their mind or their needs change late in the
development of a product, we welcome changing requirements, because agile processes allow us to use
such changes to give our customer a competitive advantage.
Rather than spending six months to a year (or more) developing a total solution for all our customer's
needs, we deliver working software as often as possible, preferably in a couple of months or less.
We must put our business people and developers together on a daily basis throughout each project. This
is SO important. In our meetings, we all sat around the table as equals, each one bringing her or his own
perspective, insights and expertise to the table. It is critically important that business people and
developers see each other as allies and team-mates working toward the same goal.
If we want to achieve something great, rather than mundane and merely acceptable, we need our team
members to be motivated. This is why some of the most successful companies in the world, today, like
Google, Facebook and Microsoft encourage their employees to play and provide bright, cheerful
atmospheres with everything from games, to gym and yoga classes, to letting them bring their pets to
work and even to playing pranks on each other, such as Mark Zuckerberg posted on Facebook.
The point is, if we want creative and motivated people, we need to create the culture (environment and
support system) they need, then trust them to get the job done.

3. One very obvious part of the Agile Manifesto, although it is seventh on the list of twelve, is the fact that
we need to remember that working software must be the primary measure of success. One of the things
I often used to hear is, “It's all fun and games until somebody loses an eye.” The point was that we
have to remember why we go in every day, or we won't be going in for long. The business still has to
produce the product it exists for, or it will fold up.
A beautiful thing about the agile way of doing things is that it promotes sustainable development. When
everyone recognizes that the world of business is constantly and quickly evolving, it's possible for all
stakeholders to maintain a constant pace indefinitely. As Robbrrecht Van Amerongen so aptly put it,
“Software development is like running a marathon and not (a)100 meters sprint. You have to keep up to
speed but not run so fast that you exhaust yourself or your team members.”
The idea of agile is not to slap a product together for delivery, then quickly come up with version II for
next week, but to continually focus on technical excellence and good design. This means that a good
product gets delivered this week and an even better product in version II.
When I coached my kids as they learned to color, I first coached them on very tidy results by instilling
in them the importance of first choosing well defined outlines, then not coloring over the lines, then
focusing more and more on filling in everything inside the lines. Always, the focus was on design and
excellence. So we must focus on design and technical excellence in software production.
As in almost everything in manufacturing, from the Mars Rover to software, we must use the K.I.S.S.
Approach. Keep It Simple Stupid. Or, as I always liked to put it, Keep It Stupidly Simple. I used to tell
people that the job needs to be done right, but not hard. In other words, don't create unnecessary work
to get the job done. As a wise person once told me, “As soon as you create a foolproof system, they will
come up with a better fool.” As the Agile Manifesto succinctly puts it, “...the art of maximizing the
amount of work NOT done is essential.”
We need to encourage our teams to think for themselves and be able to organize themselves. They will
produce the best designs, architectures and requirements. I can't tell you how many times I have had
this proven to me. Let your people thrive on the pride of their own accomplishments! As shared in a
previous article, the CTO is the maestro in this orchestra, not the one who makes all the music!
I remember the day I said to my team in charge of our software products for airlines’ flight operations :
“We’re going to develop an optimization engine!” There was a blank stare. I was confident in the
project as I knew that our clients would sponsor us, I would acquire the skills by doing the research, and
the team would tackle the challenge. After we designed the architecture, we started to code business
logic, month after month, reporting our progress first to our clients and sharing our difficulties. 8 months
after, we delivered the beta version and 4 months later we finalized V1.
Again, I can't emphasize how important it is to have regular, short team meetings (from 15 to 30 min),
where everybody can brainstorm on how they can be more effective, allowing them to tune and adjust
their behavior accordingly. The results of doing this are quite amazing to observe. When everybody
realizes their input is important to the company, they become enthusiastic and motivated performers, not
only able, but willing to go that extra mile and produce something extraordinary.
The agile method for software development breaks down barriers between teams from every department
and area, creates a better, brighter, friendlier and happier work environment, and produces a higher
quality and evolving product in less time that everybody is happy with.
In keeping with the agile spirit, I welcome your comments and insight below!
Jean-Christophe (Jay C) Huc 14 July 2016
jch@huc.name