What makes the state of “agile” processes in modern software development so depressing is that actual agility is worthwhile and – if anybody were actually to adhere to actual agile project management principles – achievable. However, I’ve been through at least a dozen agile “transformations” over the past 20 years or so since XP kicked off this whole trend and they all end up going like this: management hires some “agile consultants” who don’t have much (or sometimes any) actual software development experience, so they see software development as sort of an assembly line process to optimize, Taylor style. Under that model, software developers are skilled (or semi-skilled) widget assemblers, and management creates tickets for the software developers to “assemble”. The agile consultant’s role, then, is to make that happen as fast as possible. Since it’s just a matter of assembling some “computer stuff”, every task is predictable: an experienced assembly line worker with one or two years of experience ought to be able to look at a widget/ticket and estimate +/- 5% exactly how many hours it should take to complete. Any widget/ticket that’s estimated > 1 day can be broken into multiple smaller tickets of < 1 day each. If this isn’t the case for any of the tickets, the whole model breaks down and, since we don’t want the model to break down, this must a priori be true: if one of the assembly line workers takes too long on a task, the fault must lie with the assembly line worker, because, the assumptions have already been established to be accurate.
This is a great document, especially with the DoD name on it to give it weight.<p>> 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.<p>This one is a largely a "comfort zone" problem IMO;<p>- Recruiting users, especially for B2C products is tricky<p>- Management get nervous about "unwashed developers" talking to customers<p>- Developers have to leave cosy offices<p>- In remote teams it's even harder<p>- It's tricky to schedule without disrupting normal work<p>- Imagining the world and designing features for it in a cosy office is a great ego trip<p>- Nobody really knows how best to interact with users<p>- Business people get nervous about developers having opinions<p>... etc.<p>Many places I've seen even Product "Owners" never talking to users and basically spending all time managing the backlog.<p>All very comfy and getting out of that comfort zone takes significant effort.<p>I once gave a talk about the fundamental flaw of much mobile app development which is summarized in this slide - <a href="https://i.imgur.com/v1qmR8m.jpg" rel="nofollow">https://i.imgur.com/v1qmR8m.jpg</a> ... 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.
Do we have any evidence that Agile actually helps, and for what kind of projects / companies it helps?<p>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.<p>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.<p>I think agile is a great way of making e commerce websites.<p>Sure, XP came out of NASA, but XP is a specific thing. Not working overtime is important in XP.<p>'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.
There are so many spot-on things in this document that I cannot share it with the appropriate people in my organization as it will be seen as an attack and offensive insult. Not sure how I could be gentle about it, it's quite damning.
Surprisingly reasonable & well written.<p>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.<p>EDIT: These actually seem like great questions to ask at an interview to a potential employer
Funny story. I once worked in a mainframe team at a large financial org that, since the company was going through a period of "digital transformation" (or some such weird corporate jargon that I have suppressed) declared itself agile and had scrums, a kanban board, a scrum master etc agile trappings.<p>... 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 love this and thanks for sharing.<p>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.
Six months ago I joined an "agile" team. The team is completely disconnected from any reasonable interpretation of agile.<p>No sprints.<p>No stand-ups.<p>No prioritized backlog.<p>No sprint planning.<p>No sprint reviews.<p>There is a product owner, who is a BA, but I never speak to her. She's on a different floor.<p>If I want to work on something, I literally have to ask the other developers if anyone has anything they need done.<p>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".<p>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.<p>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".<p>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".<p>I have an interview at another place on Friday. I think people will be genuinely surprised when I tell them I'm leaving.
FTA: A question for management: "What have you learned in your past three sprint cycles and what did you do about it?"<p>That's a <i>great</i> question for detecting "fake agile". In real agile, your process is something that you tweak and optimize as you learn things.
I'm a manager who recently transitioned my team to Scrum. I see many parallels from the doc to my team vis-a-vis the Scrum process as implemented by our scrum master. I think it's an awful process and I'm questioning whether it was the right move. I don't really see any improvements despite my engineers' desire to adopt it.<p>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.<p>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.
Given the budgetary/bidding process that funds and contracts government and especially DoD projects, how is an iterative approach even possible? How would the CO know and be comfortable signing off on saying yes, the terms of this contract are being fulfilled?
This seems to be a root document with more links:<p><a href="https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;DR_TOC_DIB_SWAP_V1.5_2019.01.11.PDF" rel="nofollow">https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;...</a><p>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 (<a href="https://innovation.defense.gov/" rel="nofollow">https://innovation.defense.gov/</a>) which consists of some big names (Neil Degrasse Tyson, Eric Schmidt, Reid Hoffman, Marne Levine, among others).
Some more detail / statements from the Board from October RE the document and efforts to combat this (imho rampant) problem:<p><a href="https://www.fedscoop.com/defense-innovation-board-wants-help-military-recognize-agile-bs/" rel="nofollow">https://www.fedscoop.com/defense-innovation-board-wants-help...</a><p>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.
I expected to find more negative examples based on the title. With that document alone (esp. last page) it's difficult to spot BS unless you get a binary yes/no answer.
Unsurprisingly, there is no notion of UX/UI design or user research or usability testing in this process at all. It makes the assumption that developers are good at everything, including all non-programming tasks.<p>This is all too common in software development, and decidedly old-fashioned thinking in the modern world of design driven development.
I work in networking infrastructure products in embedded systems. I never understood the appeal of agile/devops style development for anything whose failure has immediate and widesperead consequence. For e.g would you add features to a deployed compiler in an agile manner? (throw it out there to see what sticks?)
> Customer collaboration over contract negotiation<p>Uh, yeah. NOT!<p>This is the government. If you don't have a contract, you are not getting paid. Period.<p>Agile is great when both parties are working in good faith. Government procurement, by both law and definition, does not work that way.
I thought the DoD caught on to the fact that "agile" is, in fact, BS. Apparently not. It'll take them another decade of "sprinting" to nowhere to figure this out.