13 ms·
DIB Guide: Detecting Agile BS (2018) [pdf]
- okl 8y agoI 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.
- commandlinefan 8y agoWhat 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.
- pjc50 8y agoIndeed, it all breaks down because of the Taylorist approach. True agility would recognize that most of the time software is implementing a "business process", and that there are real benefits to being able to change the process outside of the software. There is also usually a chunk of "tacit knowledge" - how the workers actually implement the process differs from the official manual in ways that are not usually written down and that management don't know about (indeed usually insist that they are kept hidden, by punishing deviation from the written process while ignoring feedback). Implementing a process in software overwrites the tacit knowledge that may have been keeping an unworkable process running.
- Roboprog 8y agoOne of the most spot-on comments I’ve read in a while. 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.
- okl 8y agoI have seen the model break down while working in small, heterogenous teams. Work is assigned "automatically" to the person that will inevitably do the work, consequently team members refrain from judging work done by the specialist in the team, and so on until you can throw all the typical "scum tools" into the garbage bin. Turns out a kanban-style division of labor approach is sometimes preferrable... But is that agile? Depends on who you ask.
- BurningFrog 8y agoAs someone who has had the fortune of working on real agile teams, this has the same relationship to that as the German Democratic Republic had to Democracy.
- devonkim 8y agoYour reasons for why “Agile” isn’t working is the same for why “devops” isn’t working - the enterprise refuses to let go of fundamental practices and assumptions of Taylor work models where planning is centralized by a manager caste and concerns for individual contributors are mostly cast aside (Deming’s approach is the opposite and is what the Japanese auto makers used to improve quality and dominate the US auto market in a matter of a decade). Furthermore, a great deal of the places in a crisis (seriously, why go through an expensive transformation if you’re fine?) have lost most of their software craft and are culturally bankrupt to do much more than manage things and watch them fail. Execution on anything besides sales is missing completely while an offshore team or a bunch of engineers too tired / hungry / captive to protest their conditions are dragged through it all. 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).
- outworlder 8y ago> Your reasons for why “Agile” isn’t working is the same for why “devops” isn’t working 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.
- nineteen999 8y agoAs far as industry snake oil terms go, at least "agile" is a dictionary word. "Devops" is merely a portmanteau of two abbreviations.
- devonkim 8y agoHaving tried to hire for a team that is focused on operations there’s a huge world out there full of engineers that have hid their head in the sand about configuration management, infrastructure as code, etc. They may have managed a lot of network devices, SANs, AD and Exchange clusters, etc. But devops really started within the software community fundamentally rather than the modern sysadmin one and there’s a lot of distinct differences in mentality that shows. This doesn’t mean one is better than another but if tou’re in the technology field it is imperative that you stay up to date on what’s going on even slightly adjacent to our respective fields. This has been lost on a lot of otherwise excellent sysadmins though, and for that reason alone I have to decline good engineers - attitude and perspective over a long career being unsuitable for the company I’m hiring for.
- 29athrowaway 8y agoYou can become a "Certified ScrumMaster" after a few hours of training without active participation in developing software. That is a big part of the problem.
- iredwards 8y agoHey, I'm a "Certified Product Owner" too.
- darioush 8y agoEach time I hear something about breaking down tickets to things that can be done < 1 day you end up with an unorganized pile of tasks, that someone thought must be done in a short amount of time. Usually this happens in stark contrast to the lack of a prioritized list of (meaningful, valuable) things to do.
- CuriousSkeptic 8y agoI find estimation and size limits to be good QA. It kind of forces you to flesh out unanswered details. So I use it as a tool for that. 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.
- sailfast 8y agoYou make a good point about the consultants without experience and I think this document is working toward fixing it: make sure you ask the questions that ensure contractors (especially) demonstrate they have done this and know what they're doing, rather than relying 100% on the proposal. 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!
- smacktoward 8y agoChanging is hard. Pretending to change is much easier. And frequently the people in the organization high enough up to dole out rewards (promotions, bonuses, etc.) aren't sophisticated enough technically to tell the difference between real change and pretend change. So the incentives all run towards doing the pretend change, grabbing the rewards, and then leaving a mess behind for someone else to clean up later. 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.
- montenegrohugo 8y agoSurprisingly reasonable & well written. 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
- pjc50 8y agoThe actual author has been scrubbed, presumably as part of the declassification, but the organisation responsible is https://innovation.defense.gov/ https://innovation.defense.gov/ I see Neil deGrasse Tyson and Eric Schmidt on there, but I very much doubt they've seen this document.
- AndrewKemendo 8y agoProbably Josh Marcuse or someone on his team. He's the Civilian Permanent Chair of the DIB for the DoD.
- ddebernardy 8y agoI wish it was only contractors. I've seen my fair share of startups over the years that were nothing but. And heck, I'm no agile specialist by any stretch, and I'm often first to point out how god awful it's being implemented in practice. But the one thing I grokked about it is that if you're not talking to end-users each sprint you're not agile plain and simple. (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.)
- nikk1 8y agoI'm working for a large defense contractor. We are adopting an "agile framework" (this is being pushed on us by upper management) and I've been going nuts over how nobody around here seems to understand the true agile philosophy. I'm really glad the DoD recognizes how to spot good software development.
- williamdclt 8y agoI was telling myself the same thing, even if I'm not expecting a potential employer to actually do all of that, their reactions and answers probably will say a lot about the culture of the company
- whieee 8y agoSurprisingly clear document, completely free of BS itself.
- okl 8y agoExcept for the title.
- Quarrelsome 8y agoyou wanna do it in less words while retaining the precision?
- okl 8y agoThe title literally contains BS. So… Whoosh!
- Quarrelsome 8y agooh I getcha, my bad :D
- ionforce 8y agoWhat does DIB mean?
- g_b 8y agoDefense Innovation Board
- harryf 8y agoThis is a great document, especially with the DoD name on it to give it weight. > 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 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.
- martin_drapeau 8y agoYou are correct. As a company grows, process starts taking over talking to users. Change becomes a disturbance and backlog grooming more important. I say measure traction with the user and make that the focal point. The rest is secondary.
- perfunctory 8y ago> Nobody on the software development team is talking with and observing the users of the software in action On every new project (usually internal enterprise software) I plead to let me talk to the users. Every time in vain.
- fouc 8y agoIf the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.
- shubb 8y agoDo we have any evidence that Agile actually helps, and for what kind of projects / companies it helps? 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.
- Kalium 8y agoEven the DoD has plenty of fairly generic webapps it needs developed and maintained. I worked on one that was "agile" - it definitely ran afoul of some of these pointers.
- t0mbstone 8y agoWell, yeah... I would imagine that's why this document exists and they are attempting to push it for the 2019 and 2020 agenda
- fouc 8y agoPresumably Agile is for software projects, not hardware.
- howard941 8y agoIME this is not a good presumption. I'm aware of its use at one local manufacturer of electronic medical devices, another that makes fire protection systems, and another that makes those ankle bracelet tracking things.
- mi100hael 8y ago> 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. 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.
- aristophenes 8y agoThere 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.
- ahi 8y agoThe DoD source gave me just enough cover to share it as general interest material.
- okl 8y agoIn my experience it's counterproductive to force the issue and antagonize the persons you need to win over. But if you want to do it: I've had good experience in the past with putting such information in circulation (under false premise) and then playing Columbo, "Oh really? I thought we were already doing agile programming?"
- harryf 8y agoYou could anonymously print it and stick it on the wall next to the coffee machine
- aristophenes 8y agoUnfortunately I work remotely. I think my wife would suspect it was me ;)
- winslow 8y agoI was really hoping DIB stood for Department In Bullshit.
- TheSoftwareGuy 8y agoI work for a defense company and this pretty much describes our development flow. Who thinks I should show this to my manager?
- okl 8y agoConstant dripping wears the stone is my advice. You have to phrase/wrap your critique in positive words or your opinion will be met with disdain.
- Yoms 8y agoThis seems to be a root document with more links: https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;DR_TOC_DIB_SWAP_V1.5_2019.01.11.PDF 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/ https://innovation.defense.gov/) which consists of some big names (Neil Degrasse Tyson, Eric Schmidt, Reid Hoffman, Marne Levine, among others).
- mshockwave 8y agoJust feel amusing this was written by DoD
- nwhatt 8y agoI love this and thanks for sharing. 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.
- commandlinefan 8y ago> it may be hopeless though 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.
- AnimalMuppet 8y agoFTA: A question for management: "What have you learned in your past three sprint cycles and what did you do about it?" 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.
- draw_down 8y agoRinging the "bullshit" buzzer is a lot easier than believing in something, that's for sure.
- James_Owens_69 8y agoAnother bullshit label. I prefer working with normal people you know? Back in my days coders managed to produce good code while eating pizza and not dealing with retards.
- kvhdude 8y agoI 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?)
- sailfast 8y agoSome more detail / statements from the Board from October RE the document and efforts to combat this (imho rampant) problem: https://www.fedscoop.com/defense-innovation-board-wants-help-military-recognize-agile-bs/ 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.
- obelos 8y agoGiven 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?
- kradroy 8y agoI'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. 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.
- winrid 8y agoYou hit the nail on the head. Hire the right people, keep the teams small, and you can just give them context and let them solve the problem.
- commandlinefan 8y ago> completely slowed down my senior engineers > if my engineers were more enthusiastic and proactive 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.
- deleted 8y ago[deleted]
- kradroy 8y agoYou're a true leader with your inspiring, insightful comments. 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.
- icedchai 8y agoInteresting, since "agile" itself is actually built upon bullshit.
- winrid 8y agoI actually had management tell me it's a problem that my team is agile but not Agile. Sigh...
- YeGoblynQueenne 8y agoFunny 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. ... 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).
- tensor 8y agoUnsurprisingly, 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. This is all too common in software development, and decidedly old-fashioned thinking in the modern world of design driven development.
- williamdclt 8y agoI wouldn't say that assuming that "developers are good at everything, including all non-programming tasks" is old-fashioned. At the contrary I would call "old-fashioned" the idea of the caveman dev who only talk to their computer. 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 :)
- tensor 8y agoThis is not a working recipe for a successful project if you count good UX as part of the requirements. The modern way is full stack cross functional teams. You need UX designers working with developers, not to mention other domain experts depending on what you are developing. 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.
- FavouriteColour 8y agoSix months ago I joined an "agile" team. The team is completely disconnected from any reasonable interpretation of agile. 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.
- bsder 8y ago> Customer collaboration over contract negotiation 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.
- scur7 8y agoAn important part of the agile manifesto that is sometimes missed is that it is not saying there is no value in the items on the right (i.e. that you should not have contracts). An agile way of handling contracts is to negotiate smaller contracts (for example a contract to build the first vertical slice of a system rather than one contract for the entire system) to allow either party to easily move on (fail fast) if things don't work out.
- m0zg 8y agoI 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.