A Look Back On Agile

We were discussing the good, the bad, and the ugly on Agile. We were able to appreciate many points outlined in plenty of articles, namely: Not setting too narrow a goal on techwell. Here were some of our takeaways.

The Good – Agile Helps Reduce Risk Of Not Meeting Project Goals

If the project goals are to create a new service, application, use-case, workflow, visualization, data feed, or other very specific components, Agile will help you launch those specific components. These components solve specific “user stories” within “epic” problems rapidly. You can also blend Agile development with the “lean” method. This helps you launch beta, soft, or early versions to a closed set of known users. Or, under a brand that can be shown to everyone.

Both methods help avoid embarrassing deployments. They also expose missed aspects, such as negative testing, security testing, load testing, or experience modeling. You have a better chance of this “Agile-Lean” method finding adoption and roll-out issues early. The Agile Lean approach allows you to move forward on final decisions on features and form, when you have done your due diligence on mock-ups, prototypes, or initial deployments at smaller scales. This allows you learn as you go, and decide when you at least know the investment costs.

This Agile Lean approach works for component or service architectures. Keep in mind, it does not work for legacy architectures, where the architectures themselves are not flexible enough for agile development, refactoring, architecture, or deployment. Using Agile in these cases are actually higher risk, because the learning curve discovers problems very late in the phase. This causes more problems and runs up costs. So if you are doing system integration with new and legacy, balance where you can and cannot use Agile Lean.

Also, don’t set the goal too narrow because the focus is on the project goals. Be prepared for your requirements to change, flux, and adjust as you learn and focus on achieving that goal.

The Bad – You Will Likely Not Meet Your Defined Project Scope

Some ask, is this bad? Was the initial project scope right anyhow? Were there too many features and functions that were on the nice-to-have list that snuck into the required for business? Sometimes Agile will help trim the fat and provide focus to make sure we do not shop hungry.

The initial desired scope is key, and this is where it gets bad. Maybe, it turns out the architecture chosen has led you down the wrong path throughout the learning curve. Then there are a few restarts that need to occur to introduce new patterns, components, operating concepts, etc. If this architecture reset is done with only the development and management project team, this could happen multiple times, making this very inefficient. A way to avoid this is to have any re-architecture needs involving the proper stake and stockholders govern and invest in the program. Whereas Agile tends to be responding to the functional manager, if the design, flow, and strategy needs to be reset. Then, those questions need to go beyond the functional manager, and return to the right stakeholders.

The Ugly – Government Contracting is Not Ready For Agile… Today

Consider if your firm does fixed price contracts with the US federal government, which determines how you define deliverables up front. Many articles demonstrate ways to play the cards you are dealt and work within the Firm Fixed Price framework. However, there is a hard reality to consider. If the epics are in development, then you must make sure the contracts are set up to define deliverables that are developed and deployed in 2 week sprints. 

However, replying to that level of description in a federal government proposal may be complicated for various reasons. For example, how much level of effort per sprint does there need to be? Are the technologies hardened or could new ones come about? The answer is the latter. Are the sprints to productions, staging, or soft-launch? Basically, Agile Development and Agile Design are very hard to do in fixed contracts. Legalities also tend to cause some hiccups.


The other options of T&M have their own problems of accountability, but that is a more “mom and apple pie” argument. We are still seeing RFP and RFIs going out and asking for the enchilada and waterfall. It is what the Contracting Officer space knows. We request “systems” as the common jargon. However, we demarcate the layers of “services” and “components” to help with agile bidding. This typically does not bode well for Agile unless it prescribes system, along with “services” and “components” solution architecture principles that force the responders to respond with an architecture that itself allows for Agile. You cannot do agile on traditionally tightly coupled architectures. At best, you end up doing iterative instead which has its differences

And somewhere in between, bidding at the lowest price became accepted as the WORST agile solution. This is because it is only capable of responding to the technical specs, and not what is really needed: Agile-skilled, impassioned “Ninja” developers who can adapt to changing technologies. LPTA would bring in the Junior developer, since a Senior developer has an increased output for Agile Development that goes live, and also reduces the cost of the acceptance period as they understand how to design code for integration, negative, security, and load testing, and for the O&M teams to manage, deploy, and support.

So if you are pitching Agile, beware if the customer is saying great, because you’ll likely have to respond to the FFP or competing with LPTA.

The Takeaway

At the end of the day, you need to understand Agile in order to properly use it, like any other concept. Agile can be good for your projects, but never forget it can be bad and ugly. Keep those last two parts in mind, and you are more likely avoid any pitfalls that can break projects.