DIB Guide: Detecting Agile BS (2018) [pdf]
media.defense.gov
media.defense.gov
Implementing a process in software overwrites the tacit knowledge that may have been keeping an unworkable process running.
I laughed out load when reading the part about talking to the actual / real users in the doc. We pretty much never do that, but by God, we’re doin’ agile, ya know.
Most of the Agile coaches I think know this and just want their cash before these places sink (takes maybe 15 years, enough time for a decently long career), and if maybe one of these places is saved they can feel good. But really, I think the situation isn’t too different from what Mitt Romney’s private equity firm was accused of doing for decades (and anyone else in PE for that matter).
Thank you. This brightens my day.
Far too many companies want to appear "up-to-date" with the "industry standard", so they rename their ops team as devops and call it a day. Maybe add some automation-focused reqs to justify the change. Ops with some ansible and terraform sprinkled on top are still ops. Just call it ops.
That is true.
> and for that reason alone I have to decline good engineers
Ultimately, that's the right call. Once certain a way of thinking solidifies, it is very hard to change.
Not sure estimating tasks adds a lot of value though. But the act of listing them can refine the original estimation, so some value can be had by braking things into tasks before sprint planning I guess. Wouldn’t wast time on it for non-sprint candidates though.
But yeah, breaking a backlog down into meaningful, but minimal, issues takes some finesse.
Given the DoD's (and Government, FAR-governed) proposal process, it's exceptionally hard to get real proof that an organization knows what it is doing so language is really important. While not a guarantee, you can at least feel slightly better about a proposal that speaks the right language about these topics instead of parroting talking points that indicate less hands-on experience.
Agile vehicles at DHS and GSA have tried this but have yet to gain serious traction - I look forward to see how this evolves.
Ensuring you get the right folks on the ground / staffed AFTER the award is also part of the problem, but one step at a time!
That's what makes documents like this useful -- they provide ways for those non-technical higher-ups to start distinguishing between the projects in their organization that are pretending to change, and those that are actually changing. Which (hopefully) will help them start pointing those incentives in the right direction.
> Key flags that a project is not really 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.
This one is a largely a "comfort zone" problem IMO;
- Recruiting users, especially for B2C products is tricky
- Management get nervous about "unwashed developers" talking to customers
- Developers have to leave cosy offices
- In remote teams it's even harder
- It's tricky to schedule without disrupting normal work
- Imagining the world and designing features for it in a cosy office is a great ego trip
- Nobody really knows how best to interact with users
- Business people get nervous about developers having opinions
... etc.
Many places I've seen even Product "Owners" never talking to users and basically spending all time managing the backlog.
All very comfy and getting out of that comfort zone takes significant effort.
I once gave a talk about the fundamental flaw of much mobile app development which is summarized in this slide - https://i.imgur.com/v1qmR8m.jpg ... the "older generation" making apps on big screens, fast networks while sat a desk for a younger generation on the move, that barely knows what a mouse is.
On every new project (usually internal enterprise software) I plead to let me talk to the users. Every time in vain.
It probably won't get you fired outright, but does destroy the goodwill that you will need to make meaningful changes down the road.
Now, if you can do it without rocking the boat (perhaps without management ever finding out) then go for it.
[1]which does have value, but not necessarily value to the customer.
it's unfortunate that your organizational structure prevents you from doing so.
Related: You might've already come across it, if not, I suggest reading this paper (it's not about any specific technical topic, but more about the thought processes) from Peter Naur, titled: Programming as Theory Building.
The experience was great and I’m trying to do the same at my new job. If anyone has the chance or can convince their managers I’d jump on it immediately.
It's just I note this is a DOD document, and I don't think we should be desiging jet fighters in 2 week sprints. Airframes probably can't be modified like that. So it follows that, within a waterfall project, the flight software shouldn't be developed agile either.
Beyond that, I don't think safety critical systems should be produced code first. We should probably be doing modelling and formal verification and stuff like that.
I think agile is a great way of making e commerce websites.
Sure, XP came out of NASA, but XP is a specific thing. Not working overtime is important in XP.
'Modern Agile' on the other hand cares about things like producing an MVP and iterating, which originated in and are appropriate in a web startup context. I'm not sure they should be forced in an engineering context.
Do you have any basis for that position? I think using agile principles (ie making small modifications and testing them frequently to get feedback) seems like a great way to design a complicated piece of machinery.
Its a terrible, terrible way to try to design complex control systems. They must be studied and modelled and analyzed by experts in processes that have absolutely nothing to do with '2 week sprints'. =
To have a "complete" design (what does that even mean), you need perfect requirements (what does that even mean), and perfect requirement collecting has been many many times proven to be virtually impossible. You'll get an imperfect design that you'll have to work around.
In addition, you'll have waited god knows how much time for those design, while you could have been developing stuff and validate that it actually solves problems for your users.
Agile is not about making devs into assembly line workers, nobody's pretending that works (though some people are still trying to do it without realising it)
Some managers definitely think agile processes are about making developers into interchangeable widgets and maximizing their efficiency.
I agree that this is close to the opposite of the original intent.
I grok the value of learning more as you explore the solution, but there’s a huge value in planning as well as you can ahead of time. The cheapest code to change is the code you never mistakenly wrote in the first place.
There are definitely many tight feedback loops that are necessary, whether they are 2 weeks or longer. Things get tweaked all the time, especially in production. There's stuff that don't show up in testing, and there's cases that cannot be anticipated. There's definitely some control analysis to identify default tuning parameters, but the proof of the pudding is in the eating. The design tuning parameters are only initial values -- they are tweaked online while the plant runs.
There's an upfront spec but that spec only provides guidance. The real world will often surprise you. There are elements of waterfall at play, but the entire process by necessity cannot be waterfall.
In my experience (25+ years now), an awful lot of people who are looking into adopting Agile processes are actually in the midst of grasping at straws/looking for a silver bullet. The "problem" they have is that software development takes longer than they want it to and no matter how hard they beat the programmers, it keeps taking longer than they want it to. So "agile" is just the newest cudgel.
Maybe they should try not beating the programmers. I'm just saying...
Who is making this claim?
One magical day the consultants and all and any mentioning of agile, scrum, etc just disappeared like it never happened, just like a bad dream, and we woke up and smelling roses again...
Any meaningful progress on a project subjected to agile/scrum is possible only to the extent to which the project violates the agile/scrum process.
Of course you're very welcome to tell me that we weren't doing Agile/Scrum right...
Is it possible to build software successfully without agile processes? Also yes.
The point is that, blaming agile for your failure is about as pointless as saying agile is a saviour. Any corporate forensic anthropologist would need to look at a lot of process, incentive, and organizational specifics to know what was and was not working in either case.
not really. Until of course your software is simple - ie. 1. doesn't have any significant internal nor external dependencies being developed as part of the same project/during the same time and 2. any feature can be done by a one "full stack developer".
Agile/Scrum don't provide for dependencies management, and when implemented thorough and correctly the Agile/Scrum actively and severely impedes dependencies management.
>The point is that, blaming agile for your failure is about as pointless as saying agile is a saviour.
I'm not blaming Agile. The Agile in our case of various mildly to really complex enterprise software projects worked exactly as designed - ie. practically halted down any progress of the projects.
I'm blaming the people who decided to implement the Agile/Scrum in our company when it is an obviously unsuitable process for any minimally complex projects.
Besides the above mentioned dependency management issue, the Agile/Scrum main effort is directed toward dramatically lowering of the latencies in the dev process (which main effect is totally transparent always up-to-date status - management's wet dream, and boy, did we have it!) while promising bandwidth/throughput (productivity) increase at the same cost (i.e. the same developers/teams).
The fallacy of "it is possible to pick all the 3 at the same time" - the lower latency and increased bandwidth/throughput while keeping the same cost/hardware - would be easily recognized by any normal engineer in the context of a normal engineering problem. Yet when it comes to process management, many otherwise reasonable engineers do unexplainably believe in the pixie dust of Agile/Scrum.
When somebody says "we're successful and we're using Agile/Scrum" it has always (until it is 10x dev case described below) been the case in my experience that hey do have significant deviations from a complete thorough Agile/Scrum implementation and those deviations provide the "breathing windows" which allow for their survival.
Another situation of "we're successful and we're using Agile/Scrum" is that the companies employing "10x" developers, like Google, FB and many well-funded hip startups can allow themselves to decimate the engineers' performance/bandwidth/throughput even by say 5 times (by the combination of factors like open floor office, Agile/Scrum process management, etc.) and they would still be left with effectively "2x" performing developers which still allows to be pretty successful. Similar scale decimation of performance/throughput of a typical "1x" developer at a typical BigCo like say ours naturally leaves you with "1x/5" :)
This is false, and I believe you are generalizing your experience far beyond what can can realistically concluded.
You experienced a systemic halting of productivity across an organization. That is a very UNIQUE experience. It’s worth discussing, because I don’t think it is clear what happened. your posts are making very broad postulates about agile just not being applicable rather than getting into specifics, and that’s a shame.
Software ranging from operating systems, to artificial intelligence, to medical systems, to military systems are being developed with agile software processes. Some of these have higher regulatory documentation and certification requirements than others. Those aren’t incompatible with the agile that I’m familiar with.
> Agile/Scrum don't provide for dependencies management, and when implemented thorough and correctly the Agile/Scrum actively and severely impedes dependencies management.
Firstly, one team’s use of Scrum might be agile, but Agile is not Scrum. If someone applied Scrum blindly and decided not to include any other processes not in Sutherland’s or Schwaber’s books, or what some coach told your management, that indeed would be risky.
Scrum is a rather tepid version of Agile that is incomplete in its description of the practices of successful software development, compared to something like XP, and even XP doesn’t cover everything exhaustively.
Secondly, Your point about dependency management is insightful. I think it has more to do with management ignorance about applying Scrum blindly rather than seeing it as a tool in a toolbox.
Scrum basically has nothing to say about dependency management. XP has some stuff to say about it, some pretty important insights around continuous integration, but not a ton. This is not to say that dependency management suddenly doesn’t exist or should be banned because an agile author hasn’t said anything about it. Published topics and books need to have boundaries, even though product development itself doesn’t have the same luxury.
Various contemporary or follow-on ideas and professional movements such as design structure matrix (DSM), lean product development, API-first design, consumer-driven contracts, continuous delivery, microservices architecture, all have more to say about dependency management. These are not incompatible with agile processes.
I don’t think it requires 10x developers to be successful with agile.
> The Agile in our case of various mildly to really complex enterprise software projects worked exactly as designed - ie. practically halted down any progress of the projects.
The agile in my case is completely foreign to this experience. It involves systems software with millions of lines of code and coordinating across over 80 teams on subsystems, shipping minor updates daily and major updates quarterly. With all shapes and sizes of programming expertise. It is possible, and it is done.
If projects halted and weren’t showing progress, there is something systemically wrong in the organization that’s far beyond what’s being discussed here.
Sounds like management halted a process that was at least moderately successful and tried to replace it with something incredibly under-baked. Rather than incrementally and iteratively introducing the new process to a set of subsystems, with the ability to use old / proven practices where you had no clear better alternative.
The F35 might be the first plane in history where the software costs more than the airframe development. It's difficult to find a detailed breakdown, but example numbers include
https://www.theregister.co.uk/2018/03/22/f_35b_block_4_upgra... "Figures reported by The Times newspaper pegged US estimates for upgrades to the supersonic stealth fighter at £7.67bn ($10.8bn) for software development and £3.84bn ($5.4bn) for deploying those upgrades across all F-35s ever built."
And that's just an upgrade. Now, arguably you don't want to be too agile with the avionics either, but at some point the cost of not delivering anything that works becomes prohibitive.
An upgrade is additonal work right? Like, an extra sprint. It turned out to be crazy expensive.
The F35 programme went wrong because they built an MVP (F35A) and then decided to derive 2 extra planes from that design (F35 B and C). Turned out that modifying an existing air frame to make it VTOL is really hard and they would have been better off designing a new plane from scratch.
As you say we weren't there, don't have the data, and judging the facts from a noteably freakishly unsuccesful programme isn't sensible but... I mean, I think it supports the idea we shouldn't do this.
Then make the sprints longer. IMO, the Apollo project was run in an agile fashion (“They want us to send men to the moon, but we can’t go there, nor send men up. What baby step can we make instead?”)
[1] https://en.wikipedia.org/wiki/Iterative_and_incremental_deve...
You are probably talking about consumer gear. Consumers usually have two requirements: a) FEATURES FEATURES FEATURES. All of them. 200 beamforming antennas. Interplanetary internet. b) Price. All of the above for the lowest price possible. FTL communication? Cool. It better be under $50 or I'll buy the competitor.
So this is what the companies optimize for. Who cares if DHCP is broken if it works most of the time. Memory leak? Just have it reboot. IPV6 broken? Most customers won't even know or care.
You'll find that 'enterprise' hardware performs way better. At a price premium.
"Finish twice the average stories per month and you get a bonus!" People game the rewards system by generating smaller, achievable stories. I had a colleague once who [0] would save up test cases (we were on the V&V side) to develop that were smaller. He could've had them all done and delivering value in two weeks, 200 test cases done! But if he did that he'd be left with the remaining 50 test cases that each needed 1-3 weeks to develop test systems for (sometimes shorter, I think 2 weeks or so was the average). So if he found himself looking bad on the burndown chart, he'd churn out 20 finished test cases from the easy ones. This way he was always "on track". If he'd done them and gotten ahead, they would've wondered why he slowed down (because not all test cases had the same size, duh) and penalized him for it.
The problem is, that goals like that (as carrot or stick) don't change the fundamental system. If I manage to churn out 20 story points this week, but only 10 every other week, is it sustainable? Was it a fluke? Was it because I did 40 hours of OT? Or was it that they were overestimated? Maybe I had a unique skill set or insight that let me solve it more quickly than had been anticipated. Maybe something in my brain clicked (remember that moment early in your career where a "hard" concept suddenly became obvious, and all your programming tasks became much easier?) and the new level will be sustainable.
On the other hand, if you create a goal to double efficiency/capacity and provide access to resources to change the development/deployment/whatever system then you can get something useful.
I wrote a tool for data analysis for a project (actually a collection of related projects). The tool cut down test analysis time from hours to minutes. An activity done daily by the V&V team. I saved them years of work in that first year. The goal was to reduce the bottleneck (test results took too long to get so developers were waiting or operating blind). That goal, by itself, was worthless. It was only able to change the system of that team because I had been given permission to work on tools that would achieve it.
[0] We had a manager who did things like this, though no carrot all stick.
But once the outer mold line is set and prototype construction starts the engineers must be far more cautious about design changes.
Agile is not 2 week sprints. Agile is not code reviews. Agile is not pair programming. Agile is abstract; it's a set of values, a philosophy, a methodology. It screams, "Stop just following some stupid formula, because it may not work for you!" The whole point is to shake up the slow, rigid, inefficient way that organizations can easily fall into, and get people to work together better. If you take the guidelines it offers and apply them, any organization can benefit. But you can't just follow a formula and be magically better.
What I've learned is that all of the abstract methodologies (agile, lean, devops, etc) do not prescribe specific actions you must take; they prescribe general ways that you can adapt your work to get better outcomes. I can't give you exact evidence that it works, because there is no one way that it works. But there are tons of organizations that have followed the principles and have measurably improved their businesses. Until someone turns all of business into a science, I don't think you'll find anything better.
For me, there is only 1 true rule in Agile: good retrospectives!
Once you have good retrospectives, you can improve anything within the process. Any argument about "We cannot do 2 week sprints" falls out, because your team can decide whether 2 week sprints is in your best interest.
This is interesting. Is this a hypothetical notion or can you share any personal experience of having worked on any projects where this is done successfully?
I bring this up because there is typically a narrow band of applicability of purely theoretical constructs in most complex systems (AWS & Azure teams both use formal methods [1] to find bugs and to increase confidence in critical algorithms but I don't believe they do this system-wide. Also the verification is only done on the abstraction, not the actual implementation.).
Richard Cook gave a talk on "How Complex Systems Fail" [2] which addresses this point, and advocates for designing for resiliency as opposed to designing to exhaustively handle all failure modes (which are impossible to predict).
Design people often design from some idealized notion of inputs and/or worst case scenarios.
Ops people know what can go wrong will go wrong, which is why ops is there to handle the deviations from the norm. Real world design exposes lift points, reveals controls and supports continuous maintenance.
Highly reliable systems are evolved, not just designed.
This is the Erlang design philosophy.
Agile attempts to turn the implicit requirements development into explicit requirements development. It tries to shortcut the process of acquiring requirements by getting stuff in front of the user as fast as possible.
Now, if you really do know the requirements (like there's a real spec to follow) or you're in a situation where you don't have the architecture decided so that you can show discrete things in a small time window (2-3 weeks), then agile isn't nearly as useful.
That's a damned lie. Iterative and spiral development greatly pre-date web development. They pre-date the Web itself for software (though perhaps not the Internet, or at least Arpanet). Iterative and spiral development is the only sane way to develop any complex system (or at least to develop its specification). Agile is a further extension of that whose proponents further work to breakdown the knowledge and communication barriers that inhibit effective project development and management.
There are some linked documents at the end of the OP, and this one with link "to be added"[0]. It addresses your exact point, in that hardware development and software development have to move in completely different processes. Their first example is the DoD 5000 process[1] and how it is a total fail for software:
"The DoD 5000 process , depicted on the left, provides a detailed DoD process for setting requirements for complex systems and ensuring that delivered systems are compliant with those requirements. The DoD’s “one size fits all” approach to acquisition has attempted to apply this model to software systems, where it is wholly inappropriate. Software is different than hardware. Modern software methods make use of a much more iterative process, often referred to as “DevOps,” in which development and deployment (operations) are a continuous process, as depicted on the right. A key aspect of DevOps is continuous delivery of improved functionality through interaction with the end user."
"DoD 5000 is designed to give OSD, the Services, and Congress some level of visibility and oversight into the development, acquisition, and sustainment of large weapons systems. While this directive may be useful for weapons systems with multi-billion dollar unit costs, it does not make sense for most software systems."
[0] https://media.defense.gov/2018/Nov/02/2002058905/-1/-1/0/DIB...
[1] http://acqnotes.com/wp-content/uploads/2014/09/DoD-Instructi...
I worked for a huge Brazilian ERP company. Three years ago the board decided that the company was not realizing its full potential (which I agree with) and decided to give Agile a try.
Since then, some really critical areas started to suffer a lot, the latest version is being heavily criticized by the users and the company's reputation is consistently going down.
The answer seems obvious: they are doing Agile wrong, they missed the point entirely, the "big company" mindset is hindering the efforts and so on. This is, in fact, how the whole company is behaving about the poor results so far, treating any suggestion towards a Agile's rollback as a cabal proof of the company's inability in delivering software the proper way.
But I dare to think that Agile might not be the only path. Most of the companies around are delivering fairly complex projects employing small and efficient and competent teams and this is really great.
But some companies are not that lucky. Somebody has to build that monstrous stuff over two-decade-old legacy code foundations, employing many dozens of teams.
You simply can't afford hiring the best people around, because they are not available nor willing to work for you and, anyway, there aren't enough of them.
You can't work with the best users, because you have no control at all over their teams and they aren't too excited about you bothering them with your project -- and this is bad because users in Agile projects are a critical part of the team.
You may somehow enforce them to work with you and this has already been made many times, but the resultant half-hearted participations are not worth the hassle.
There are so many practical issues regarding a real-world agile culture implementation, so many out-of-control environmental variables affecting you very negatively, and they all seem to end up being buried under a set of principles which have allegedly worked somewhere else. As if it were easy, or even desirable, to blame your context for not being "mature enough" to adopt Agile.
I've never seriously looked into it, but I believe that there are some rigorous academic case studies discussing cases where agile didn't work well. Although I believe they are scarce, both because Agile tend to fail in a smaller, yet important, set of projects, and also because they would hurt some strong beliefs which are currently being taken as common-sense.
I also believe their analysis may occasionally show some bias too, perhaps focusing more on the "mistakes" made by the teams instead of considering the hypothesis of Agile being inappropriate in the analyzed case.
I wonder who wrote this, sounds like a person with extensive experience with contractors that sell themselves as 'agile' but really have no idea what the term even means.
EDIT: These actually seem like great questions to ask at an interview to a potential employer
I see Neil deGrasse Tyson and Eric Schmidt on there, but I very much doubt they've seen this document.
(And agreed these are good questions for would-be employers. But if you do ask them and refuse to work in a non-agile shop, you'll find precious little outfits to work for.)
... and ten-page long Word forms with 15-item drop-down lists that had to be filled in before a single line of JCL could be changed (we did not touch the COBOL. Nobody touched the COBOL).
I'm glad that we're starting to develop a backlash to "Agile Industrial Complex" and "Dark Scrum". At the end of the day, it may be hopeless though. Being able to read and internalize the Agile manifesto is hard. Just like design thinking is way harder than process thinking. Successful companies will empower developers, middling to failing companies will continue to view them through Taylorism.
I fear it is hopeless. After all, XP - which morphed into the umbrella term "agile" - was a direct response to the failings of the software project management fads of the time... which are exactly what has been warmed over and served up as "agile" now, 20 years later.
No sprints.
No stand-ups.
No prioritized backlog.
No sprint planning.
No sprint reviews.
There is a product owner, who is a BA, but I never speak to her. She's on a different floor.
If I want to work on something, I literally have to ask the other developers if anyone has anything they need done.
When I joined the team, we had a project manager who would create tasks in jira and assign them to individuals. When the task was finished, we assigned them back to the PM so he could assign them to a tester. The tasks were already broken down from user stories so I would often get "implement REST service for X" and someone else would get "implement web page for X".
We have a new project manager who doesn't like agile. He is currently "resetting" the project by forcing the business to write a complete set of detailed requirements. They have until June 30 to finish that. In the meantime, the team will continue in a kind of limbo of "agile" but the PM has already committed the team to completing the project by Dec 31st even though the requirements won't be finished until Jun 30th. The budget is also fixed.
I've asked the team why we don't do any of the agile things. Normally you'd at least get cargo cult stand-ups. They said they don't see the value in it. They've all been working on the project for 2+ years so they know what needs to be done. I pointed out that it makes it impossible for me to participate in the project in any meaningful way since I'm reduced to begging for work. They don't see a problem with that. "Just ask".
Because it's "agile" there is no up-to-date technical documentation. So to get anything done (once I have work to do) involves finding out who in the team knows what I need to know and interrupting them. The guy who knows the most is a terrible communicator. "Just ask".
I have an interview at another place on Friday. I think people will be genuinely surprised when I tell them I'm leaving.
That's a great question for detecting "fake agile". In real agile, your process is something that you tweak and optimize as you learn things.
It seems to help junior engineers by making them comfortable tackling unfamiliar systems and code. However, it's completely slowed down my senior engineers. I feel Parkinson's Law (work expands to fill the time allotted for it) creeping in. The scrum master encourages the engineers to be conservative in their sprint workload.
I suspect if my engineers were more enthusiastic and proactive, it might have paid off. However, I think enthusiastic, organized and proactive engineers don't need any process to be productive.
You should definitely get rid of all of them. They're holding you back. Free them to pursue other opportunities, because it's obvious that you would be taking over the world if you weren't hamstrung by lazy, coddled, overpriced, whiny complainers. After all, even if you don't have the budget to offer what the absolute best and brightest might command somewhere else, I'm sure that the most talented engineers would jump at the opportunity to work for and with a true visionary like yourself.
I've worked with these engineers for the past 5 years as a technical lead and as their manager. I'm thoroughly qualified to pass critical judgment on them. I instituted Scrum because they asked for it thinking it would be helpful. It hasn't had that effect. My point was that process means little if your people aren't engaged.
I understand the point you're driving at, but process is essential. It makes bad engineers less dangerous, and good engineers more productive.
They definitely do: I'm currently working with a team of enthusiastic, organized and proactive devs and they are delivery at a crawling pace due to the lack of process.
Who thinks I should show this to my manager?
https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;...
After having worked on government contracts for many, many years - this is an amazing leap forward - I had to do some googling. DIB is the Defense Innovation Board (https://innovation.defense.gov/) which consists of some big names (Neil Degrasse Tyson, Eric Schmidt, Reid Hoffman, Marne Levine, among others).
https://www.fedscoop.com/defense-innovation-board-wants-help...
This was fun to read. I think the charge will be led by a few areas within DoD that have been newly stood up but it doesn't take long for something that works and is shiny to become a best practice especially if it brings money in the budget along.
This is all too common in software development, and decidedly old-fashioned thinking in the modern world of design driven development.
That being said, I agree that it's assuming a lot from developers, but that's a working recipe for a successful project. If you have another way, please do share it :)
I never said anything about "caveman dev." Software development is a challenging area, but being good at creating software does not make you good at other things. Some industries, like game development, have long had cross-functional teams where developers, designers, artists, writers, all work together.
In my opinion, any agile process that doesn't address UX design is outdated.
Uh, yeah. NOT!
This is the government. If you don't have a contract, you are not getting paid. Period.
Agile is great when both parties are working in good faith. Government procurement, by both law and definition, does not work that way.