Say you’re standing up a software development team. You really like the agile approach, but your customer didn’t read my previous post about agile contracts. Can you still use agile or are you stuck developing a waterfall-based program plan?
Agile vs waterfall
In a traditional contract, the requirements are laid out from the start. The development team is on the hook to meet those requirements within the set schedule and budget. This suggests a “waterfall” approach, linearly moving from requirements to design to development to verification. With proper planning, the team will deliver the promised capabilities. However, incorrect assumptions early on can result in an ineffective product after considerable investment.
In an agile approach, the basic concept is defined but specific requirements are not. Teams strive to create a “minimum viable product” which they can offer to users to learn about their behavior. The team discovers as they go and adapts the development accordingly. Incorrect assumptions are quickly identified and the system reworked. Good assumptions are validated, strengthening the product.
Traditional, requirements-driven contracts generally do not support an agile approach. This is primarily due to the incentive structure. The contractor’s performance is evaluated against the requirements. There’s no bonus for meeting user needs, but there are heavy penalties for not meeting contractual obligations. Naturally, management focuses on fulfilling the requirements within budget and schedule.
Can agile work anyway?
But you really, really want to use agile. The hard truth is that most agile efforts within a traditional contract are agile-in-name-only. They write user stories, work in sprints, and hold daily scrums. But their actual process more closely resembles waterfall. Here are the ugly details:
The product owner
In an agile process, the product owner lays out the vision and represents users in between user engagements. They encourage adding items to the backlog and prioritize the backlog to maximize user satisfaction.
In agile-in-name-only, the product owner is a systems engineer ensuring that all of the requirements are addressed. They act as a gatekeeper, rejecting items as “scope creep”.
User stories
An agile user story describes how the user approaches and intends to utilize the system. It shifts the emphasis from the system’s functionality to how the system serves the user.
An agile-in-name-only user story is simply a re-written system requirement. For example, ‘The system shall have feedback latency of less than 500ms’ would become ‘As a user, I want the system to display feedback in less than 500ms so that I know my command has been received.’
Interpreting requirements
Agile emphasizes meeting user needs and wants. User stories are decomposed, discussed within the team, and shared with users. Functionality that doesn’t meet the user’s intent is quickly discovered and will be reworked until it does.
Agile-in-name-only development teams do their best to understand requirement intent, but rarely have an opportunity to engage with users to better understand their needs. Functionality which doesn’t fit the user’s needs or wants isn’t discovered until much later, by which point design decisions are already solidified. Meeting the letter of the requirement is more important than meeting the needs of the user.
Metrics and evaluation
Agile teams evaluate themselves for both continual improvement and management reporting purposes. They use agile metrics such as cycle time, velocity, and defect discovery.
Agile-in-name-only teams may also evaluate themselves with similar metrics, but their management is more concerned with traditional metrics: lines of code, requirements met, budget and schedule, etc.
Own your process
There are many more indicators of agile-in-name-only. The Defense Innovation Board recently published a draft Guide to Detecting Agile BS. There are similar guides around the internet. Take a moment to evaluate your own team and processes.
Realize that an agile process inside a traditional contract can never be more than agile-in-name-only 1. Trying to implement agile anyway closes you off to other ways of doing things which might be more suited to your project.
Instead of pretending to do something you don’t, own your process. Consider spiral development, which many agile-in-name-only efforts more closely resemble. Tailor your approach with best practices from across the industry which support your unique project.
And keep clamoring for true agile adoption in government contracts.
Do you disagree? What are some other key indicators of agile-in-name-only? Are there alternative development approaches which are good to use on government contracts? Share in the comments below!
Footnotes: