A Look Back on Agile
We were discussing the Good, the Bad, and the Ugly on Agile. As we were, we were able to appreciate many points outlined in the articles Why Agile? article on wunderkraut, Not 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”. This helps you launch beta, soft, or early versions to a closed set of known users. Or, under a brand to show to anyone. Both methods can avoid embarrassing deployments. They can also expose aspects missed such as negative testing (think 5-year 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 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 as 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.
Given the focus is on the project goals, don’t set the goal too narrow. Also, 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, 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 scope desired is key, this is where it gets bad. Perhaps it turns out the architecture chosen and discovered through the learning curve led you down a wrong path. Then there are a few restarts that need to occur to introduce new patterns, components, operating concepts, etc. If the architecture reset is done with only the development and management project team, this could happen multiple times. 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 reset. 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 with the US federal government 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 hard reality to consider. If the epics are in development, user stories unknown, and specific components unknown, then make sure the contracts are setup to define deliverables developed and deployed in 2 week sprints. However, replying to that level of description in a federal government proposal may be complicated. For example, 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. However, the layers of “services” and “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. This is because 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 responding to that FFP or competing it LPTA.
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.