Delivery and Simplicity : Don't Leave Home Without These Agile Principles

Bootstrapping Agile from the Trenches

In February of 2006, I was offered the position of Lead Architect for the redevelopment of CDC's Epi-X system, CDC's flagship secure communications platform for emergent disease outbreak notification and bi-directional collaboration between multi-jurisdictional public health authorities. However, on the same day I was offered a position at a private .NET consulting company, Abel Solutions. Realizing that actual redevelopment of Epi-X would be months, if not years away, due to the then very disruptive agency-wide reorganization, I decided to leave so that I could gain more experience in a variety of private sector industries.

During the five years since I left Epi-X, I've worked as a senior software engineer, architect, lead application architect, and as an independent consultant. My first assignment with Abel Solutions was to re-architect and re-develop a very popular web-based electronic commerce & auction system to support more than 1 million registered users and the processing of more than 300 million dollars in annual sales. For a different company,  I re-engineered the security, object-relational, and querying architecture of a complicated human resources & payroll processing system used by thousands of companies. Most recently, I helped lead the design and development of both a modular user-interface architecture and the core service-oriented architecture for a new correspondence banking & ACH settlement platform to be used by hundreds of local and regional banks to conduct business more easily with the Federal Reserve and each other.

For the companies sponsoring the first two projects mentioned above, I introduced and lead the successful adoption of Agile management and development practices. For the third, I was recruited specifically to consult both on their adoption of Agile and the design of its new system's user-interface and service-oriented architecture.

I've also consulted with many other private entrepreneurial businesses about technology strategy, and in 2008 founded both the Atlanta Science Tavern and the ATL ALT.NET community groups.

Aligning the Agile Approach to the Business Domain

Let me be the first to state that adopting Agile in the "real world" is not easy. To be successful, you must internalize the values of Agile, especially the very first one which reads:

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

Did you notice that this specifies nothing whatsoever about writing code? It specifies nothing at all about writing code at all. It specifies delivery of valuable software.

Later on in the principles document, it says:

Simplicity--the art of maximizing the amount

of work not done--is essential.

It says simplicity is essential, not optional, but essential. How many projects have you seen that feature unnecessary complexity? That is the exact opposite of this Agile principle. For more about this problem, see my post that reviews a Skype architect's presentation.

You can read the rest of the Agile principles here: http://agilemanifesto.org/principles.html

I highlight this because a lot of practitioners think that Agile is some kind of magic bullet that will solve all the problems that sequential "waterfall" style development has. This is absolutely not the case.  Agile has its own pitfalls that must be addressed as well, and one of them is plainly that development teams don't even understand or truly believe in these two core principles!

The Core of Agile: Communication and Collaboration

As the principles in the Agile Manifesto explain, collaboration and communication are the two most critical underlying themes of agile development. What if, by communicating with your clients successfully you could help them avoid spending millions of dollars custom-developing a solution to a problem that you could solve using low-cost or open-source software?

Would that not be the ultimate fulfillment of the first principle of Agile? I think it most certainly would. And, it would certainly fulfill the later example I highlighted!

Unfortunately, many people, even managers, fail to think this way when they adopt Agile. This is not to say that they don't mean well. It's often just the case that they recognize Agile, and associated development practices like XP and TDD, as a better way of building software, but can lose sight of principle number one: delivery of valuable software.

Internalized Agility = Flexibility

True internalization of Agile values should cause architects, developers, testers, and all manner of managers to adopt an attitude of true collaboration with their stakeholders.

So, keep it mind that being agile doesn't always mean building software. First and foremost, it means delivering valuable software.