Want to break down barriers between teams?

Think “Agile” and 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…

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.

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. Nine 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