Do you suspect that your company’s commitment to agile consists of jargon and sloganeering, as opposed to actual organizational and cultural change? Then you would do well to refer to this pamphlet on Detecting Agile BS (pdf) produced by the Department of Defense’s (DoD) Defense Innovation Advisory Board (DIB) in October of 2018. The DIB established itself to bring the best practices and innovations of Silicon Valley to DoD software development. The pamphlet was the result of luminaries such as Eric Schmidt, Reid Hoffman, and Neil deGrasse Tyson coming together turning their gimlet eye towards true agile practices in DoD software development.
I’ve excerpted some interesting parts of the pamphlet below and tied in some of my perspectives based on my current TeraThink project at U.S. Citizenship and Immigration Services (USCIS). Full disclosure: TeraThink is a for-profit company, and as such is not 100%-free of BS. However, I like to think we have less BS than most. I’ll detail why through highlighting key flags that a projects is not truly agile.
Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code (acceptable substitutes for talking to users: observing users working, putting prototypes in front of them for feedback, and other aspects of user research that involve less talking).
This issue is prevalent in many large IT projects. It usually manifests itself in the guise of developers seeking input and feedback from developers. When in reality, end users should be the ones to give feedback on the application under development.
My project works closely with an application design team to build prototypes and conduct usability testing sessions with application end users. We use the feedback from the end users to adjust the design. Soon to be implemented designs are demonstrated within test environments. At these demonstrations, our product owner (PO) is present and represents the “business” or end users. Users repeat this process again on a monthly basis. Proper agile methodology depends on frequent and fast feedback from users to allow for the readjustment of requirements on an ongoing basis.
Feedback, Feedback, Feedback
Continuous feedback from users to the development team (bug reports, users assessments) is not available. Talking once at the beginning of a program to verify requirements doesn’t count!
This relates to the first point, but with the nuance that user feedback received during testing sessions/demos must lead to documented changes. We capture requirement changes either by creating new user stories to document desired enhancements or as bugs documenting the issues reported by the users.
In a large, geographically dispersed organization such as USCIS, collaboration tools such as Adobe Connect, Skype, Slack, and more are essential tools to assist with the process of ad-hoc problem reporting with the user groups. At USCIS, we use Jira to track enhancements and bugs, and attach screenshots, emails, and other information giving context and history to the Jira issue itself.
Use Your Product Owner
End users of the software are missing-in-action throughout development; at a minimum they should be present during Release Planning and User Acceptance Testing.
The above shortcoming is frequently related to the product owner. A good PO:
- Represents the business and end users of the application.
- Has the authority to make decisions on key functionality and prioritization.
- Seeks feedback proactively from users in the field and other subject matter experts (SMEs) throughout the development cycle.
At USCIS, we conduct frequent demonstrations of new functionality and bug fixes to our product owner. Our PO signs-off on completed stories after demonstration and prior to release. Furthermore, at the program level, leadership makes good use of integrated product teams (IPTs) with end users included at the increment planning level.
If you have an ineffective product owner, there are ways to still make it work. You just have to plan and work a little more.
Iterate Quickly, Together
Meeting requirements is treated as more important than getting something useful into the field as quickly as possible.
All agile teams should embrace the concept of the minimally viable product, or MVP. The MVP says that something is better than nothing. An example is having working software with a spartan user interface and limited functionality being better than feature-rich vaporware with reams of supporting documentation. The MVP gets working software in front of end users as soon as possible. Its value lies in the fact that user feedback improves future releases and helps fine-tune requirements.
Remember, the true value of agile versus waterfall is that course corrections are early and ongoing. Whereas with waterfall, if your team is off-course you likely won’t know until it’s too late.
On our project, the program has wisely decided to limit early releases to certain form types and statuses, rather than attempting an “all at once” release. We are sure to receive greater understanding of user needs from this early MVP release. We apply this understanding to our application as enhancements and also use it to inform later releases where more form types will be included.
SAFe May Be the Safest Way to Go
Stakeholders (development, test, ops, security, contracting, contractors, end-users, etc.) are acting more-or-less autonomously (e.g. ‘it’s not my job.’)
This behavior is a recognized weakness of agile. The methodology might be well-defined at the team level, but it’s vaguer at the program/management level. The USCIS initiative that our project is currently engaged in spans multiple development teams, security, user groups, and test groups. The teams are also comprised of multiple government and contractor resources.
While agile dictates that teams be “self-organizing”, the larger the program and higher the need for coordination, the more self-organizing begins to look like anarchy. TeraThink has found that applying the Scaled Agile Framework (SAFe) is one way for organizations to assert enterprise-level control over a large portfolio of agile teams.
Don’t Be Full Of It
The pamphlet continues with key questions that leadership should ask of programming teams, program management, and end users. Read the whole thing!