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).
> 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.
Having 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.
> 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.
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.
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.
One 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.
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 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.
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.
Currently working in a kanban/pair programming/tdd project and it is indeed the best that can happen to you. Plus pair programming spreads knowledge extremely well.
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.
One of my favorite software jobs was working on an in-store UI for creating custom apparel, not because of the software stack but because I got to sit in the store, in the mall and work, observe, and help people use the software. Seeing their struggles and questions and ideas was truly the most inspired I have ever felt working with any software.
as fouc noted in a sibling comment, you shouldn't need to ask for permission to talk to customers if the organization is truly agile. however, the product owner (which i've been in various capacities) should bring a lot of customer information to the table so you can focus most of your time on development.
it's unfortunate that your organizational structure prevents you from doing so.
Even if a "Product Owner" brings a lot of customer information, it is still damn important for those developers who are genuinely willing (and able), to interact with customers—even if it is only via medium-bandwidth tools like video calls. Developers should not worry about spending some time talking to users.
we are not "disagreeing" that develoeprs have freedom to talk to customers. but if a developer spends most of their time doing something other than development, there are other inefficiencies going on.
I know we agree on some level. Still, I can't help but feel like you have a somewhat narrow definition of "developer". A thoughtful senior developer who is in it for the long-run (read 15–30 years), and thinks in terms of "building a craft" will (and must) aim for a more well-rounded set of skills (that does not involve "development" in the narrow sense of hurling code)—e.g. giving high-quality technical talks that provide durable value, high-bandwidth interactions with customers and users, writing specifications, bringing multiple technical teams together to architect features and solutions (which requires careful and effective communication), and so forth.
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.
Can you talk to the people who talk to the customers (The sales team)? It's indirect, and you need to isolate what's "real" and what's "If I had X feature I think I could close more sales"[1], but it's better than nothing.
[1]which does have value, but not necessarily value to the customer.
It doesn't hurt to cc management at times or find a way to keep them in the loop on your immediate findings etc. That way it's just a demonstration of 'showing initiative' while still being a team player.
I’ve been the Software Engineer on customer sites and visting call centers with 100s of users in international locations. It was a very good experience every time. I’m certainly not the unwashed developer type but some of the non IT folk did share some of the points you raised.
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.
I noticed that they very assiduously avoided the whole "Working software over comprehensive documentation" angle and didn't say anything crazy like "maybe CDRLs of stupendous quantity and length due at regular intervals to the DoD might negatively impact development."
You 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.
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.
This is exactly right. I was at two companies in Florida who were "agile" and it was extremely pathetic. Daily standups, marching orders, insane requirements and deadlines, overly long meetings, tons of PMs and 0 automated/QA testing. In fact, they were hiring more QA personnel and project managers at both companies and keeping the dev count the same. So yeah... This is typical stuff.
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.
Exactly this. The problem that people have with Agile are mostly because they think they need to follow rigid Agile rules.
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.
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.
That's not agile. That's goal-driven motivation systems.
"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.
That type of dysfunction can occur under any methodology, regardless of agility. It indicates an inadequate definition of done and poor quality procedures.
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.
> 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.
"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)."
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.
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.
”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?”)
There is a difference between iterative or incremental development and agile. Iterative processes have been used for 70-80 years. The first example on the wiki page [1] is the Mercury rocket program.
Agile is a set of practices intended to shorten the feedback cycle of “increments and iterations”, which became ineffectively long and unwieldy in both commercial and defense, perhaps in part due to a greater value placed on political perception of a program rather than its actual results.
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.
Not even fighter jets. When several years ago our BigCo implemented total Agile Scrum (only few super important super critical projects got exception) with the best consultants one can get for the money the result was exactly as could be easily predicted by applying basic system analysis to those methodologies - the projects halted to the screeching halts while people and organizations were spinning at FTL speeds with everything just burning around on contact. I've never seen such profound yet so easily predictable failures.
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 with agile processes? Yes.
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.
>Is it possible to build software successfully with agile processes? Yes.
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" :)
>> Is it possible to build software successfully with agile processes? Yes.
> 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".
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.
> '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.
Its a great way to churn through hundreds of small tasks, like hooking up database queries to web pages or changing graphics on a site.
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'. =
I know something about complex control systems (MPC implementations). There's a lot of trial and error involved. Breaking the task down into small composable tasks is definitely helpful.
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.
Stronger: What's worse about "iteratively refining a complex design as you gain feedback from its implementation", compared to "not iteratively refining a complex design as you gain feedback from its implementation"?
By the time developers are working on the change, the design should already be complete. An assembly line worker isn't going to be considering the design of a car: they are going to add this one part according to the blueprint, and move on. They trust the engineers / architects' plan, which should have already been done by the time they started building.
Definitely not a good way to go about software development, and one of the things agile avise against.
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)
To play devil’s advocate, I’ve certainly seen plenty of cases where people start coding something—anything—with no coherent plan that they can articulate regarding how it is even supposed to work.
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.
IME 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.
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
I 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.)
I'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.
I 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
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.
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.
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.
> 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.
You'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.
> However, I think enthusiastic, organized and proactive engineers don't need any process to be 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.
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 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 :)
This 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.
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?)
An 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.
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.
