Ah, the no true Scottsman. If it's not working, despite all the best efforts of your scrum-certified agilistas, it's because you're doing Agile wrong. If it's working, then it's because Agile is awesome!
I've never seen a non-functioning team start functioning after Agile was introduced. And I've been on plenty of functioning teams that aren't doing Agile.
Agile the process is about as useful as a tiger-warding talisman. Look, ma, no tigers!
Agile works perfectly fine where I works. We just try to adhere to the manifesto. Works much better than anything I have been part of the last 25 years of my career, for sure. We wasted so much time back then.
I mean, if you use a process that's apparently fixed enough it's worth making certifications around it, it's quite likely not "agile" in both the dictionary sense of the word and in the sense of the agile manifesto.
The agile manifesto is so broad and vague, it is all things to all people, and therefore useless. As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations, because there are always capital-R 'Reasons' for why <your company's particular flavour of horrorshow> is having a negative impact on developer productivity. 'Reasons' that neither you, nor your team lead, nor his manager have any power to change, regardless of whether or not you are six-sigma-black-belt-scrum-master-rock-star-certified.
There's only two valuable ideas in agile, that are actually broadly applicable.
1. Do continuous integration.
2. If it doesn't make sense to do something, don't do it.
You don't need to get into philosophical discussions over the manifesto, and the purity of your adherence to agile philosophies, or any of that nonsense.
What you do need to do is to go and deploy Jenkins (Or whatever the new hotness is in the CI world), and don't build features that nobody needs.
As soon as you start transforming it into actionable items, in a non-working team, you immediately start getting capital-A 'Agile' abominations,
I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
I work in an environment with projects for many different customers, and almost as many different approaches to coordination with the customer, and I'd say the points from the agile manifesto are quite useful to suggest and evaluate the process for a project. Can we get a proper quick feedback loop? Can I talk directly to people that actually know about the details? How does the change process work? How much overhead is there that's not directly relevant to doing whatever it is were asked to do? What kind of decisions do we need to stick to that have been made without/against technical guidance?
It really depends on the customer if that process is something that can't be influenced. Although of course we're as an external party often have more freedom in that regard than a customers direct employees.
I've worked in a few Agile shops, and it was horrible in all but one. Perhaps that one was "doing it right".
The thing is that it appears to be extraordinarily hard to do Agile right. I think that any system that is so difficult to implement correctly is an inherently flawed system.
Might it not be that it's extraordinarily hard to manage software development in general? Are you aware of any other methodology that's easier to do right and get the desired results?
Yes, managing software development is generally hard and there is no silver bullet. But I do think that the methods that I commonly encountered before Agile were better in terms of both developer stress and software quality.
Interestingly, in many ways they also weren't all that different from what Agile is intending to bring. They still involved something analogous to "sprints", they still allowed for course correction and pivoting during development, and all of that.
Agile seems to position itself as the opposite of "waterfall", but outside of large corporate environments, I'd never seen a shop that actually used waterfall as described by the Agile community.
If I hate something only when it is done wrong, but it is so easy to do wrong that it is far more often done wrong than not, at what point should I consider just hating the thing because it is so easy to do wrong?
One of the biggest issues with the scrum (master|lord|bag) model of Agile is that any process grievances magically transform from "this process has issues" to "that person is wrong."
Agile is fine if it is an organic, bottom-up process. And as any of the founding Agile gurus like to profess, this was the original intention.
The problem is that it is usually implemented as a centralized, top-down imposition by management. The net result is usually just a tax on productivity to ever more process, paperwork, status updates, and meetings.
I built a from-the-ground-up agile/scrum process workflow for a team shipping a monolithic enterprise app that had a complex build process. Our productivity sky-rocketed. We went from semi-annual production deliveries to monthly ones.
Management didn't skip a beat -- they pivoted to new and innovative ways to push against the guardrails we built for requirements, approvals, agreements and deadlines.
In this case, neither agile nor Agile were the issue.
The problem with current implementation of agile is it tries to standardize a process and use it across all companies and all project.
In reality, I've found that every developer are unique. And together with unique company cultures and projects, the process need to adapt with those things, and not the reverse.
A scrum may work well in a team / project, while it may not work in other.
> In reality, I've found that every developer are unique. And together with unique company cultures and projects, the process need to adapt with those things, and not the reverse.
Which is pretty much the core of the agile manifesto.
Indeed, but this criticism suffers from the no-true-Scotsman fallacy. Better to just eschew anyone who endorses "agile" no matter how persuasively he claims to practice the one true actually-agile Agile methodology.
> Individuals and interactions over processes and tools
Take a look at the rest of the principles and compare them to that diagram. SAFe is clearly the opposite of agile. It calls itself "Agile", but it's as non-agile as is possible to get.
What we have here is not the no-true-Scotsman fallacy, it's somebody rightfully pointing out that somebody born in Australia, who has never left the country, with no heritage that comes anywhere near the northern hemisphere, is not, in fact, Scottish.
Sure. Yet every single time an organization tries agile, the result is a dysfunctional mess. After this history of pain, "real agile isn't like this!" has just as much legitimacy and persuasive power as the old "real communism has never been tried" line.
As a developer who has been quite unhappy in Agile environments, I don't actually think Agile is to blame, which the article alludes to.
I think the issue with Agile is that software is a field in which is difficult to measure productivity easily. Then Agile comes along and offers the appearance of making it easy to score and and measure team and individual effectiveness. Sure it's "supposed" to be for the team to measure their own effectiveness and empower people to work more productively, but for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
Once it becomes just a way to figure out who's not moving fast enough, or "failing to meet their commitments", of course people will hate it. It gets changed from a tool into a stick.
Your observation is right on target, and it has been predicted and validated [0]. The people who originally developed agile understood this, but it's one of the kinds of things that doesn't really sink in in many cases.
[0] 'Measuring and Managing Performance in Organizations', Robert Austin, Dorset House, 1996.
But who ensures it isn't? Management who are the ones inherently attracted to having the metric to use? The ones who are able to withstand that pressure and not touch the information are likely the ones would could see the information without using it as a stick.
I guess upper management could enforce the separation on a level lower management could not override, but I would assume such cases are rare.
The solution is to stop blaming the methodology for the failures of management, and just accept that bureaucracy breeds mediocrity. Corporations grow into bureaucracy, inevitably. Choose accordingly when evaluating potential employers. Keep this in mind when running a business.
I'll bite. Management always seem to get the crap. To summarize, if engineers knew how to manage things better than management, why don't they? From my experience, teams without management seem to complain about that and end up with bad results. There are more factors at play, and honestly it's very rare that the engineers sees that (or even acknowledge that they don't know all the relevant factors, with all the implications that gives).
Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
Yeah I don't mean to imply that it's managers per se. Management seems suuuuper hard and I wouldn't want the task of assessing engineering productivity.
I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker.
By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both.
It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
As a project manager, I hate taking a bug tracker and trying to beat it into being a project management/communication/measurement tool. The only reason I always end up doing so is that bug trackers are already in the engineers’ daily workflow so they are usually the source of truth about the project.
I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
> I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
What'd that look like, that's different from what they do now? Trying to imagine what developer input to that would look like. I think a lot of devs already feel like existing PM tools they use for sprint tracking and such are worse than if they pushed more planning into git or somewhere otherwise closer to the code, so getting buy-in might not be so hard if devs got to be a little less heavy in a bunch of not-actually-that-useful-to-them tools on a day to day basis.
Could be something as complex as MS Project or simple as a shared spreadsheet with rows for each project and columns for each milestone or for things like ETA, dependencies we’re blocked on, escalations needed, scope changes, etc. Not sure how that could gel well with a source control tool but I’m all ears!
I think 1/4 of the challenge is what tool to use and 3/4 is convincing and motivating people to be reliable and forthcoming with accurate information. A good project manager demonstrates he or she can add value, unblock things, escalate and communicate appropriately, and not just be the Project Police.
Management has, culturally, become very metrics-oriented. This is the root of the problem under discussion here. See Goodhart's law for a brief statement of why this can't work.
Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold:
1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it.
2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies).
Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good.
Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.
Management gets the crap because they have the responsibility and push the processes.
It’s as if we were complaining that elected officials get the crap for mismanaging the country. Well, that’s the point of them doing their job. Our goal is not to all become managers (though some do, exactly for these reasons), it shouldn’t be a ”why don’t you do it ?” rhetoric.
Somewhere, there's always an impedance mismatch. Agile can be managed, and managed well - I've seen it done - but above that manager, there's another manager. Somewhere up the chain, someone wants to see progress on a PERT chart or similar, and the person who is managing an agile project doesn't have a good way to answer.
It is vital to have someone close enough to the project that the team trusts them to see their honest opinions about progress and blockers, including non-bullshit pointing of tasks, who is the point person for communicating progress to management, and who is capable of producing reports that are technically bullshit in an is-this-quantifiable-this-way sense but actually do reflect reality usefully to managers. Someone who does that well is worth All The Money.
They're useless if you're giving management direct access to team planning & communication tools, of course.
In some places these are called Engineering Project Managers, in others they are Technical Program Managers. You may think they are worth All The Money but let me assure you they usually make far, far less than the developers :-)
Agile was proposed as a way for engineers (or "self-organizing teams") to manage things better. The complaint is that the engineers' better management process has now been hijacked by management and turned into something else.
A space alien with a raygun and a watch knows just enough English to tell you to build a time machine "or else!"
Any attempt to persuade him otherwise just results in him pointing his raygun to his watch. Either he's ignorant, can't or won't understand, or simply doesn't care.
Software management in 2019 is still very much like this. Management has had 40 years to solve this problem, and it looks like it won't be solved in the next 40 either
> if engineers knew how to manage things better than management, why don't they?
They do: engineering-led companies are often dynamic success stories, then when they get big enough traditional management works down from the top to lower levels and the firm stagnates.
I am not sure it would even save the situation. Most agile methodologies assume a lot of constants to allow measurements to have any sense at all (for instance scrum assumes teams members are stable, of that knowledge over their work perimeter is good, etc.)
We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.
The failing after every step has been when they close the loop. That is, agile is used to score and measure velocity. This velocity is then used to impact future scoring. This nullifies Agile's use for measurement since management is now insisting that x number of points be completed per developer per sprint.
The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out.
Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked.
So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.
That assumes really good (measured against the norm) management. If your management is "normal" (or worse), giving management access to that just destroys the whole value of the scoring system. (Always remember that fifty percent is worse than the centerline, to say nothing of the still-within-a-standard-deviation "better" that isn't enough better to matter.)
It really sounds like a "not true Scotsman" argument, but I've had Agile fail when the team failed to use Agile. As I wrote above, points inevitably became a proxy for time in one manner or another. Production was pinned to a certain number of points (say 15 per developer per sprint).
I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop.
Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).
I do think that "Agile" is to blame. In my view the Agile software methodology is like Communism or libertarianism. Whenever you point out the myriad ways that it can fail in practice, someone always jumps out to say, "Well, what you're not describing is not true Agile. True Agile has never been tried!"
This is a great point. If there's a tool that no one can figure out how to use properly or effectively, it's hard to argue that the tool is well designed.
You could say the same about vim though...
Jokes aside, many resources about agile start with explaining how agile is “easy to understand, difficult to master”, and I think that’s true.
The difference is that vim is a specific tool, and if I see someone struggling repeatedly to be effective with vim, I can gently suggest that they try some other tool. But if I see a team repeatedly to implement something that looks like an Agile methodology, what do I tell them?
I suspect that many devotees of agile would speak at this point about getting management buy-in, or reforming the wider organization, but at this point "agile" just becomes shorthand for "reform your entire organization from top to bottom so that your management doesn't suck".
If the team struggles, the org does not need to be changed. However, from my point of view, companies should increase support for their teams when transitioning to agile. Training would be a good start. I have taken a few agile trainings, and they have been among the best I had in my career.
But IMO agile is not at all about measuring productivity, I'm not sure how you'd come to that conclusion?
There is, I admit, an element of it in the sprint planning, but that is only meant to be a tool to figure out how much work can be put into the next sprint. Agile does not care what your absolute value of velocity is.
If however, some misinformed PM is obsessing over velocity then I think that is a very different issues and not really related to the essence of agile.
> But IMO agile is not at all about measuring productivity, I'm not sure how you'd come to that conclusion?
It wasn't a conclusion it was a summation of what is happening when agile ideas are misused. I've seen it used that way too, it never ends way because nobody can measure a programmer's productivity/effectiveness.
But using agile does change how developers communicate progress to management. So agile processes can definitely indirectly impact how your productivity is perceived and measured.
As a developer become engineering manager become director of product, I agree with you wholeheartedly.
But I think the bigger problem is that often developers and management (at all levels) give very little thought into "delivering value" and a lot of thought into "doing whatever they want".
I can't fault individuals (workers, management, or executives) for trying to do what's best for their careers rather than what's best for the company. As a manager, I think management's primary objectives are to set up their reports for success and to figure out how to align their reports' incentives with the company's incentives in the best possible way.
Management, I have seen, often does a terrible job 1) actually knowing what "value" is, 2) figuring out how to measure that they're actually delivering value, and 3) figuring out how to align delivering value with the worker's own incentives.
If you can't do these things, you have NO chance to do agile effectively. It's easy to go through the motions of Agile, but you will gain nothing if you can't define and measure value (and hardly any companies can -- it's not easy!)
But as you pointed out, even if you can accomplish the prerequisites, it's still INCREDIBLY difficult to attribute an engineer to value. You can execute effectively, but be on a project that turned out to be useless. Making the button green might be easy, but because of previous technical debt, making it blue might be really hard, etc...
TBH I think it's normal for any person to put their own interest on first priority. The key is to hire people who actually share the same interests. I fully agree with your point actually.
Here some reasons I have seen why nobody has a clue about value...
* Often the financials of a company are "need to know" or obfuscated (Y-Axis unannotated)...
* The financials are regarded as irrelevant to engineering (by management, finance AND engineering)
* The estimates of where the value lies is often just a spreadsheet sucked out of the thumb of somebody in marketing who already has a eye on his next job.
* Nobody _ever_ goes back and closes the loop and evaluate the value estimations and the value estimation process, so the company never learns to do better.
* Let a drooling slob of an engineer talk to a customer? You're joking Right?
And yet engineer is all about tradeoffs, we make several per day under the illusion we know which are wise....
I worked in fake agile for a few years. It took me a while to place my finger on why I never really loved everything about it, but I eventually decided that it felt like it was a façade to a management power grab. It gave the ability to micro manage workers to those who don’t understand the problems or even the product. If agile is necessary to be productive then you already have too many people involved. If it isn’t necessary then it introduces a lot of overhead for a little bit of book keeping (which isn’t inherently bad).
It's the burgerization of software development, where every engineer can be turned into a generic fungible burger-flipping engineering unit, and the output measured in the number of burgers flipped.
The software architecture is falling apart, the tech debt overshadows the actual debt of a small country, our subject matter expert quit the company over being micromanaged, and the clients are abandoning our buggy software for our competitors? What went wrong, we closed all of those JIRA tickets, surely that must be good for something.
Ticket driven development isn't just an agile issue though. Project management has always loved granular tasks and the assumption that at some point they are all worth the same effort.
I’ll add this — To a large extent, many management systems are about reducing the failure modes — but I don’t see why a system must downplay creativity and deep thinking about the core business engine (often the software).
I remember a time I worked with a team not using the agile process.
We were agile.
When I worked in teams following the agile process, we were rigid.
Agile shouldn't be a process, mgt see it as such. It becomes a process. Clever engineers hate poorly thought out processes. Agile as a process is a contradiction in itself.
Agile is no process. Let the team find their ways and iterate as often as possible, along with a few other proven principles.
Points becomes estimates for managers, they will see it as such and build huge waterfall projects documents to track everthing, and they will pressure teams to deliver shitty software when they feel the stories are sand bagged.
I think that's pretty close to the truth. Like the Tao, you can point at instances of it, i.e., you can point to a particular team and the processes it is today using, and that is agile. But it is not Agile. On this same team I'm on, I've used different process a year ago, and two years ago, and now, and almost certainly in a year and two years. Those specific processes aren't Agile... but they were each agile, because we're constantly re-evaluating how we're working and what we're doing, and tuning our processes to match the environment we're in. If you take my agile process and just blindly apply it to your team, regardless of what that process is, that's not Agile. The grass of the field does not become a bird by shaping itself into wings.
It took me a while to place my finger on why I never really loved everything about it, but I eventually decided that it felt like it was a façade to a management power grab.
Yup that's exactly it. Or to put it more delicately (than simply a "power grab"): a façade that servers various ulterior purposes -- from making their company seem hip and modern (to the uninformed) to simply being able to say "finally we have some structure!" even though it's very debatable whether new "structure" really brings the benefits that it claims to (and evidently brings many negatives on board with it).
-- Value individuals and interactions over processes and tools
-- Value working software over comprehensive documentation
-- Value customer collaboration over contract negotiation
-- Value responding to change over following a plan
That doesn't sound like "agile" anywhere I've seen it implemented. The issue is that you need real buy-in from all levels of the company for any process. I've always said that a "bad" process executed consistency and with real buy-in will outperform any "good" process with only lip service commitment.
You know the problem with those principles? They are not a methodology.
Most of the problem described in the article -and everywhere- is precisely that "the theory is good but everybody is doing it wrong".
But that doesn't really help, because it overlooks the fact that the origin of all this is just a pile of generic, hard-to-argue small-time guru ruminations. I mean, it is not necessarily bad advice: "These are valuable things and we think that in particular these ones are more valuable than those other ones". Okay. Probably. They do look good. Let's say they are. Now what? Oh, that's left as an exercise to the reader.
It's funny. Just yesterday I almost had an argument over one of these things. I heard Karen say to the guy on my left that "Agile means less documentation", so I raised my eyebrow. "Agile means less defined documentation, more open, because documentation has no value at all" - she added. I was about to point out that that is not at all what it means, but then she went further and told him that what he needed to do was to "work as a team and become more involved in collaboration". That, right there, is the problem: pretending a bunch of cool sounding expressions can be a substitute for actual things like writing down what they wanted the guy to do.
It seems like the problem might be that people assume agile software development is, in and of itself, supposed to be a methodology. As I understand it, agile software development is meant to be a set of principles describing any methodology that serves those principles. As such, Extreme Programming is an agile methodology, intended to serve those principles when employed well, and Scrum is a pseudo-agile methodology that serves as the halfway point to which one might be able to drag management, but more often ends up being an excuse to measure developer productivity in story points.
There's value in enumerating important principles for consistently pursuing quality work product. That's why the Agile Manifesto has value. The manifesto is just a manifesto, a statement of intent and principle, and not a methodology in and of itself. One doesn't need a published, monetized methodology to engage in agile software development. One simply needs a methodology -- whether unique to one's project, or widely known -- that reinforces those principles to engage in agile software development.
The biggest problem with agile software development as a concept is that it, like any other elaboration of any principles of quality work, is that most people will fail to see the forest for the trees, will marry themselves to some well-marketed thing that pretends to be about principles, and will end up largely doing the same dumb crap they've always done.
The documentation one is the one that completely throws me for a loop, and why I will never be on-board with anything claiming to be Agile. You know what? sometimes the documentation is more important than the working code. We're not all building crappy web properties as an agency, sometimes we are building stuff that is supposed to last longer than any one developer's career.
Sometimes just documenting what the thing is supposed to do and why would solve so many issues, but since people have gotten hooked on capital-A Agile so much has gone by the wayside, or been delegated to non-technical roles.
> You know the problem with those principles? They are not a methodology.
No, that's not the problem with the five values and twelve principles.
In fact, the problem is the desire to have a single, divinely ordained methodology (which both the first value and twelfth principle reject, and that rejection is arguably the central basis of Agile.)
OTOH, while it is good that the Manifesto and Principles don't ordain a methodology a it's bad that they are written in a way which makes it harder to extract actionable direction than is necessary.
The only place I've worked where Agile was like this was, surprisingly, one of New Zealand's major banks. The buy-in for Agile started at the executive level, and they made a call that everything was Agile. Obviously, this would've been an absolute mess for most teams. But my team functioned perfectly. The woman who was our scrum master was originally a project manager in the bank. But with the Agile reshuffle she went over-the-top with her retraining. This was horrible in some areas, where she would follow processes to a T, but she would catch herself, and recognise the importance of those principles. She grew into the role well, and the team was eventually working great!
I was in a company that did Agile well (my first time using it). Team velocity was never used to measure the output of the team, only to better predict how much work we could fit in a sprint. The other big think was that they saw Agile as a framework, each team was free to do a different "implementation" and use different tools. Team velociyy had different units in different team and couldn't be compared.
I worked for an employer that had a different PROCESS.md document in every project repository. At every retrospective, we'd evaluate the process for that project to determine whether it needed updating. It was awesome.
Eventually, things changed, but for a while there it was awesome. Things got done well, in reasonable amounts of time, with a lot of attention to quality work.
I think the beginning of the end was probably around the time when the company (a software development consultancy) started using fine-grained hourly measures of time pre-sold to clients. This started happening around the time investors in certain clients got more involved in trying to dictate company policy, and I'm pretty sure it was all part of an attempt by investors to ensure there were "better metrics" for evaluating their investments.
You can't measure something without it directly affecting the measured thing's state. In this case, it started having detrimental effects on almost everything. Previously happy and productive devs started burning out, mediocre devs became new management favorites, more bugs got into production, projects suffered under less and less reasonable goals (including at one point my task effectively being to solve one of the Hard Problems of software dev -- cache invalidation), and so on.
In the US, management culture seems to have a monomaniacal focus on metrics. (I'd say "simplistic metrics", but the way they use them guarantees they're always simplistic.) This is driven, in part, by bureaucratization, which is in turn driven by a bunch of other things (mostly stemming from politics, directly or indirectly) in our business culture. Many managers would complain that without metrics they can't evaluate team productivity, individual value to the organization, and other important stuff, and they're right. The solution is not to double down on those metrics obsessions, though; it's to replace those managers with managers who are capable of effective, qualitative evaluation, instead of the almost purely quantitative approach that holds the high ground.
This is absolutely correct. For example, what is the point of a sprint in Agile ? Do what one can finish in a sprint but try and finish "modules" while maintaining quality and carry over rest to next sprint. What does management read? Finish ... modules ... current sprint?
You've hit the nail squarely on the head. The problem with Agile isn't Agile itself, but the fact that humans can't keep themselves from using the data it produces to their own non-Agile ends.
But maybe Agile is the source of problem with Agile. Agile, to me, is like the nitroglycerine of development methodologies. The explosive instability of Agile isn't a problem from outside that corrupts Agile - it arises from the methodology itself, which inherently invites abuse.
> for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
One nice thing about this is that the metric is visible. Then you can optimise your performance against it. Is this necessarily productive, or in the real interests of the company? Maybe, maybe not. But I look at this as a kind of a favour: if your boss is complaining "velocity is too low" well, at least you know what you're being measured by. Put some extra points on those stories. Undercommit. Make your boss happy and get them off your back. You'll be doing the same work either way.
We moved to Kanban a few years ago and I think it's been much nicer than the "sprints" we used to do.
There is a board. The board has a prioritized list of things to do. You work on your thing until it is done. Then you pick your next task based on where the priorities currently sit.
It's really not far off from the "sprint" idea. The main difference is it is a constant re-balancing rather than an every X weeks affair.
There is always a list of things to be done and it's usually prioritized and often the highest priority item is what you do next. This isn't unique to software. It isn't even unique to white-collar jobs. Why does that even need a name?
the main innovation of Kanban is to limit the number of items being worked on (in a specific category) at one time. For example - You can't pick up new work if testing is behind - go help the testers (somehow) instead.
You think that it is how it's supposed to work, but that's not really how it works. When a bottleneck presents itself everyone gets to work around it as it is not fixable by them! (Or the fixes are deemed either or of scope out to time consuming, so you're directly even prevented trying at it.)
Generally you cannot fix things you do not have control over. Kanban is meant to have a process person fix the bad bottlenecks - not the developers, not the managers - and said person is supposed to have the clout to pull it off. I've never seen Kanban implemented properly.
As for the example - if testers are not keeping up, either you hire more or enhance testing methodology. Throwing developers at it slows down development moving the bottleneck.
(Of course, throwing some developers to provide better testing methodology, testable components or automation would be a proper fix.)
well, any type of process will fail in a dysfunctional organization :). And you can't (well, shouldn't) arbitrarily implement a specific process without thinking through the fit for your organization. Just buying a license to a Kanban tool isn't enough :).
The example you gave is a good one - devs spend their time making improvements to to code or the test automation to make the testing more effective, if testing is the bottleneck to delivering finished features. Throwing more code/features over the wall when that code isn't actually being tested isn't real progress.
In principle, the manager/lead would tweak guidance until the most expensive resource (dev engineers) are the actual bottleneck. I guess of course teams/companies that care less about quality might just tell the testers to test less thoroughly in order to get their work items through the system faster, but at least it's a conscious decision.
I've worked for teams where they literally close every testing ticket once the code is pushed to production regardless whether the testing has been done. 'tested in production' - that's one way to keep up I guess...
It's a great way to have an unfixable mountain of tech debt.
See, Kanban only works when the focus is on quality. It's the main secondary premise of the original Toyota approach of Lean which spawned Kanban. Note that it starts with minimizing waste (in programming, tree breakage or waiting on tests) and secondly minimizing overloads. The philosophy is kaizen, continuous improvement. Sacrificing quality is not an improvement, Toyota itself started by breaking process into quality assured steps to fight waste due to rework.
Otherwise anyone can push undone paper tickets over the wall and that's not the point.
It came from Toyota manufacturing, so right off the bat software is a borrower of the idea.
I love Kanban, it's all about minimizing work in flight, to allow you to focus on the task at hand until it's Done instead of hurrying to meet the sprint deadline.
Kanban goes a little further in my own experience. Here are some things I’ve seen in the wild:
- make sure that developers have some slack time, so that they can cater to their tools and study new things
- never move back an item to a previous column. If
something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks
> never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks
Could you explain this a bit further? I'm imagining three columns, todo / doing / done, and I'm working on a widget when I'm asked to put out a fire. I'd imagine that the fire is moved from todo to doing and that the widget work is moved from doing to todo, but it sounds like you're advocating for something different.
Could you explain more about it or link to resources that might help me understand? Thanks!
You need a mechanism to keep track of your unpredicted interruptions, so that you can improve your process continuously (which is what Kanban is about).
Moving items back makes this harder (although possible). What I saw some teams doing was to mark such items as cancelled, explaining in the tickets why they got cancelled, so that a manager can then see which columns (i.e. steps of a process) are interrupted more often. This could point to a bottleneck in this process.
In the near future, the "rest" of the cancelled ticket would make it back into the backlog as a new ticket entirely. This has the added benefit of keeping your backlog cleaner.
I will try this today with my own personal kanban board. I do find myself with cards moving back and forth a lot. The way I've dealt with "Cancellations" is I have a list called "Waiting" where I stick tasks that are blocked. Sort of like pending review but it could also involve waiting for a resource, a response, etc.
I think if I implement cancellations with details it could help me figure out what processes are broken that caused fires(i.e. this report is suddenly due, overriding everything else. Did I miss a memo? Do we have a solid process for anticipating these sorts of reports in the future? etc.) I could then go back during some planning time to view what needs some brain time.
>This isn't unique to software. It isn't even unique to white-collar jobs. Why does that even need a name?
Kanban originates in Toyota's factory line. The key thing isn't the existence of the list, it's in making people responsible for maintaining and tracking the list rather than consolidating the authority in foremen who direct minions on what to do next. This makes it possible for teams to set priorities collaboratively and move between roles fluidly.
It also establishes a clear order in which things need to be done and an agreed upon subdivision of tasks that make it possible to track the status of work.
IMO the two main points of Kanban (and Agile in general) is limit the size of activities and make the backlog visible. The goal is to empower the team to quickly change priorities.
Of course, It's possible to do that without Kanban, but it requires a lot of management skill, and workers hate changing priorities mid-work. And Kanban/Agile also doesn't assure that it will happen.
Sometimes we go a very long time without doing any explicit planning. Things can tend to get a bit stale if we wait too long.
What I meant by "constantly" was probably more "at any time". The truth is that we cannot commit to a list of priorities for two weeks. There will always be something that comes up and pulls someone off track.
The different between Kanban and 2 week sprints is that, rather than viewing that as a failure, that is seen as responding to business priorities, which is a good thing.
One of the advantages of moving to Kanban in my previous job was that people was that the code quality improved a lot because they were rushing at the end of sprints.
So here's the thing... "Sprints" are not specifically part of "Agile" at all! Look at the Agile Manifesto and see if the word "sprint" appears at all. (Hint: it does not).
So anybody complaining about "sprints" isn't complaining about "Agile", they're complaining about one specific attempt to implement the principles of Agile. Likely that's Scrum, since "sprints" are mainly a Scrum notion. But Scrum is not the only way to do Agile, and it certainly may not be the best. And even within the world of Scrum, there's a lot of variance in terms of exactly how it's implemented.
In reality, there are only things that people are working on, and things that no one is working on. There's no need for a third category of "things that are in the sprint" as long as someone (anyone!) keeps the task queue sorted in priority order.
Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.
The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.
There are two arguments against grouping as a deliverable:
1) sprints are (supposed to be) predictable. So you know when to expect something and can plan other activities around that date.
2) (the more important reason IMHO) a sprint enforces early delivery, where features are rough and not very comfortable to use, but it’s already visible how it will look like. That means feedback can be collected and fueled into the next planning. The assumption is that it’s easier for people to talk about hidden assumptions when they interact with the software, than when they write specs
Sprints are meant to be a tool to measure a team's velocity, defined as average amount of work throughput in X weeks. You don't know the average until a sprint team has worked together for several sprints on similar work.
Sprints can work very well if you need to:
A) Estimate the time it will take to complete a large project
B) Compare productivity of different teams so you can shift or add people
C) Get continual feedback on the work quality and the workflow process
Over time, I've seen sprint teams become very accurate at estimating their work throughput ahead of time. This can be extremely valuable to the business delivering on its goals on time and committing to the right amount of deliverables.
Who prioritizes? On a large team, most tasks require at least some collaboration and discussion. Kanban seems very chaotic for a large team, with priorities constantly shifting. With sprints, everyone on the team is in agreement about the priorities for the next N weeks, and you regroup at the end to iterate.
As a manager, how do I know how long a Kanban task should take? How do I know how long it's been in-progress, or how much is left? (With sprints, the idea is that every task should be defined as completable within N weeks. So it's pretty simple to estimate when deliverables will be done.)
Business is very chaotic. Admittedly, we (where I work) are a very bare-bones team, so we are quicker on our feet than a larger organization.
The main issue we would run into with "sprints" was that the business world-view didn't stay fixed for 2 weeks at a time. There was always something that came up and got bumped in priority. This led to people feeling disappointed that "we blew the sprint".
In reality, "the sprint" doesn't matter. Solving business problems matters. Kanban (Wikipedia says it's just japanese for "billboard" i.e. "big priority board") is just a way of explicitly stating the current priorities so that you can react to them.
> As a manager, how do I know how long a task should take?
You still break down big tasks into small tasks and estimate them. The planning process isn't really any different than with sprints, it's just that you're more free to make trade-offs in real time.
Isn't the idea of the sprint there to protect developers from having the priorities shift under their feet every two minutes? It's easier to get work done if you know you can focus on a task for a few weeks and not be forced to context-switch suddenly.
Under Kanban the way that is protected is by enforcing "don't start something new until your current task is finished."
Obviously life is messy and it doesn't always work out that way, but it tends to be closer to reasonable if you break the size of the tasks down enough. I can reasonably anticipate what I will be doing on a given day. Possibly even the next couple days. I have a good idea what I'll be doing in a week, but any number of things could happen before then.
Another thing to keep in mind is that the changes I'm talking about are "course correction" type changes. I.e. "We have projects X, Y, Z ongoing. Z has suddenly become more important, so we're going to bump it's priority." This is vastly different from a business that is managed incompetently where one day we are trying to sell milkshakes and the next we're in the tuxedo business.
It reminds me of a comment I heard regarding earthquake safe buildings: "They are scarier because everything moves more. But since they move more, they don't fall over"
Wow, I honestly didn't even know that had a name. I worked at a place that did this but I just thought of it as "the only time I've seen Agile actually work".
Kanban seems pretty similar to a method I used in college to track tasks, not even software tasks. This leads me to believe that it is intuitive since it more or less naturally made sense to me before ever knowing Kanban was a thing.
Going to look for this or something like it when job searching.
I dislike Agile, but let's not operate under the assumption that removing or changing the process is going to stop "the business" from wanting more features, faster. There is no process that will make that go away.
Dogma destroys agile. If the team is coerced into behaviour that doesn't create momentum its counter productive, both in terms of morale and buy in on the end goal.
Devs LOVE Agile, the ideas behind Agile and the agility itself.
What devs hate is cargo cults. When management slaps "agile" sticker on your team while having no clue what Agile is about, it's called deception, misrepresentation, misinformation, and exactly what people usually "hate".
You direct your disappointment towards wrongly placed label, not Agile. Hate your incompetent management instead.
I hate agile. And I'm a dev. This is not a matter of hating the wrong thing or not knowing what agile is.
I literally hate agile, i think the definition of agile is loaded.
I propose a new form of project management called "Relativity." The definition of relativity based project management is effectiveness. If something is not effective don't do it, if something is effective do it. Wait aren't devs doing this anyway? Is putting a fancy word on top of this obvious concept pure BS? Is this what agile is doing? No it can't be BS. Not when people can take a class for it. Once a class is made for "Relativity based project management" you know it's no longer BS.
I'm gonna name a new process of walking, but not just walking... effective walking where you avoid obstacles. I'm going to give it a fancy name and call it "Quantum movement." It's different from regular walking as Quantum movement adapts to terrain and avoids obstacles where the priorities of the person who is walking are satisfied.
Agile is the same concept as above. It's different from regular development as it's trying to satisfy the customer.
One alternative I prefer: not specifying any deliverables or deadlines at all. It’s just that mangers often have a hard time selling that to stakeholders. But if you can be in that process, it’s fantastic.
That is “our product is great, but it’s going to be outdated in 10 years, so we’ll put you 5 devs in a room to try to build the Next Big Thing”.
Yeah, a process like this is applicable to maybe 5% of development projects out there, and is definitely not ripe for abuse by all and sundry in the other 95%.
Demonstrate you're producing valuable work on a regular, fixed cadence. Use whateve process you want to do so.
The hard part is defining value somewhere below "the whole project is done." Harder than it sounds, people get it wrong all the time, astoundingly so, almost to the point where I'm convinced it's some sort of evolutionary defect.
Completely agree. But here is the thing: as a developer I'm probably going to dislike any process that management and stakeholders agree is viable. It's not that I expect to find myself in any kind of non-viable process, but I also don't expect to not dislike it.
That is a great way to do software if you have unlimited money. This can be achieved either by working on something that does not yet have any stakeholders and get income from elsewhere or by working at a huge company that has time to spare.
If you want to create a company that is profitable, you absolutely must have a deadline for shipping something. If you don’t decide one yourself then your bank account will do it for you.
One of the problems with "agile" is that no one has a clear idea of what Agile is. Day-to-day, what does an "agile" team do? As a dev, I've encountered many software development methodologies that lay claim to the term "agile". I've hated every single one of them. At what point do I get to say, "Actually, no, it's the idea that's the problem not the implementations"
I think you captured my post better, so I'm just doing it as a reply:
---
"Agile" is like "xml" (or JSON.) Just following a process, or using a technology, doesn't mean you'll do it right. I'm sure plenty of us have come across hair-brained xml, or JSON, that looks like it was designed by a moron.
The same can be said for "Agile." Just because a group tries to follow it, doesn't mean that they follow it correctly or manage themselves the best way.
I'd also like to point out: All of the quote in the article could equally apply to waterfall, or any other software management model.
I agree with this sentiment. As the author said, agile was invented by programmers for programmers but somewhere along the way the army of scrum-certified project managers hijacked it and turned it into something we (or at least I) despise.
The worst part of it: the box-checking. The incessant, never-ending, "was this and this and this and this and this ceremony done", all of which provided no value to the product.
Here's what's interesting... of all the people screaming about how much they hate "Agile", pretty much none of them are proposing any alternative. And if they did propose an alternative, how much you do you want to bet that it would look an awful lot like ... wait for it ... the Agile Manifesto?
It's been said before, even in this thread, but "Agile" as it's practiced today is not the "agile" of the Agile Manifesto. The problem is ignorant managers and consultants who don't actually know anything about how software is developed, want a buzzword to slap on to what they're doing to CYA, and will do stupid shit no matter what it winds up being called.
The entire category of ideas that agile occupies is utter bullshit, and the alternative to bullshit is just common sense. Hire good people, give clear instructions, and leave them alone. The problem with common sense is that you can't make six figures peddling it for a living.
It's the opposite of the Agile Manifesto. These are 3 practical steps to management that apply to any industry where you depend on workers with diverse skillsets, software included. I actually picked them up from "First, Break all the Rules," a general management guide. OTOH, the Agile Manifesto is collection of value judgments that are not only vague to the point of being incomprehensible but also completely ignored by all agile practitioners (i.e. evangelists, coaches, whatever you call them).
I viewed the Agile Manifesto as a sacred text of software development for most of my career. Eventually, I came to understand that this is not a sacred text but a golden calf. It's just a gentleman's agreement between consultants not to interfere with each other's snake oil. It's not a misunderstood document; it simply wasn't intended to be understood.
The problem is that the "agile" of the Agile Manifesto is underspecified to the point of uselessness. I'll quote the Manifesto in full:
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work, we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.
That's it. That's all the manifesto gives us. In a real sense, any methodology at all is "not agile", since agile values individuals and interactions over processes and tools. But while that might work for a small team, it's a recipe for disaster in any kind of larger organization.
Right. which is why I argue that it is important to quit referring to "Capital 'A' Agile" as though it's an actual methodology in and of itself. Agile really just refers to a family of (loosely) related methodologies which purport to adhere to those principles to varying degrees, and where different methodologies make more sense in different settings. Collapsing all of this discussion under the umbrella of "Agile" elides the point that there actually are different approaches for different kinds of organizations, and different projects.
That's ironic since the Agile Manifesto was originally written by software developers, in 2001. The problem is that since then - as Dave Thomas put it in his "Agile is Dead (Long Live Agility)" post
"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
>what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
Worse. I once attended an agile community meetup, and felt like I had just stumbled upon a weird cult. It's scary to think that there are so many software developers out there who have to put up with these authoritarian doctrinaires.
I'm currently part of a team implementing a "next-gen" HMI on an industrial machine. There are too many new technologies, not enough experience and no existing work.
Trying to squeeze this development effort into a Scrum workflow has produced all the problems mentioned in this article. I feel that we're producing a huge pile of crap that will come down on us sooner rather than later.
Our Certified Scrum Master is almost always absent.
Agile Fails for the following reasons.
1) In reality, most stories/tasks that make it out of the backlog and into sprints are the ones that were inserted by PM's, that support the short term goals placed on the PM. End result, massive technical debt in short order. Even if developers express the 'need' for refactoring, it gets delayed as the PM doesn't get fired for a messy code base, but gets fired for a late deadline.
2) Companies 'turned' to "SCRUM" and imagined/expected that by renaming meetings to "stand-ups" etc.. their productivity would increase significantly. This usually resulted in management blaming their engineering staff for their own follies.
3) Most Biz environments don't lend to a 'perfect' scrum model, as such, many organizations try to 'shoe-horn' practices in situations where it doesn't make sense. For example, an organization may not have the ability to adjust features or timelines, resulting in stories being a convenient way to blame engineers for poor decisions outside of their control (Sales selling products that don't exist and promising it yesterday, or Product demanding features that are unrealistic, etc..).
4) Another buzz word that has little functional value other than to help 'experts' get promotions, who in practice are nothing but glorified PM's with a pinch of snake-oil salesmanship.
Agile Fails for the following reasons. 1) In reality, most stories/tasks that make it out of the backlog are executed on, ones that were inserted by PM's, that support the short term goals presented to the PM.
This is a classic example of the problem we're fighting here. Agile is not a methodology and it does not mandate use of stories, a backlog, scrums, etc. Those things are artifacts of one particular methodology which purports to be an exemplar of "Agile" -- that being Scrum.
I really feel like most people saying "I hate Agile" really mean "I hate Scrum".
Devs are such a special kind of people that you should just leave them alone? #sarcasm
I for one like where we are heading with things like Event Storming/Modeling. I admit I care more about solutions than spending time on perfectly describing a problem. Stop the navel gazing. IMHO. Agile tries to solve the Big Issue. Communication.
kanban is for factories to make more cars etc. the boss likes it, the workers, not so as they're pushed by the rule with less leeway.
agile is for software companies to hopefully build product faster, managers like it, developer not so, as daily standup alone pressures developers to stay on track all the time, e.g. less "free" time at work etc.
both are really designed for the owners, not for developers, so it's absolutely normal when you say software developers hate it.
The part missing from agile is the model for what software is and how it is built. If management don't correctly understand the nature of software development, they will inevitably manage it incorrectly, tie it to the wrong accounting measures, and embed an adversarial perspective to their own development teams.
Yeah not having meetings and process is great for a solo developer working in isolation, but it doesn’t scale to even a single team, let alone a much larger organization. Once you go past a single person working on a product, you need some kind of process to facilitate communication.
Once you move beyond yourself you are gonna have a process, either implicitly or explicitly. I vote that it is best acknowledge there is going to be a process regardless of you liking it or not and be explicit and intentional about its formation.
Once you acknowledge that there is gonna be a process you can either start from a known set of processes (scrum, kanban, waterfall, XP, whatever) and then iterate on it until it suits your environment. The alternative is to somehow reinvent the process wheel from the ground up and probably not be as effective as if you had started with proven processes.
It’s like people who start a project and say “all these frameworks suck!!! I refuse use them! Bloat!!!”. Six months later you look at their codebase and surprise, they’ve created their own implicitly defined framework. They won’t call it a framework, but lo and behold they have a framework. Probably worse on every measurable dimension than what they would have had if they started with what’s out there too. Had they been honest with themselves, they could have saved a ton of trouble being explicit that there will be a framework no matter what and had been intentional about its creation/adoption.
Been working Kanban since June, life is better and I think our company is putting out more meaningful features than my last job using agile. We also continuously deploy everyday instead of doing 2 week releases.
It's because Agile as a theory (in a vacuum) works but in practice, fails to be anything but a time sink for most development teams. Agile was supposed to help teams react to change and allow for elasticity in the development process but in my experience, managers rarely allow pushing deadlines or allowing for cutting features. Agile is basically just used by managers as a way to make sure people's velocity is maximized at all times.
233 comments
[ 3.1 ms ] story [ 297 ms ] threadFTFY
I've never seen a non-functioning team start functioning after Agile was introduced. And I've been on plenty of functioning teams that aren't doing Agile.
Agile the process is about as useful as a tiger-warding talisman. Look, ma, no tigers!
There's only two valuable ideas in agile, that are actually broadly applicable.
1. Do continuous integration.
2. If it doesn't make sense to do something, don't do it.
You don't need to get into philosophical discussions over the manifesto, and the purity of your adherence to agile philosophies, or any of that nonsense.
What you do need to do is to go and deploy Jenkins (Or whatever the new hotness is in the CI world), and don't build features that nobody needs.
I think we should stop referring to those things as "Capital 'A' Agile" ( which isn't even an actual thing to begin with) and refer to them by their actual name: Scrum, Scrumban, SAFE, XP, Crystal, RUP, USDP, AUP, etc. At least we can try to make the point more clear that when we criticize these things, we're criticizing a specific "thing" and not some catch-all term. Given that there is no concrete methodology named "Agile" to actually criticize.
It really depends on the customer if that process is something that can't be influenced. Although of course we're as an external party often have more freedom in that regard than a customers direct employees.
EDIT: added some specific questions
The thing is that it appears to be extraordinarily hard to do Agile right. I think that any system that is so difficult to implement correctly is an inherently flawed system.
Interestingly, in many ways they also weren't all that different from what Agile is intending to bring. They still involved something analogous to "sprints", they still allowed for course correction and pivoting during development, and all of that.
Agile seems to position itself as the opposite of "waterfall", but outside of large corporate environments, I'd never seen a shop that actually used waterfall as described by the Agile community.
The problem is that it is usually implemented as a centralized, top-down imposition by management. The net result is usually just a tax on productivity to ever more process, paperwork, status updates, and meetings.
Management didn't skip a beat -- they pivoted to new and innovative ways to push against the guardrails we built for requirements, approvals, agreements and deadlines.
In this case, neither agile nor Agile were the issue.
In reality, I've found that every developer are unique. And together with unique company cultures and projects, the process need to adapt with those things, and not the reverse.
A scrum may work well in a team / project, while it may not work in other.
Which is pretty much the core of the agile manifesto.
It really doesn't. Most of the things people hate about capital-A Agile are things that specifically go against the agile manifesto.
Take a look at the Scaled Agile Framework (SAFe):
https://156s6k36aesz1w6oyx474wo9-wpengine.netdna-ssl.com/wp-...
It's an atrocity of an overbearing bureaucracy created by a committee of consultants that obviously fetishise process.
Take a look at the agile manifesto:
http://agilemanifesto.org
Its very first principle is:
> Individuals and interactions over processes and tools
Take a look at the rest of the principles and compare them to that diagram. SAFe is clearly the opposite of agile. It calls itself "Agile", but it's as non-agile as is possible to get.
What we have here is not the no-true-Scotsman fallacy, it's somebody rightfully pointing out that somebody born in Australia, who has never left the country, with no heritage that comes anywhere near the northern hemisphere, is not, in fact, Scottish.
This isn't true though.
I think the issue with Agile is that software is a field in which is difficult to measure productivity easily. Then Agile comes along and offers the appearance of making it easy to score and and measure team and individual effectiveness. Sure it's "supposed" to be for the team to measure their own effectiveness and empower people to work more productively, but for folks in management roles, the opportunity to 'score' engineers based on Agile metrics is too attractive.
Once it becomes just a way to figure out who's not moving fast enough, or "failing to meet their commitments", of course people will hate it. It gets changed from a tool into a stick.
[0] 'Measuring and Managing Performance in Organizations', Robert Austin, Dorset House, 1996.
I guess upper management could enforce the separation on a level lower management could not override, but I would assume such cases are rare.
Of course, just as with engineers, there are good and bad managers. But it seems pointless to always complain about management being the ones screwing it up all the time.
I just mean that the "metrics" put out by Agile give the illusion of something useful to managers. It's totally understandable that folks in positions of authority would attempt to make use of them. But I think the illusion of objectivity is more damaging to teams than the acceptance of uncertainty.
By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker.
By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.
It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.
I’d love it if developers would be willing to collaborate using a dedicated project management tool and leave the bug tracker for bugs, but the chances of that happening voluntarily are nil. You gotta go where everyone else already is.
What'd that look like, that's different from what they do now? Trying to imagine what developer input to that would look like. I think a lot of devs already feel like existing PM tools they use for sprint tracking and such are worse than if they pushed more planning into git or somewhere otherwise closer to the code, so getting buy-in might not be so hard if devs got to be a little less heavy in a bunch of not-actually-that-useful-to-them tools on a day to day basis.
I think 1/4 of the challenge is what tool to use and 3/4 is convincing and motivating people to be reliable and forthcoming with accurate information. A good project manager demonstrates he or she can add value, unblock things, escalate and communicate appropriately, and not just be the Project Police.
Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold:
1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it.
2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies).
Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good.
Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.
It’s as if we were complaining that elected officials get the crap for mismanaging the country. Well, that’s the point of them doing their job. Our goal is not to all become managers (though some do, exactly for these reasons), it shouldn’t be a ”why don’t you do it ?” rhetoric.
They're useless if you're giving management direct access to team planning & communication tools, of course.
Any attempt to persuade him otherwise just results in him pointing his raygun to his watch. Either he's ignorant, can't or won't understand, or simply doesn't care.
Software management in 2019 is still very much like this. Management has had 40 years to solve this problem, and it looks like it won't be solved in the next 40 either
They do: engineering-led companies are often dynamic success stories, then when they get big enough traditional management works down from the top to lower levels and the firm stagnates.
We work in a field where inherently there are unknows, and measuring the unknown is not gonna be that useful, however we turn it.
The places I've had it succeed greatly have all been new development. We consistently scored stories. Product owners could then had a budget equal to the team's velocity to purchase from the backlog into the next sprint. What it really looked like was they got to arrange the order that the backlog would be picked up and how much would get done in a sprint was an estimate, but with consistent implementation it became eerily accurate over time. It has been my observation that it takes about 6 sprints to calibrate -- where the team scores consistently and the variances from sprints cancel out.
Another point of emphasis is that velocity is a team score. Every failing effort I've been involved with used it to score individuals which inevitably ends up in scoring the stories higher so that an individual gets more points. It also results in cherry-picking easy points and ignoring tasks and bug fixes which may result in zero. It also (like bug fixes) results in everything being assigned points such that points become a proxy for time. If you're developing a new system and you have a bug fix, the team has already claimed the points for that bug fix. You should not make more points for the bug fix, your velocity should actually go down, giving a more accurate estimate in the future of how much new system is actually produced and not a measure of how much a programmer has worked.
So, measurements should absolutely be available to management. But they shouldn't be used to impact future scoring.
I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop.
Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).
I suspect that many devotees of agile would speak at this point about getting management buy-in, or reforming the wider organization, but at this point "agile" just becomes shorthand for "reform your entire organization from top to bottom so that your management doesn't suck".
https://en.wikipedia.org/wiki/No_true_Scotsman
There is, I admit, an element of it in the sprint planning, but that is only meant to be a tool to figure out how much work can be put into the next sprint. Agile does not care what your absolute value of velocity is.
If however, some misinformed PM is obsessing over velocity then I think that is a very different issues and not really related to the essence of agile.
It wasn't a conclusion it was a summation of what is happening when agile ideas are misused. I've seen it used that way too, it never ends way because nobody can measure a programmer's productivity/effectiveness.
But I think the bigger problem is that often developers and management (at all levels) give very little thought into "delivering value" and a lot of thought into "doing whatever they want".
I can't fault individuals (workers, management, or executives) for trying to do what's best for their careers rather than what's best for the company. As a manager, I think management's primary objectives are to set up their reports for success and to figure out how to align their reports' incentives with the company's incentives in the best possible way.
Management, I have seen, often does a terrible job 1) actually knowing what "value" is, 2) figuring out how to measure that they're actually delivering value, and 3) figuring out how to align delivering value with the worker's own incentives.
If you can't do these things, you have NO chance to do agile effectively. It's easy to go through the motions of Agile, but you will gain nothing if you can't define and measure value (and hardly any companies can -- it's not easy!)
But as you pointed out, even if you can accomplish the prerequisites, it's still INCREDIBLY difficult to attribute an engineer to value. You can execute effectively, but be on a project that turned out to be useless. Making the button green might be easy, but because of previous technical debt, making it blue might be really hard, etc...
That sounds like a cultural problem. From my experience, tools do not solve cultural problems. Leadership changes cultural problems.
I'm saying that it seems to be a problem at the vast majority of companies of all sizes.
* Often the financials of a company are "need to know" or obfuscated (Y-Axis unannotated)... * The financials are regarded as irrelevant to engineering (by management, finance AND engineering) * The estimates of where the value lies is often just a spreadsheet sucked out of the thumb of somebody in marketing who already has a eye on his next job. * Nobody _ever_ goes back and closes the loop and evaluate the value estimations and the value estimation process, so the company never learns to do better. * Let a drooling slob of an engineer talk to a customer? You're joking Right?
And yet engineer is all about tradeoffs, we make several per day under the illusion we know which are wise....
The software architecture is falling apart, the tech debt overshadows the actual debt of a small country, our subject matter expert quit the company over being micromanaged, and the clients are abandoning our buggy software for our competitors? What went wrong, we closed all of those JIRA tickets, surely that must be good for something.
I’ll add this — To a large extent, many management systems are about reducing the failure modes — but I don’t see why a system must downplay creativity and deep thinking about the core business engine (often the software).
When I worked in teams following the agile process, we were rigid.
Agile shouldn't be a process, mgt see it as such. It becomes a process. Clever engineers hate poorly thought out processes. Agile as a process is a contradiction in itself.
Agile is no process. Let the team find their ways and iterate as often as possible, along with a few other proven principles.
Points becomes estimates for managers, they will see it as such and build huge waterfall projects documents to track everthing, and they will pressure teams to deliver shitty software when they feel the stories are sand bagged.
Strange world we live in.
When I worked in teams following the agile process, we were rigid.
"The Agile that can be named is not the true Agile."[0]
I'm not being entirely facetious.
[0]https://en.wikiquote.org/wiki/Tao
Yup that's exactly it. Or to put it more delicately (than simply a "power grab"): a façade that servers various ulterior purposes -- from making their company seem hip and modern (to the uninformed) to simply being able to say "finally we have some structure!" even though it's very debatable whether new "structure" really brings the benefits that it claims to (and evidently brings many negatives on board with it).
But ultimately - a façade.
And we're going to do agile! It will be great! How are we going to do so? According to this rigidly-defined process, that's how.
Most of the problem described in the article -and everywhere- is precisely that "the theory is good but everybody is doing it wrong".
But that doesn't really help, because it overlooks the fact that the origin of all this is just a pile of generic, hard-to-argue small-time guru ruminations. I mean, it is not necessarily bad advice: "These are valuable things and we think that in particular these ones are more valuable than those other ones". Okay. Probably. They do look good. Let's say they are. Now what? Oh, that's left as an exercise to the reader.
It's funny. Just yesterday I almost had an argument over one of these things. I heard Karen say to the guy on my left that "Agile means less documentation", so I raised my eyebrow. "Agile means less defined documentation, more open, because documentation has no value at all" - she added. I was about to point out that that is not at all what it means, but then she went further and told him that what he needed to do was to "work as a team and become more involved in collaboration". That, right there, is the problem: pretending a bunch of cool sounding expressions can be a substitute for actual things like writing down what they wanted the guy to do.
-value trust over plotting and scheming
-value open communication over hoarding information and deception
-value disarmament over preparing for battle
While we value the things on the left, we value not getting steamrolled by people who practice the things on the right even more.
There's value in enumerating important principles for consistently pursuing quality work product. That's why the Agile Manifesto has value. The manifesto is just a manifesto, a statement of intent and principle, and not a methodology in and of itself. One doesn't need a published, monetized methodology to engage in agile software development. One simply needs a methodology -- whether unique to one's project, or widely known -- that reinforces those principles to engage in agile software development.
The biggest problem with agile software development as a concept is that it, like any other elaboration of any principles of quality work, is that most people will fail to see the forest for the trees, will marry themselves to some well-marketed thing that pretends to be about principles, and will end up largely doing the same dumb crap they've always done.
Sometimes just documenting what the thing is supposed to do and why would solve so many issues, but since people have gotten hooked on capital-A Agile so much has gone by the wayside, or been delegated to non-technical roles.
No, that's not the problem with the five values and twelve principles.
In fact, the problem is the desire to have a single, divinely ordained methodology (which both the first value and twelfth principle reject, and that rejection is arguably the central basis of Agile.)
OTOH, while it is good that the Manifesto and Principles don't ordain a methodology a it's bad that they are written in a way which makes it harder to extract actionable direction than is necessary.
Eventually, things changed, but for a while there it was awesome. Things got done well, in reasonable amounts of time, with a lot of attention to quality work.
I think the beginning of the end was probably around the time when the company (a software development consultancy) started using fine-grained hourly measures of time pre-sold to clients. This started happening around the time investors in certain clients got more involved in trying to dictate company policy, and I'm pretty sure it was all part of an attempt by investors to ensure there were "better metrics" for evaluating their investments.
You can't measure something without it directly affecting the measured thing's state. In this case, it started having detrimental effects on almost everything. Previously happy and productive devs started burning out, mediocre devs became new management favorites, more bugs got into production, projects suffered under less and less reasonable goals (including at one point my task effectively being to solve one of the Hard Problems of software dev -- cache invalidation), and so on.
In the US, management culture seems to have a monomaniacal focus on metrics. (I'd say "simplistic metrics", but the way they use them guarantees they're always simplistic.) This is driven, in part, by bureaucratization, which is in turn driven by a bunch of other things (mostly stemming from politics, directly or indirectly) in our business culture. Many managers would complain that without metrics they can't evaluate team productivity, individual value to the organization, and other important stuff, and they're right. The solution is not to double down on those metrics obsessions, though; it's to replace those managers with managers who are capable of effective, qualitative evaluation, instead of the almost purely quantitative approach that holds the high ground.
One nice thing about this is that the metric is visible. Then you can optimise your performance against it. Is this necessarily productive, or in the real interests of the company? Maybe, maybe not. But I look at this as a kind of a favour: if your boss is complaining "velocity is too low" well, at least you know what you're being measured by. Put some extra points on those stories. Undercommit. Make your boss happy and get them off your back. You'll be doing the same work either way.
There is a board. The board has a prioritized list of things to do. You work on your thing until it is done. Then you pick your next task based on where the priorities currently sit.
It's really not far off from the "sprint" idea. The main difference is it is a constant re-balancing rather than an every X weeks affair.
Generally you cannot fix things you do not have control over. Kanban is meant to have a process person fix the bad bottlenecks - not the developers, not the managers - and said person is supposed to have the clout to pull it off. I've never seen Kanban implemented properly.
As for the example - if testers are not keeping up, either you hire more or enhance testing methodology. Throwing developers at it slows down development moving the bottleneck. (Of course, throwing some developers to provide better testing methodology, testable components or automation would be a proper fix.)
The example you gave is a good one - devs spend their time making improvements to to code or the test automation to make the testing more effective, if testing is the bottleneck to delivering finished features. Throwing more code/features over the wall when that code isn't actually being tested isn't real progress.
In principle, the manager/lead would tweak guidance until the most expensive resource (dev engineers) are the actual bottleneck. I guess of course teams/companies that care less about quality might just tell the testers to test less thoroughly in order to get their work items through the system faster, but at least it's a conscious decision.
I've worked for teams where they literally close every testing ticket once the code is pushed to production regardless whether the testing has been done. 'tested in production' - that's one way to keep up I guess...
See, Kanban only works when the focus is on quality. It's the main secondary premise of the original Toyota approach of Lean which spawned Kanban. Note that it starts with minimizing waste (in programming, tree breakage or waiting on tests) and secondly minimizing overloads. The philosophy is kaizen, continuous improvement. Sacrificing quality is not an improvement, Toyota itself started by breaking process into quality assured steps to fight waste due to rework.
Otherwise anyone can push undone paper tickets over the wall and that's not the point.
I love Kanban, it's all about minimizing work in flight, to allow you to focus on the task at hand until it's Done instead of hurrying to meet the sprint deadline.
- make sure that developers have some slack time, so that they can cater to their tools and study new things
- never move back an item to a previous column. If something more important came up, you “cancel” the current task and start the new one. This helps to identify bottlenecks
Could you explain this a bit further? I'm imagining three columns, todo / doing / done, and I'm working on a widget when I'm asked to put out a fire. I'd imagine that the fire is moved from todo to doing and that the widget work is moved from doing to todo, but it sounds like you're advocating for something different.
Could you explain more about it or link to resources that might help me understand? Thanks!
Moving items back makes this harder (although possible). What I saw some teams doing was to mark such items as cancelled, explaining in the tickets why they got cancelled, so that a manager can then see which columns (i.e. steps of a process) are interrupted more often. This could point to a bottleneck in this process.
In the near future, the "rest" of the cancelled ticket would make it back into the backlog as a new ticket entirely. This has the added benefit of keeping your backlog cleaner.
I think if I implement cancellations with details it could help me figure out what processes are broken that caused fires(i.e. this report is suddenly due, overriding everything else. Did I miss a memo? Do we have a solid process for anticipating these sorts of reports in the future? etc.) I could then go back during some planning time to view what needs some brain time.
Thanks for suggesting this!
When you recreate a ticket that was cancelled, you are compelled to review its scope and adjust accordingly.
Kanban originates in Toyota's factory line. The key thing isn't the existence of the list, it's in making people responsible for maintaining and tracking the list rather than consolidating the authority in foremen who direct minions on what to do next. This makes it possible for teams to set priorities collaboratively and move between roles fluidly.
It also establishes a clear order in which things need to be done and an agreed upon subdivision of tasks that make it possible to track the status of work.
Of course, It's possible to do that without Kanban, but it requires a lot of management skill, and workers hate changing priorities mid-work. And Kanban/Agile also doesn't assure that it will happen.
What I meant by "constantly" was probably more "at any time". The truth is that we cannot commit to a list of priorities for two weeks. There will always be something that comes up and pulls someone off track.
The different between Kanban and 2 week sprints is that, rather than viewing that as a failure, that is seen as responding to business priorities, which is a good thing.
Quality of life increased a lot, too.
So anybody complaining about "sprints" isn't complaining about "Agile", they're complaining about one specific attempt to implement the principles of Agile. Likely that's Scrum, since "sprints" are mainly a Scrum notion. But Scrum is not the only way to do Agile, and it certainly may not be the best. And even within the world of Scrum, there's a lot of variance in terms of exactly how it's implemented.
In reality, there are only things that people are working on, and things that no one is working on. There's no need for a third category of "things that are in the sprint" as long as someone (anyone!) keeps the task queue sorted in priority order.
Sprints can work very well if you need to:
A) Estimate the time it will take to complete a large project B) Compare productivity of different teams so you can shift or add people C) Get continual feedback on the work quality and the workflow process
Over time, I've seen sprint teams become very accurate at estimating their work throughput ahead of time. This can be extremely valuable to the business delivering on its goals on time and committing to the right amount of deliverables.
As a manager, how do I know how long a Kanban task should take? How do I know how long it's been in-progress, or how much is left? (With sprints, the idea is that every task should be defined as completable within N weeks. So it's pretty simple to estimate when deliverables will be done.)
The same people that did before.
> Kanban seems very chaotic
Business is very chaotic. Admittedly, we (where I work) are a very bare-bones team, so we are quicker on our feet than a larger organization.
The main issue we would run into with "sprints" was that the business world-view didn't stay fixed for 2 weeks at a time. There was always something that came up and got bumped in priority. This led to people feeling disappointed that "we blew the sprint".
In reality, "the sprint" doesn't matter. Solving business problems matters. Kanban (Wikipedia says it's just japanese for "billboard" i.e. "big priority board") is just a way of explicitly stating the current priorities so that you can react to them.
> As a manager, how do I know how long a task should take?
You still break down big tasks into small tasks and estimate them. The planning process isn't really any different than with sprints, it's just that you're more free to make trade-offs in real time.
Obviously life is messy and it doesn't always work out that way, but it tends to be closer to reasonable if you break the size of the tasks down enough. I can reasonably anticipate what I will be doing on a given day. Possibly even the next couple days. I have a good idea what I'll be doing in a week, but any number of things could happen before then.
Another thing to keep in mind is that the changes I'm talking about are "course correction" type changes. I.e. "We have projects X, Y, Z ongoing. Z has suddenly become more important, so we're going to bump it's priority." This is vastly different from a business that is managed incompetently where one day we are trying to sell milkshakes and the next we're in the tuxedo business.
It reminds me of a comment I heard regarding earthquake safe buildings: "They are scarier because everything moves more. But since they move more, they don't fall over"
Going to look for this or something like it when job searching.
What devs hate is cargo cults. When management slaps "agile" sticker on your team while having no clue what Agile is about, it's called deception, misrepresentation, misinformation, and exactly what people usually "hate".
You direct your disappointment towards wrongly placed label, not Agile. Hate your incompetent management instead.
I literally hate agile, i think the definition of agile is loaded.
I propose a new form of project management called "Relativity." The definition of relativity based project management is effectiveness. If something is not effective don't do it, if something is effective do it. Wait aren't devs doing this anyway? Is putting a fancy word on top of this obvious concept pure BS? Is this what agile is doing? No it can't be BS. Not when people can take a class for it. Once a class is made for "Relativity based project management" you know it's no longer BS.
And what is the alternative that you would prefer?
Agile is the same concept as above. It's different from regular development as it's trying to satisfy the customer.
That is “our product is great, but it’s going to be outdated in 10 years, so we’ll put you 5 devs in a room to try to build the Next Big Thing”.
I did that and it was great.
Demonstrate you're producing valuable work on a regular, fixed cadence. Use whateve process you want to do so.
The hard part is defining value somewhere below "the whole project is done." Harder than it sounds, people get it wrong all the time, astoundingly so, almost to the point where I'm convinced it's some sort of evolutionary defect.
If you want to create a company that is profitable, you absolutely must have a deadline for shipping something. If you don’t decide one yourself then your bank account will do it for you.
I am neutral to slight dislike towards it. If I see someone talking about it, it usually means it is the kind of place I don't want to work.
---
"Agile" is like "xml" (or JSON.) Just following a process, or using a technology, doesn't mean you'll do it right. I'm sure plenty of us have come across hair-brained xml, or JSON, that looks like it was designed by a moron.
The same can be said for "Agile." Just because a group tries to follow it, doesn't mean that they follow it correctly or manage themselves the best way.
I'd also like to point out: All of the quote in the article could equally apply to waterfall, or any other software management model.
The worst part of it: the box-checking. The incessant, never-ending, "was this and this and this and this and this ceremony done", all of which provided no value to the product.
It's been said before, even in this thread, but "Agile" as it's practiced today is not the "agile" of the Agile Manifesto. The problem is ignorant managers and consultants who don't actually know anything about how software is developed, want a buzzword to slap on to what they're doing to CYA, and will do stupid shit no matter what it winds up being called.
That's pretty close to what the Agile Manifesto says.
I viewed the Agile Manifesto as a sacred text of software development for most of my career. Eventually, I came to understand that this is not a sacred text but a golden calf. It's just a gentleman's agreement between consultants not to interfere with each other's snake oil. It's not a misunderstood document; it simply wasn't intended to be understood.
It is not management manual nor specific.
Here's the true Agile Manifesto:
1. Sack all your product owners and scrum masters, because they are useless and a waste of the salaries which they get paid.
2. Reduce a development team so it's no more than 5 people.
3. Give them god admin access to everything they need to run the show (cloud, CI, dev tools, etc.).
4. Tell them what you need
5. Get out of their way until it's done.
The biggest problem with the agile manifesto is that armies of agile consultants and scrum masters have never heard of it.
"The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products."
(https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)
Worse. I once attended an agile community meetup, and felt like I had just stumbled upon a weird cult. It's scary to think that there are so many software developers out there who have to put up with these authoritarian doctrinaires.
Trying to squeeze this development effort into a Scrum workflow has produced all the problems mentioned in this article. I feel that we're producing a huge pile of crap that will come down on us sooner rather than later.
Our Certified Scrum Master is almost always absent.
It's just tiring.
This is a classic example of the problem we're fighting here. Agile is not a methodology and it does not mandate use of stories, a backlog, scrums, etc. Those things are artifacts of one particular methodology which purports to be an exemplar of "Agile" -- that being Scrum.
I really feel like most people saying "I hate Agile" really mean "I hate Scrum".
I for one like where we are heading with things like Event Storming/Modeling. I admit I care more about solutions than spending time on perfectly describing a problem. Stop the navel gazing. IMHO. Agile tries to solve the Big Issue. Communication.
agile is for software companies to hopefully build product faster, managers like it, developer not so, as daily standup alone pressures developers to stay on track all the time, e.g. less "free" time at work etc.
both are really designed for the owners, not for developers, so it's absolutely normal when you say software developers hate it.
Agile = Lots of meetings.
Agile = Releases done on fixed schedule.
Agile = User stories defined by product owner.
Productive Developer = Litte/No process
Productive Developer = Little/No (formal) meetings
Productive Developer = Releases as soon as ripe to release
Productive Developer = Doesn't need product owner. Actual usage and metrics tell productive developer what to do next.
Agile <> Productive Developer
People over processes, deliver often, with frequent communication between the business people and developers.
[0] https://agilemanifesto.org/ [1] https://agilemanifesto.org/principles.html
Once you move beyond yourself you are gonna have a process, either implicitly or explicitly. I vote that it is best acknowledge there is going to be a process regardless of you liking it or not and be explicit and intentional about its formation.
Once you acknowledge that there is gonna be a process you can either start from a known set of processes (scrum, kanban, waterfall, XP, whatever) and then iterate on it until it suits your environment. The alternative is to somehow reinvent the process wheel from the ground up and probably not be as effective as if you had started with proven processes.
It’s like people who start a project and say “all these frameworks suck!!! I refuse use them! Bloat!!!”. Six months later you look at their codebase and surprise, they’ve created their own implicitly defined framework. They won’t call it a framework, but lo and behold they have a framework. Probably worse on every measurable dimension than what they would have had if they started with what’s out there too. Had they been honest with themselves, they could have saved a ton of trouble being explicit that there will be a framework no matter what and had been intentional about its creation/adoption.
http://programming-motherfucker.com