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.
Your 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).
Indeed, 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.
Changing 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.
You 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.
You 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!
Each 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.
I 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.
As 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.
This 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 ... 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?
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 we have any evidence that Agile actually helps
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.
If you've ever worked in a giant industrial organization, you know it's a swamp of red tape, silos, and inefficiency. Agile is a direct response to all this. Scrum, which influenced Agile, originated from case studies of automotive, photocopier and printer industries.
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.
I felt like Agile was like rewarding people for rats tails, so people start breeding rats. There was too much focus on clearing out stories, even if it meant a ton of bugs, but the bugs were good because those led to more stories and the PM could take credit for "getting so much done." This was at a certain dysfunctional, highly political networking hardware company.
> We should probably be doing modelling and formal verification and stuff like that.
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.
I'm not exactly a huge agile fan, but there are a few things it gets right. Most of the time, software development is implicitly a process of requirements development. Nobody ever knows what they want until they see it, even if they claim they do.
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.
> I don't think we should be desiging jet fighters in 2 week sprints. Airframes probably can't be modified like that
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.
”I don't think we should be desiging jet fighters in 2 week sprints”
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?”)
Agile development practices are now more relevant to the early stages of airframe design when no real hardware exists and all testing is done in computer simulations. At that point changes are relatively cheap and there are no safety concerns.
But once the outer mold line is set and prototype construction starts the engineers must be far more cautious about design changes.
> '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. [emphasis added]
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.
>It's just I note this is a DOD document, and I don't think we should be designing 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.
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."
I mean I don't think this document is actually taking a stance on things being agile. Just on the detection of things that are actually agile and those that aren't due to the prevalence of the buzzword.
Even 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.
> 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.
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.
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.
In 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?"
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
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.
... 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.
Six 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.
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.
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.
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?
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).
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.
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?)
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.
[+] [-] commandlinefan|7 years ago|reply
[+] [-] devonkim|7 years ago|reply
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).
[+] [-] pjc50|7 years ago|reply
Implementing a process in software overwrites the tacit knowledge that may have been keeping an unworkable process running.
[+] [-] smacktoward|7 years ago|reply
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.
[+] [-] 29athrowaway|7 years ago|reply
[+] [-] sailfast|7 years ago|reply
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!
[+] [-] darioush|7 years ago|reply
[+] [-] okl|7 years ago|reply
[+] [-] BurningFrog|7 years ago|reply
[+] [-] harryf|7 years ago|reply
> 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.
[+] [-] shubb|7 years ago|reply
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.
[+] [-] commandlinefan|7 years ago|reply
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.
[+] [-] peterwwillis|7 years ago|reply
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.
[+] [-] starpilot|7 years ago|reply
[+] [-] wenc|7 years ago|reply
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.
[1] https://en.wikipedia.org/wiki/TLA%2B#Industry_use
[2] https://www.youtube.com/watch?v=2S0k12uZR14
[+] [-] jnwatson|7 years ago|reply
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.
[+] [-] regularfry|7 years ago|reply
[+] [-] pjc50|7 years ago|reply
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.
[+] [-] Someone|7 years ago|reply
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?”)
[+] [-] nradov|7 years ago|reply
But once the outer mold line is set and prototype construction starts the engineers must be far more cautious about design changes.
[+] [-] ionforce|7 years ago|reply
Who is making this claim?
[+] [-] Jtsummers|7 years ago|reply
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.
[+] [-] tacon|7 years ago|reply
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...
[+] [-] SolarNet|7 years ago|reply
[+] [-] Kalium|7 years ago|reply
[+] [-] mi100hael|7 years ago|reply
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.
[+] [-] fouc|7 years ago|reply
[+] [-] myth2018|7 years ago|reply
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.
[+] [-] aristophenes|7 years ago|reply
[+] [-] ahi|7 years ago|reply
[+] [-] harryf|7 years ago|reply
[+] [-] okl|7 years ago|reply
[+] [-] montenegrohugo|7 years ago|reply
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
[+] [-] YeGoblynQueenne|7 years ago|reply
... 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).
[+] [-] nwhatt|7 years ago|reply
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.
[+] [-] FavouriteColour|7 years ago|reply
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.
[+] [-] AnimalMuppet|7 years ago|reply
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.
[+] [-] kradroy|7 years ago|reply
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.
[+] [-] obelos|7 years ago|reply
[+] [-] TheSoftwareGuy|7 years ago|reply
Who thinks I should show this to my manager?
[+] [-] Yoms|7 years ago|reply
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).
[+] [-] sailfast|7 years ago|reply
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.
[+] [-] okl|7 years ago|reply
[+] [-] whieee|7 years ago|reply
[+] [-] okl|7 years ago|reply
[+] [-] ionforce|7 years ago|reply
[+] [-] tensor|7 years ago|reply
This is all too common in software development, and decidedly old-fashioned thinking in the modern world of design driven development.
[+] [-] kvhdude|7 years ago|reply
[+] [-] bsder|7 years ago|reply
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.
[+] [-] m0zg|7 years ago|reply