Agile approaches and the risk Trade-off

We were discussing Good, Bad, and Ugly on Agile. As we were, we were able to appreciate many points on Why Agile? article on wunderkrautNot setting too narrow a goal on techwell.com as well as a slightly aligned and counter article on Fixed Price Contracts for Agile Teams.

Here were some of our takeaways.

The Good – Agile helps reduce risk of not meeting project goals.

If the project goals are to stand up a new service, application, use case, workflow, visualization, data feed, or other very specific components, Agile will help you launch those specific components solving specific user stories within epic problems rapidly. You can also blend Agile development with lean to make sure you launch beta, soft, or early versions to a closed set of known users or under a brand to show to anyone. This can avoid embarrassing deployments and also expose aspects missed – negative testing (think 5year old pounding on keyboard or tablet), security testing, load testing, or experience modeling. You have a better chance of this “Agile lean” blend to finding out early on the adoption and rollout issues. The Agile Lean approach allows you to move final decisions on features and form to when you have due diligence of mockups, prototypes, or initial deployments at smaller scales, which allows you learn are you go, and decide when you know, at least investment cost.

This AgileLean 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 as the learning curve discovers problems very late in the phase, and thus causes more problems, higher cost. So if you are doing system integration with new and legacy, balance where you can and cannot use AgileLean.

Given the focus is on the project goals, don’t set the goal too narrow, and 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 hit the your defined project scope.

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

Then again, where it is bad, some of the initial scope desired was key, but turns out the architecture chosen and discovered through the learning curve led you down a wrong path, and there is a few re-starts that need to recur to introduce new patterns, components, operating concepts, etc. This could happen multiple times if the architecture reset is done with only the development and management project team. A way to avoid this is any re-architecture needs to involve the proper stake and stockholders governing and investing in the program. Whereas Agile tends to be responding to the functional manager, if the design, flow, and strategy needs to be re-set, then those questions need to go beyond the functional manager, and back to the right stakeholders.

The Ugly – Government Contracting is not ready for Agile… today

Consider if you do firm fixed price contracts, how you define deliverables up front. Articles like Fixed Price Contracts for Agile Teams give you ways to play the cards you are dealt and work within the Firm Fixed Price framework, but there is a reality. If the epics are in development, user stories unknown, specific components unknown, make sure the contracts are setup to define deliverables that show developing and deploying x # of 2 week sprints in desired environments with desired scope from clients that assumes these type of skills. Even that level of description may be complicated to reply to. How much level of effort per sprint? Are the technologies hardened or could new ones come about (Answer is the latter)? Are the sprints to productions, staging, or soft-launch? Agile development or Agile Design is VERY hard to do in fixed contracts. Legalities do tend to cause some hiccups.

Then again, 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 go out asking for the enchilada and waterfall. Its what the Contracting Officer space knows. “Systems” are being asked as the common jargon, but the layers of “services”, “components” are clearly being demarcated to help with agile bidding. This typically that does not bode well for Agile UNLESS if it prescribes system, it also “services” and “components” solution architecture principles that forces the responders to respond with an architecture that itself allows for Agile. You cannot do agile on traditional tightly coupled architectures. You end up just doing iterative instead at best which does have its differences

And somewhere in between, bidding as lowest price, technically acceptable is the WORST agile solution, as the only capability of doing that is 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, and since a Senior developer has much increased output for Agile Development that goes live, and 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, now respond to that FFP or competing it LPTA.