Everyone claims they are following “agile methods” but few do (2018)
qz.com
qz.com
I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone.
What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over.
I don't really want full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.
Agile with the backend/infrastructure actively encourages taking on technical debt just to get something, anything up and running as quickly as possible. Which is great for PMs' careers but terrible for the developers who have to maintain those systems, and ultimately the organization as a whole. Maybe it's even great for job security or to get an IPO/acquisition as quickly as possible, but it really does result in much more work in the long term.
The issue is that the people who push for these terribly designed backends that suck up unnecessary human-years worth of work to maintain, patch, and fix are never held accountable. And if you're stucking as a developer working on these systems, you're screwed (and it can even be bad for your career since you're not shipping anything new). I can't tell you how much of a relief it is to just walk away from that kind of mess... which really, makes the situation even worse, since everytime that happens organizational knowledge gets lost and some poor soul gets to start working on something terrible with much less context
The last part is more of a problem with hard maintenance work being unappreciated compared to launching new shiny shit which is entirely different can of worms.
None of those things are disclaimed by Agile. Agile never meant "don't do any design, requirements gathering, or specification." If the people you're working with think that "being Agile" means you can't do those things, then quit and go work somewhere else.
Remember, "there is no such thing as Agile." That is, there is no specific process or methodology named "Agile" which is prescriptive and says "don't do design". Agile is an umbrella term that encompasses a wide spectrum of different methodologies, including Scrum, XP, AUP, Crystal, DAD, SAFe, etc. Those different methodologies may argue for more or less emphasis on up-front design, but I'm not aware of any of them that disclaim it completely. If your people are saying "Agile doesn't let us do design" then they're full of shit.
The Agile experiences I've had that were more satisfying were actually the ones that were closer to "by the book" Scrum or Kanban.
The specific things that I've noticed get left out that make Agile miserable are: - Story pointing goes away - Velocity never gets calculated - Retrospectives get removed
I think Agile shifts responsibility off of management and onto the engineers in even the best run team. PMs and management don't have to commit to hard decisions early in the development cycle because the methodology says that overcommitting early will lead to failure.
Velocity and Retrospectives are two of the best features for me.. Velocity is a check on managers over scheduling developers, and Retrospectives force everyone to look failures right in the eye and adapt. When you remove those two things Management can over schedule the team without even realizing it and no one has any data to show it. When you remove retrospectives no one gets to discuss bad parts of the process or bad parts of the planning.
That's just one part of being satisfied though.. if you're doing perfect agile and killing it but you're building a poor product that's not going to be terribly great either.
Most of the reality for me has actually been good products that were right for the market but ended up implemented pretty poorly due to failings that could somewhat be blamed on Agile.. it seems to be getting worse and worse over time in my experience. More technical debt, poorer scalability, more bugs, less QA (you could write a book on QA and Agile).
I did quite a bit of UI early in my career and moved towards back end over time. I was mostly all back end by the time Agile really took off. I am generally pretty depressed with the quality of the back end code under Agile. You get horrible MVP database schemas and awful quickie framework dependent code that is horribly inefficient and really hard to remove later.. but that path is super quick for that MVP "gotta demo" mentality. I think this stuff really kills the morale of back end developers and leads tons of people to move on.
In a sense, it sounds like there is nothing to correct! Would moving more slowly and deliberately have improved the exit, or worsened it? Perhaps code quality has only a tenuous link to business outcomes.
"I believe it is time to explicitly state the long held secret of software, we do not need to do design; design is ineffective and costly." --Wayne Mack
It's really hard to argue with a money printing machine. That theoretically it might print faster or at least longer for a bigger integral, after doing things that seem to slow down printing now, is also hard to believe if the person you're arguing with has never experienced such a non-linear outcome.
And I would say than in most areas, design is effective and required.
NT works. 9x is long-dead (and even 9x had tons of design, but there was just a gap too immense on some fundamentals to get anywhere)
I would even make the hypothesis that good design is always eventually effective and required, but the period of time after which lack of proper design hits you badly varies, and in some fields it is actually longer than the lifetime of the product...
As much as Netscape vs Microsoft hurt Netscape, the time it took to do NS7 and the quality it shipped with, pushed them back 5-6 years.
I'll add it to my quote file, file under quotes by snarf21 :-)
Positive criticism always falls on deaf ears - "why not just give it a chance" blah blah.
Yet the product is markedly inferior to the same product we created with fewer developers in a shorter period of time, while also creating the backend services, right before we created this product, when we were not following ‘agile’.
Because the current management approved Agile is just a bunch of rules that are enforced upon us. The previous process was basically an ad god process we had built up using best practices, adapted based on our own experiences with the unique needs of our team. In a sense, we were far more agile when we were not doing Agile.
Basically the way any larger company works.
I'm ready for what comes next after Agile.
I've been through about 5 Agile shops now. I would say
one of the 5 ran Agile well, the rest were a mess that
just makes it frustrating for everyone.
Also there's nothing in agile that would prevent you from designing things upfront, I believe the exact phrasing is "Responding to Change Over Following a Plan". I.e., build extendable / adaptable designs (that can change), do the amount of specification upfront that provides value, but don't ticket-plan 2 years of development upfront.
I'd also add: much of the culture and thinking surrounding Agile grew out of software consultancies: organizations that have the privilege of green-fielding new projects and then "abandoning" them; either because their contract was over, or there's no desire (or capital) from stakeholders to improve the software. So it doesn’t surprise me that their model breaks down for software that undergoes continuous modification for years, as that’s an atypical case for consultancies.
Sprints are about enforcing feedback from the customer into the loop. If you have a half decent customer they should be happy with any length sprint and releases that make sense.
Well, there's supposed to be -- Technical Quality - Refactoring.
Common to all flavours of Agile (I lecture agile techniques) sounds like you guys are missing out important parts of agile... but I totally agree with what you are saying. I'm old Skool and grew up with waterfall. I find it really weird teaching students who don't have a spec or UML diagrams or any idea what a software pattern is. Hell, some of them don't bother with a Model layer - not enough time to implement it in a sprint, so why bother? Lol. They get code out the door, but quality code? A-hem, it is possible, but do people do it?
What made them stand out? What did the do to make it run well?
[1] http://agilemanifesto.org/
[2] https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
This is spot on.
And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.)
It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices.
Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour.
Couldn't agree more. A development process is like your CI pipeline, there's no one solution for everyone, but there are common patterns you can choose from and build upon to make something that works for you. And it's something that you will want to assess and refine on a pretty constant basis.
I've worked on everything from high-integrity embedded systems to web applications over the years, and what worked for one would be catastrophic (both metaphorically and literally) for the other.
What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.
> It’s easy to tack the word “agile” onto just about anything. Agility is harder to misappropriate.
I'm pretty sure it'll take more than an extra syllable to save an idea from being dumbed down by marketing people.
The concept of agility, with the word taken as in its common word meaning, does not actually need all that bullshit. Well, neither does the general concept of being agile in the first place, but it is harder to distinguish from the now tainted one "Agile".
If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work."
This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM:
> The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs.
If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck.
1) https://www.researchgate.net/publication/245862516_Democrati...
> Every day, the team is supposed to get together and organize the day’s work. [... The ScrumMaster ...] knows his job. His job is to stay on top of what everyone is doing, make sure they’re doing the right things, and redirect them if they’re not. How convenient that there’s a mandatory meeting where he can do that, every single day!
> In practice the Dark Sprint Review begins by someone reminding everyone what the team “promised” to do. (That is, what was demanded right before the team said “We’ll try”. That’s a promise, isn’t it?) Then we look at the pitiful failure the team brings us.
It’s important to have goals.
This is exactly what it has become though. It's not about developers, it's about managers and product owners. It's about numbers in a spreadsheet that managers can show upper managers.
Management has sucked the life out of agile. It's become this rigid metric producing muck that gets in the way.
Agile is, to my mind, more likely to get you to the right place than something like waterfall. But all the methodology in the world won't save you if management is bad. Putting the blame in the right place is a good place to start, though. If you're living through a bad agile process, saying "I hate bad management" puts the blame in a more correct place than "I hate agile."
Which is why it seems to “work well” in young organizations with relatively small, hands-on engineering-heavy teams without several layers of non-technical (in practice, regardless of past experience) management—those aren't the places where the problems tend to exist in the first place.
Sometime I equate the near constant complaint about Agile processes with a hypothetical set of engineers complaining about a 'baseball' process. "The 'Baseball process' sucks because our psychopathic managers beat us with the bats to get us to work harder. If only we switched to the "soccer" process, things would get better because there's nothing for them to hit us with, they'll just punch and kick us. "
The difference between the Agile literature and the Lean literature (including Lean Software Development, which has its own body of literature separate from Agile) is that almost nothing labeled “Agile” actually addresses that central value (except the Manifesto, which does so at a conceptual but not actionable level). It all just skips to concrete decontextualized practices of exactly the sort that the Manifesto’s “people and interactions over processes and tools” is a reaction against, while the Lean body of work actually addresses (without narrow prescriptivism) higher level meta-processes and practices which empower workers to drive the process of evaluatibg and adapt the low-level work processes to acheive business value.
Agile is basically the values of Lean accidentally recast in less-concrete way which empowers the kind of management consultant snake-oil solution vendors that it was a reaction against. While there are some decent ideas about low-level practices that are worth considering once you have the appropriate Lean organizational culture in place under the Agile banner, the body of work under that banner is mostly a distraction from the goals it notionally serves; better to ignore it all and focus on Lean than to make it front and center.
Story points being used for the team and to tell management how much work is being done are not mutually exclusive. I'm also not sure of your distinction between "on-task" and "commitments". If I've made a commitment, there are some tasks that need to be performed to meet that commitment, no?
That's the thing though, in reality they really are mutually exclusive. As soon as management starts using a metric to measure the team's performance, that metric stops being useful for the team to improve itself, because now there is a perverse incentive to inflate the metric to get performance rewards.
Don’t let anyone show you a two year graph of story points.
Agile is basically implemented to create an iterative feedback loop in the development process, but it seems totally rational that what works for startups won't work for very large distributed companies, and what works for an app developer won't work for an automotive supplier.
Standups can take different shapes, the 'V' in MVP differs wildly by industries, and the cycle time that a product needs to have can be determined by external market forces (e.g. the school year).
Agile is meant to adapt to the characteristics of the business it is used in, rather than to be specifically some universal way of everyone trying to everything in the same way.
Maybe so, but you are also describing Agile as if it can be anything a company wants it to be, which effectively makes Agile meaningless.
I've worked with clients that have a waterfall-like development process, "standups" that are both status-reporting to management and on the spot planning, adaption to change is very slow and cumbersome, velocity charts serving management more than the team itself, tickets that represent multiple stories at once, management adding tickets(i.e. more story points) without removing less important ones, gigantic release cycles, etc.
Is that still "Agile"?
For me the "minimal set" of rules that can still be called Agile is a mechanism for measurement, and a retrospective. You use the retrospective to perturb the process, and you use the measurement to decide whether that perturbation was a success or a failure.
That's it - old school cybernetics. If you used feedback loops to iterate towards a successful process, you're doing Agile. If there are parts of the process that are off-limits to you (eg management insists on doorstepping your standups) then you're not doing Agile.
Of course, we "prime the pump" somewhat by throwing in a bunch of extra rules at the beginning that we know from experience are likely to work, but I think that Agile, done right, has a lot in common with Nomic.
If so, then it is. If not, then it isn't.
Everyone's bullshitting each other, and I wish it would stop, but I know it won't. Not everyone can be a "true scotsman".
I'm not even defending Agile or other related methodologies like Scrum. They have some good ideas, but I haven't seen quantifiable evidence that they are good for businesses. Many of the ideas are good for software engineers, but that doesn't mean they are actually good for teams or companies. Even then, I've management use "responding to change over following a plan" as a license to make more arbitrary changes to what engineers will work on in a given day because they can take it. Planning days and point systems be damned.
Maybe agile is apostate waterfall, and we might as well do waterfall.
My wife works in a company where the managements seems to be quite "proud" to apply "agile methods" but in my wife's opinion, it's more BS bingo than producing a measurable boost in productivity, quality, or any other desirable metric. It is her impression that they are forced to adhere to certain routines even when the benefit is questionable. For instance, every morning at 9pm the whole department has a "daily scrum meeting", but most of the time there's nothing important to report from the day before for a lot of people, so it tends to lead to either embarrassment, pressure, or to people making crap up just so they have something to say. Needless to say that this doesn't lead to "team building".
That's just one example.
So, either the specific way "agile" is executed in my wife's company is just stupid, or the whole methodology is perhaps not applicable to their setup -- or something else. But it seems that the current practice is just a gigantic waste of time, yet the management is so proud of their "agile" way.
How could this situation be improved? Any tips?
A better idea is to plan the current day, identify where someone could use help, where two people need to coordinate more closely or on what issues further discussion is needed and with whom. If there’s nothing to discuss because everyone is already on the same page, that’s great, cut the meeting short and start working.
Also, depending on your setup, people who can never usefully work together on anything probably shouldn’t be part of the same daily standup. I’ve seen several cases where this meeting was way, way too large.
To put a finer point on it, a daily stand-up meeting should be no more than 15 minutes long, and about three specific things. Each person should talk about exactly these three things (or less, if you can say that one or more of them are not known or relevant yet):
1. What am I working on now
2. What is in the way of getting this thing done
3. What will I work on next
The value of the stand-up comes from the replies you can get from your other team members when they hear your report...
(1) "I know something that you need to know in order to get that done well, or done at all" ...
(2) "I can help with that thing you've identified which is in your way" ...
(3) "Here's something you will need, let's get it ready for you..." or alternatively "That's not going to go well because XYZ isn't ready yet, so maybe plan to work on this other thing instead"
If these things aren't coming out of your daily stand-up meetings on a regular basis, then something about how your group is doing them is wrong.
Talking about what you did yesterday, that is already over and done with (as you say), provides absolutely no value ... unless you know from a previous stand-up that someone was actually waiting for that thing. But if you really knew that already, you should tell that person directly, as there's really no reason to save it for the stand-up unless there just wasn't another opportunity.
I disagree talking about yesterday provides no value. Talking about yesterday, in my experience, dramatically improves people's ability to accurately identify and prioritize what they have to do today.
Plus, it provides a forum to communicate unexpected interruptions that may need to be dealt with by the scrum master.
How exactly are you supposed to make three whole statements per person and also leave room for helpful reactions and questions... in an average of 14 seconds per person-statement and response?
That might be how long it takes if nobody has anything to say in response, but it won't be the average, more like the floor.
Either we're not talking about the same thing, or your dev team are moonlighting as auctioneers.
14 seconds is a long time to answer them if you are prepared and don't dilly dally around. For goodness sake, the majority of time, someone is working on the same feature today as yesterday and has no blockers. It takes seconds to communicate.
It isn't like everyone isn't aware of all the work to be done and it isn't an appropriate forum in a cross-functional team to go into details. People do that after with the people interested.
The only time I've found people run over 5 minutes is if the person running the meeting is lax or if meeting doesn't start on time.
I guess sometimes another meeting happening after might get rolled in, but then it isn't a standup.
If you're doing it correctly, it should definitely not run over 15 minutes. Other groups that I've observed are having 30-minute standup meetings with 15 or 20 people and they're dominated by two or three people with lots to say.
That's not what it's for. I like your approach better than ours.
And isn't it funny how management never uses any agile framework to do their own stuff. Could you imagine the board of directors putting Fibonacci cards on their foreheads when deciding on budgets or earnings forecasts?
The example I gave about the daily meetings was just that: an example, meant to illustrate why my wife thinks that it seems more important for their managers to pat their backs about using "agile methods" than to actually know what they're doing.
That said - I'd also like to point your attention to another commenter here who pointed out that the original authors of the agile manifesto were actually trying to achieve a less strictly structured work methodology. However, I get from your comments about how a daily meeting "is supposed to be done" that some of you seem to indeed have pretty strict ideas about what constitutes agile and what doesn't. So that is kind of an interesting observation in itself, I think.
EDIT: also keep in mind different personalities. Some people just aren't socially comfortable with the format. That's totally fine and hopefully team lead or standup lead will engage them directly after the standup and propagate any relevant info.
If people are talking about anything other than; what I did, what my impediments are and what am I planning to do then they are wasting time. Book an actual meeting after the standup to discuss things.
If there are too many people to remember to book meetings after the stand up, your stand up is too large.
It can take < 60 seconds for each person in a stand up to cover the 3 questions. If people take longer they should be more concise and focus on only the important things. We probably don’t need the nitty details. It’s ok to practice this.
And the whole department is on one scrum team?
No one should lack for something to say or have to make anything up. It is a simple status synchronization with your team. The only pressure anyone should be under is remembering what they did the day before and prioritizing what to do today.
That's what I meant when I said that their interpretation of agile seems really pointless. It seems like it's more important to have the "agile" label stuck to themselves than whether whatever they think that labels stands for brings about any positive effects.
Do they have retrospectives?
That is when I would have my teams go over what went poorly (and well) and how to improve the system - including things like how meetings are run.
Nowadays, I just find a new company.
Agile favors so-called T-shaped skills Agile is a true democracyThe Agile philosophy certainly has something to say, but it's not hard to see the possible negative implications of "self-managing/self-policing teams" when they're owned by capitalist organizations.
These kinds of ninja teams can be extremely effective, but they should own a share in what they create, otherwise the whole thing becomes a BS attempt to make people work harder via "transparency"
if agile is supposed to empower the team to self-improve and self-organize, then being placed into a top-down hierarchy where the upper levels are always in charge anyways is a contradiction in itself and is a huge cause of disappointment that it’s “not working”...
well of course it’s not working if i it’s being imposed by “the top” and for their own reasons... right from the start it’s not team-centered, so there you go.
I can't refute this strongly enough. Managers should do their jobs and manage. Doesn't matter where team members are located.
Anyway, this agile nonsense gets too much air time. We got it: highly iterative feedback loop development.
Real Agile RAD /DSDM really does work best with collocated teams and experienced developers not lowest bid outsourced talent.
I have worked on both RAD and OSI 9000 (BS5750) waterfall projects so I have experience in both types of development.
Oh my Second RAD project was featured at the IEEE and when I was younger I worked with the BSI in the early days of BS5750
In the end companies will almost always regress to a top down hierarchy.
True Agile is bottom up which is against the structure of most companies.
That said, some worked. If they: * considered every task to be a mix of features, deadlines, and resources, and realized that if you fall behind, even a little, you have to adjust at least one of those three * iteratively completed tasks and reviewed any adjustments to the overall project * Had dev <=> management be two way communication
Then things were pretty smooth, even if they weren't Agile.
But if you dig any amount of depth down it becomes ridiculous. An example I found, the helpdesk literally has one project every sprint ("Ticket resolution: February Sprint 1", "Ticket resolution: February Sprint 2", etc.)
Or tasks that used to take 2 or 3 days now gets split across 2 or 3 sprints, because guy 1 can't allocate it to guy 2 until he finishes it. And it just sits around until the next sprint.
Even creative departments are supposed to snap-to. The idea is a recording a video should be a dozen or so tickets in Jira (edits and revisions happen as bugs). These teams are smart and overworked enough to completely ignore the directive.
And the amount of PMs has increased by an order of magnitude, because taking things in and out of the tracker has become its own workload because managers want to see more and more detailed 'analytics', so work get broken down into finer and finer pieces.
I describe the situation as if someone tried to make their truck lighter and faster by bolting a Lotus onto it.
This so much. Because no PMs want to adhere to "sprint forecast," but insist on "sprint commitments," you literally cannot commit to doing a unit of work that depends on someone else getting theirs done first until they are done. A smooth flow that gets to market quicker now _must_ be lock step gated by sprint start dates. /me sighs
Furthermore, the “you’re holding it wrong” criticism of everyone who gets poor results from agile, which seems to be a majority of people attempting to use agile practices according to articles like this and comments ITT, is a major cop out. If 75% of people attempting to use a tool hurt themselves with it, you should start asking whether this was a well designed tool in the first place.
My solution: stop using the term “agile.” It’s so vague and means so many things to different people that it effectively means nothing. Instead, talk about specific practices (sprints, story points, etc) and be able to explain the purpose of each practice. This can clear away the agile fog and get people discussing actual trade offs rather than agile magic dust.
There is no one “Agile Methodology”. It’s meant to be a communication protocol you grow within your organisation based on the principals outlined in the manifesto.
Which leads me onto why it’s a communication protocol. Human systems/processes/procedures just organise the flow of information, often to help people make decisions. If everyone isn’t following the same set of rules and behaviours then there can be a breakdown in communication. Which usually screws things up (whether top down or bottom up)
Incidentally, it turns out I'm a late comer to the "stop saying agile" point–an author of the Agile Manifesto was saying that 5 years ago https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
Agile is not Scrum, Kanban, or even XP. It is the manifesto. It is shipping all the time at a sustainable development pace.
I have had great success implementing agile and I attribute this to continually reindexing on the manifesto and examining the impact of our process. Spoiler: removing processes is a solution as often as it is adding a process. No amount of stand-ups or sprint planning or retrospectives makes your software process a good one.
Management here meaning overseeing people.
Development here meaning building things.
I am often only resourced 10% to some Agile projects, because my expertise is often only required for a small part of the project. And yes a copy writer can do my job as well, but would you really let an average electrician build the timber structure of your roof while the plumber wires your house ?
The first is a fortune 500 company that is not a techy company. They have a lot crusty old infrastructure and when they decided to do agile, they hired a consultant company that came in and spent a lot of time training everyone in their "agile" methodology. I can say without sarcasm that it worked great. It was painful at first and it took probably a year for everyone to adapt, but I was very pleased with the end result. Agile didn't mean, don't do design. For us, Agile meant to always be designing. We set aside 2 hours every week to sit down as a team and design future features, as well as evaluate current architecture and propose changes. Outside those 2 hours, devs would do additional design as needed. We had one hour every week for a long form meeting for our BA's, product experts and development team to all get on the same page for business requirements and future product direction. In addition, the product team was available for consultation almost every day, and never fewer than 3 times a week. Our retrospectives were rigorous, and by the time I left the company, our estimates were excellent. We had gone from almost never being able to finish our sprint correctly to it being a surprise if every story wasn't finished on time. Occasionally business would throw a curveball at us and we would have to scramble to get our backlog and designs into place, but we were still able to finish almost every sprint as promised.
I'm a little over a year into the new place. It's also a Fortune 500 company, but it is know as techy and has a good reputation with the field at large. So far it has been miserable. They're one of those companies that does waterfall with standup. As a result, we have extended periods of torturous drawn out design (one guy went six months without writing a line of code for work), followed by a mad scramble to implement our designs as we realize we're running out of time. As a result, the documentation looks nice, but the code is a mess and doesn't always match the documentation. Since the team can't self organize, tech debt continues to accrue at a terrific rate. Small stories are awkward because the pipeline and commit process is too difficult and slow to justify it. Part of the problem is the lack of business analysts. Without that intermediate group to help manage business complexity, the developers are left doing an extensive amount of basic requirements gathering just to get started on a problem. In addition, there's no real institutional memory, and when business flows change, there's no one around to update old docs with the new changes. There's no real story grooming, so we routinely overshoot our sprints. Without a clear understanding of how product and development are supposed to interact, priorities are changing constantly and I've been shuffled between two projects almost at random.
I could go for hours about the two different companies but I think the difference boil down to one simple factor. The first company had a culture of continuous improvement. They had their share of failings, mostly related to not being a very techy company, but everyone in that company was deeply committed to constantly making things better. Pain points were either quarantined so as not to impede work, or they were called out and fixed. If something couldn't be fixed or quarantined, than it was tracked until everyone was so sick of talking about it, we'd find the time to fix it. The second company does not have such a culture. Everyone is very comfortable with the status quo no matter how much it slows things down. Things are starting to get a little better, but not much.
I think Agile worked well with the first company because everyone was already interested in constantly improving. Agile gave them a framework to evaluate their performance and improve it. Without that culture of constant improvement the second company just adopted the most cosmetic practices of Agile, without actually changing anything, or evaluating their own behavior.
It's always struck me how the attitude of agile advocates has always been so rigid to the point of being dogmatic, thereby being the exact opposite of agile.
So the article indicates and blames executives from short-circuiting Agile. And the article says that the best Agile is democratic?
That sounds like a worker cooperative, not a private corp, LLC, S or even a C corp.