Software Development: Being Agile

Dogs at work. Insane hours. Beer bongs in the break room.

Oh, the crazy days of IT yore!

If you were developing software when these were hot trends, you know there’s another legacy that’s not quite as fun to remember: failed IT projects. From extreme cost overruns to missed deadlines to projects that were cancelled mid-way through, the track record for wildly successful software development projects is less than perfect (see my previous post for more about that bad news).

But here’s some good news: software development has come a long way since the ‘90s! Instead of the traditional Sequential or “Waterfall” development process – which involved a long requirements gathering process in the beginning, followed by design, development and testing – many developers (including ours) now use the Agile or “Collaborative” development process.

I think of Agile as reality-based development because life, work and, well, software development, is all about change. (If you’ve been alive longer than five minutes you know that’s reality!) When an Agile approach is used, changes are easily accepted and adapted. In fact, with Agile, change is baked right into the process.

But don’t confuse change with confusion. Progress must be made and measured on a regular basis. When Agile is in use, progress is measured in “iterations,” which translates into a tangible work product. Multiple iterations provide the project foundation, with each one taking from one to four weeks to complete (two-week iterations or “sprints” are most common).

One of the best things about Agile software development is that it keeps all parties actively engaged and work gets done in the way they like best. Customers (or other key stakeholders) determine the priority order of the iterations and other key decisions. Developers – many of whom are Millennials that thrive on continuous feedback and teamwork – can deliver working software with each iteration. A classic win-win!

“There is pleasure in the pathless woods,” declared an 18^th century poet. Maybe that’s the best environment for developing poetry, but software development works best with a clear path. That’s why Agile involves a work plan defining each step before any work begins, with plenty of flexibility for adaptation as changing circumstances dictate. Best of all, using an Agile software engineering approach adapted to an organization’s specific culture, history and staff means more accountability and less waste.

We’ve come a long way since the crazy ‘90s as Agile-based development is proving every day. (There may not be many dogs in offices anymore, but successful software projects don’t need to rely on gimmicks to distract developers from terrible projects!)

Next, I’ll share thoughts on what to look for and how to work with team members and partners.

The Good, The Bad and the Ugly Truth about Developing Software Today

First, “the bad.”

If you have any involvement in the world of software development today, you know it’s challenging to say the least. Companies need to develop software as cheaply as possible, but many have learned the hard way that the cheapest route can lead to shoddy results (or no results at all!).

Just Google “failed IT projects” and you’ll find plenty of evidence, such as the 2009 IDC report that found 25 percent of IT project fail outright, and that 20-to-25 percent don’t provide ROI, and up to 50 percent required material rework. Add it up, and that’s a whopping 100 percent that either failed, needed rework or didn’t deliver as promised.

It gets worse.

CIO magazine has reported that two major surveys of more than 100 IT professionals across the country – conducted three years apart – revealed that:

• In 2013, 50 percent of 127 surveyed companies had experienced an IT project failure within the previous 12 months.
• The number grew to 55 percent reporting a project failure between January and March 2015.

A more recent report found that 25 percent of technology projects fail outright; 20 to 25 percent don’t show any return on investment; and as many as 50 percent need massive reworking by the time they’re finished. (Forbes 2016).

There are multiple reasons for these dismal statistics. One of the primary culprits, I suspect, is the failed offshore development adventure. Instead of providing a cheap, fast turnkey solution, offshore software project frequently was bedeviled by poor management, confusion about team roles and /quality standards well below what U.S. companies (and consumers) expect. In fairness to lower-paid offshore IT professionals, language barriers, and time zone and cultural differences are tough hurdles to overcome.

I know of what I speak. Intertech attempted engaging offshore developers years back to offer our customers a more effective solution. We worked hard to make those offshore engagements work, but in the end, we spent more money than we saved due to extensive rework. As much as we in IT want to believe space should not matter, proximity to customers and the people doing the work does make a significant difference.

And so, where do we from here?

The need to keep costs as low as possible has never been more acute. Global trade means (we) and our customers are competing with businesses around the world, many of which have much lower labor costs. We must find ways to keep delivering quality but at a price that doesn’t break the bank.

Next time: The ugly.