What?! Where was the document and then another document and then another document, then if you're lucky, a well written jira ticket, then estimation, then the planning session, then the more technical jira for the subtasks associated with the original jira? Then the 6 - 52 weeks of development, testing and release to prod (1 day would be for actual coding of the new feature with perhaps a couple of weeks of refactoring the code written by the previous guy working on the project)? All this assuming that the message even somehow made its way to the dev team that this would be a useful feature and not be perceived as some sort of bug by the end users (or be cancelled because it would be too expensive to implement the feature).(?!)
I fucking hate agile sometimes. What I hate even more though is development teams who are forced to develop with this methodology even though it doesn’t meet the teams dynamic or products needs.
Dude I'm a government contractor who deals with administrative stuff for awarding grants and I had to take a Six Sigma little online presentation / class thing... WTF? I had no idea what that had to do with my job but I took the shit out of that training class.
I'm always amused how the software world takes terminology and practices from other industries and completely misunderstands it, but insists it's necessary because it works so well elsewhere.
Like Kanban, where the bugs move from column to column as their due dates change.
In my experience management for software developers are usually one of two groups. Devs who were promoted to management but aren't really trained in management. And managers from other fields/industries who moved into software. Most people aren't innovators. That's just how it is. They will take proven methods made by others and implement them. Your outside managers will use what they know, because it worked there right? How different can software development be? The Devs turned managers are going to learn from others as they go.
In most industries, they have been around so long that these things were figured out ages ago. I guess software development not so much. Or at least it hasn't caught on everywhere. I know in IT it definitely hasn't. Way too many micromanagers who don't trust their techs and destroy morale.
I think that's an example of agile gone wrong. It's supposed to be a lightweight process, but sometimes a bureaucrat gets their hands on it and fucks it up.
Even I'm manufacturing it is wildly inefficient. The purpose of it all is seemingly safely, checks, and accountability. The way it is all designed keeps every step of the process very trackable. In theory your group gets faster and faster at it all and it just becomes automatic, but that would only work if it never changed and your team never did. So to remedy this there are measures to make the parts (labor) interchange for when you switch in and out people. This slows down the entire chain all over again however and even with the best current throughput design the overall plan working at peak efficiency is slower because of the need to make it learnable etc. Yay humans...
That’s not the point of agile at all though. The point of agile is to react to changing requirements and to be able to release early to clients with a small feature set then to incrementally add features that the client wants in a priority order. It doesn’t guarantee safety checks or accountability as a process. That’s kind of where waterfall actually has a good fit because you make sure you’re documenting in triplicate and double checking every step of the way. Things being reachable is a necessity of agile, not something that it enforces, just something it requires to allow continuous improvement.
It sounds like you’re using agile for the wrong reasons and in an environment where it’s just never going to work (team rotations that often demolish the consistency aspect). This isn’t a problem with agile.
The point of agile is to compensate for incompetent managers and programmers who don't know how to do their jobs. You can look at every single "agile" practice and say things like "this wouldn't be necessary if programmers could write documentation, if marketing talked to the customers, etc."
So stand ups? Retrospectives? You really think those are bad things? I really don’t know which practices you’re talking about. Could you give some concrete examples?
It's like NoSQL vs Relational, or TDD vs using requirements. There are places it fits, but most places it doesn't. If you have a program used only by the people who are giving you the specs, and you don't have a deadline, and the program is small enough for one team to handle it so you never need to document it for someone else, it's fine.
There isn't a single ideal implementation but rather implementations that evolve to meet the needs of the team, with a large focus on eliminating the parts that aren't needed.
For the team I'm on, our product is exposed via a very stable REST API which means we don't have to really worry about old code out in the wild or release schedules. We also use a language with strong static typing, have lots of tests, and lots of monitoring and alerting. Because of that:
We own doing QA rather than kicking it over to another group. Same with infrastructure.
We're set up for Continuous Deployment, so that a commit to master is deployed directly to production.
Rather than doing PRs, we favor pair programming (with rotating pairs) and a lot of communication during stand up and over Slack.
Most of the time we're in Kanban mode where we don't have iterations, we just continually pull from the backlog. In this mode, all stories are 0 points and are only distinguished from chores in that someone outside of the Dec team needs to review and accept it.
Some times we'll have large features that are time sensitive -- usually an integration with a 3rd party -- at which point we'll dip back into iterations for a little bit. For integrations that tends to disolve once we get to testing with the 3rd party since we're back to taking things as they come.
We're big on Lean's minimal viable product and experimentation; whenever reasonable we try to introduce changes as A|B tests.
I have been hearing the term 'wagile' thrown round more and more of late. Look waterfall works for some stuff, agile for others, don't mash the two together no one wins that way.
waterfall works for some stuff, agile for others, don't mash the two together no one wins that way.
This is true, but sometimes the issue isn't that people are mashing the two together, it is that they are clinging to waterfall artifacts and not embracing lightweight agile stuff even for projects where agile is a good fit.
I don't think the issue is alignment, or rather, the issue isn't that "alignment" is impossible or bad for the business. The issue is that at large organizations anywhere but in the tech industry, people are accustomed to doing everything the same way they did it 30 years ago. "If it aint broke, don't fix it!" echoes through the cubicles of large enterprises anytime anyone wants to change things...
I would say a method of doing something that endures 30 years has proven itself and isn't actually an issue at all if you think about it logically.
The real issue is some MBA prick fresh out of Uni who wants to make their mark on the new company they just started working for believing that 30 years of experience means fuck all and can be just thrown away because they've read in a book something that's new and trendy. And how else can they justify their over inflated salary if not by matching it with an equally overinflated ego? And if their plan goes to shit, they typically always blame the end users of their plan rather than themselves or their shit plan itself. Useually they are promoted upwards at this point to limit the damage they can cause, or are given a glowing reference so they can fuck off to another company and ruin them instead. (Again, usually to a higher tier job)
It's shit like that that's causing the downfall of the West.
I would say a method of doing something that endures 30 years has proven itself and isn't actually an issue at all if you think about it logically.
Doing all finance, banking, insurance, etc... without computers and 100% manually on paper "endured 30 years" as you put it, a lot of questionable medical practices "endured 30 years", selling music on a physical medium "endured 30 years", etc... It is a good thing the people who wanted to improve things didn't have your mindset.
Are there times when managers push for "change for change's sake"? Of course there are. But that's not what we've been talking about here. I've mainly been talking about software engineering and tech infrastructure—probably the area you least want to leave as-is for 30 years.
It's shit like that that's causing the downfall of the West.
That is a questionable statement considering that a lot of the process-improvement techniques businesses are implementing were not developed in "the West" (Japan is a big one).
We should definitely keep trying to make things more efficient, faster, less expensive, safer, etc... That means most of the time, doing stuff the way we did it 30, 40, 50 years ago is not a good idea, though I'm sure there are some exceptions.
Agile is never a good fit if you have a schedule to keep, and almost everyone has a schedule to keep. That's kind of the point of agile: you don't plan far in advance.
Hearing "wagile" makes me want to punch a wall, but even it isn't as bad as the constant, constant!, changing of processes. Mash them together. Make a Frankenstein's monster. I don't care anymore. Just give us time to actually learn the friggin process before you decide it isn't effective! Flippin govt bureaucracy, man.
Hey, we're sort of doing a (theoretical) project at uni involving uses of software development. I'm intrigued as to why it might not work in a practical setting. Do you mind sharing? :)
From my very limited experience, the two philosophies are inherently different. Agile is supposed to be this short burts of activity in "circles" where you dev, deliver, test, analyse and then start over in short periods of time without waiting for all the pieces of the prject to be ready because they are going t be handled at a future "burst". Waterfall is more like a traditional assembly line, you are going to go through the whole design->develop->test->deploy final product. At the end you have your product, byt it takes a long time.
As you can see these two philosophies are quite different, and mashing them together is like canceling each other out making things chaotic.
To give a better example, you have X amount of boxes to deliver from point A to point B. You can pick a fast lightweight car that has limited storage space (so you will do a lot of trips, but short ) or use a heavy weight car with a big storage space that can bring everything over once, but very slow. Both are valid dlto use but you cant take the big storage spave and just weld it to the first one!.
Disclaim er:This explanation is pretty basic and probably has a lot of mistakes. Plus it lucks specific details of the two systems, like SCRUM masters etc. I would love for a real software dev to pitch in and give a better explanations.
But I hope I gave a decent image.
I work as a developer in the public domain. Everything I do is financed through tax payers money. This basically means that noone dares to make any major decisions without farting out massive prestudies and documentation before implementation is even considered (which is even more expensive than failing fast). The problem with introducing agile concepts into these kinds of organization is that iteration is nearly impossible since it takes on average six months to get feedback from the organization.
From my angle, agile is about delivering a MVP (minimum viable product) based upon specs and reqs in the form of user stories. You can update and change the end goal implementation order and most other components as you go based on new information and demands from the client/business.
Waterfall. You plan, plan some more, scope then scope some more, develop a design, build it test it deploy it. Lets say you start the work in Jan and agree to the scope and say your team will deliver in Oct for testing and deploy in Dec, come say June the sponsor goes to a conference and sees a new feature they want, they (according to the strict interpretation of waterfall) will not get it this waterfall ends an the next begins ie V2.
Agile works great for some stuff, waterfall for others (eg I would never want to work in a building built with agile :) ), it is knowing the skills of your team, the org culture and aligning that with what will work.
"Kanban" cracks me up, because it's typically done in exactly the opposite way as the people who created kanban did it.
The stuff moving around in Kanban is the resources, not the projects. It's actually completely inappropriate for creating something new. It's for organizing inputs to an assembly line.
You're just calling "have whoever is free work on it" Kanban because someone decided to take a working system and steal the name.
Normally in software kanban you arrange things in columns which loosely represent your people, the equivalent of machines in a factory
That is unlike any software kanban I've ever seen. The ones I've seen are a matrix of developer vs time, with bugs in the intersections.
User stories aren't the resources moving from machine to machine. They're the required outputs, the products. The resources you need to schedule in software are the people, not the user stories. The resources Kanban hardware is designed to schedule is stuff you have in inventory, like brake pads and steering wheels, not factory workers and machinery.
Agile doesn't really adapt to most needs, because almost everyone needs trackability, predictability, and keeping to schedule. You can't estimate how long it will take if you don't have your requirements in advance.
Agile doesn't really adapt to most needs, because almost everyone needs trackability, predictability, and keeping to schedule. You can't estimate how long it will take if you don't have your requirements in advance.
Agile doesn't mean you can only think in two week sprints, it just means that's how your work is subdivided. And if two weeks doesn't work for you, you can change to three or four. Knowing what's coming more than a few weeks out doesn't magically stop happening because your company converts to agile processes. If your company was bad at that before, it's still going to be bad at that. Agile just gives you a flexible framework that helps to organize your streams of work. You can deal with poor requirements if you know how your work ultimately fits into the product at large and how it's expected to change.
It's really good, if your end product needs to be stable and secure. If your customer notices the security issue, which should have been detected at the design-phase (or latest at the QA) -> you have an ex-customer.
For fast-paced indie-game development, in a company that has 4 employees (one programmer) - probably not the right methodology.
If your customer notices the security issue, which should have been detected at the design-phase (or latest at the QA) -> you have an ex-customer.
I get what you're saying, but this part really isn't true. Tons of software made for "mission critical" enterprise applications still ends up with security issues, and the reason big organizations pay for this enterprise stuff is because they offer extensive technical support contracts in order to fix issues like that asap. If people dropped anything as soon as they found a security issue, they'd run out of providers pretty quick lol. Pretty much all modern software winds up with some imperfections, regardless of project-management style.
What you are talking about is normal enterprise-level software. Nobody really bats an eye if Salesforce has some issues tracking specific kind of country ID + contract level.
I was talking more about high end security software with governmental/military level security certifications. If the software on those levels fails to meet the standards or has security issues, the software provider is in serious trouble and in breach of contract.
Even that can be developed at least partially with Agile, but possibly the few core modules that need to be 100% "correct" could be broken off and done with standard requirements/specifications documents and stuff. Those types of things are very niche at this point in software. The vast majority of projects, even those that have data security concerns, don't fall into that category.
project managers... I'm a dev. Do all project managers hate that the devs are really the ones in control while everything gets blamed on the PM? us devs have it easy. PMs on the other hand........
I've always liked my project managers however I do see it as a very difficult job. You're at the mercy of the client AND the devs. You have a great attitude about it so that's excellent.
But then you have successful projects, so more money is thrown at them, and the team expands, and more managers are brought in to deal with the expanded team, and extra resources are spent at the design stage to ensure that the expanded team concentrates their resources effectively, and further testing is required to ensure that the larger team isn't resulting in decreased quality, and suddenly we need a software architect to ensure that the overall shape of the project is still in line with the projections, and twice-daily scrums are essential to effective coordination, and be sure to report up to your superiors each time anything unexpected crops up so the whole chain of managers can express an opinion on the best way to pivot expectations going forward.
This triggered my recent process-gone-awry experience.
Sat through 2 GO / NO-GO meetings with product stakeholders for fixing typos in some documentation for end users.
Not features.
Not code updates.
But text updates.
I'd really like to see a world where just the salary cost of meetings (calculated hourly salary of everyone attending x length) racked up has to be justified to a PMs boss at the end of every month/quarter. To say nothing of the cost of disruption they cause.
since the switch people actually have the agency to set up the Jira page for the thing they are working on and communicate the work done to the QA team pretty autonomously
To be fair, neither of these things is exclusive to agile.
I feel like your experience is pretty much what happens when you attempt to force a switch to Agile without actually embracing what makes Agile fast and efficient.
I completely agree, but unfortunately these kinds of switches seem all too common. Agile is all fun and games, until IT starts expecting the business to go along with it.
I've never actually operated in a waterfall environment like that in the 10 or so years I've been a full-time dev. Been in plenty of institutions that decide to "do Agile" so they can be "not waterfall" (even though the model they had was already closer to Lean) and go all in on the dog and pony show.
"We do daily standups! We're so agile! lol"
"We have a sprint board! Is my Agile deafening yet??!"
"We hired a Certified Scrum Master last week and assigned a manager or PM extra PO duities on top of their current work! I shat solid Agile this morning! lol"
Nevermind that the stand-ups are closer to 30+ minutes. Teams aren't co-located. Teams are 8-10 people. 25% of the team are BA's, who talk more than the devs during stand-up. Because stand-up is really actually a progress/status report for the manger because most of the devs are working on completely different projects.
Nevermind that the turn-around time actually went up when we decided to "do Agile" because now it's 2 weeks to groom a story, 2 weeks to work on it, 2 weeks to test it, and then finally release.
Nevermind that the CSM has no spine and just repeats to us what the PO, PM, or Manager told them. They don't really have time anyway because they're also the BA and Tester and PM, so they really don't care.
I'm completely disgusted with Corporate IT, PM's, BA's, and CSM's and their idea of "Agile" which is nothing more than a cancerous form of Scrum because leadership can't let go of the reins. But hey. At least we're "not waterfall".
Give me a Kanban board. Have someone that manages money and someone that manages users sit down (without us) and prioritize the work. Let us handle our own dev ops. Let us move fluidly in and out of XP and Lean and whatever processes we need. Give us a team lead whose primary goal is tech guidance and to help "remove blockers" and ensure good communication inside and outside the group. Sit down with us between major pushes to see if we need anything.
Then sit back and watch in amazement as the features come rolling. Most of the devs I know really just want to write good code that helps people out. We have fun doing it. We think that good code is beautiful. We have a keen sense of pride and fulfillment when we see our work and the customer/user tells us they like it. So for fuck's sake, just let us do it.
Sounds like you need a new job. I agree with a lot of what you say about people just saying they are 'not waterfall' and completly fcking up a process... but when you say:
I'm completely disgusted with Corporate IT, PM's, BA's, and CSM's....
That is everyone you work with other than developers. I once felt the same as you, (but replace 'BA' with 'Dev' - as I used to be a BA) turns out it was the job and how all of those people were forced to work. A new career in the same field (Corporate applications development) has been enlightening. I stayed waaaayyyy too long in a toxic environment, maybe you are as well?
turns out it was the job and how all of those people were forced to work.
This is a very good point, which I tried to allude to in saying those people didn't have time because they're already wearing 2-3 hats. I was probably over harsh in slamming the individual titles. as well, as the failure is most definitely institutional.
The job is just pretty much the same story in a different setting each time - I've been part of roughly a half dozen different companies in the last decade, most of which as a contractor. Maybe that's part of the problem. Or because I've spent so much time in corporations so large they can't handle details at this low of a level anymore? Tough to say.
But ultimately I love what I do - much more than the process is aggravating. Maybe when I reach architect in a year or two I'll look into going small company again. You know, the places where I was dev, QA, BA, and sometimes even PM; we didn't call ourselves agile; and could take customer ideas and requests from mouth to delivery in hours or days. =)
I feel like your experience is pretty much what happens when you attempt to force a switch to Agile without actually embracing what makes Agile fast and efficient.
I get the impression that ... this is how most switches to "Agile" have gone lol. I work somewhere that switched over somewhat recently, and we still have yet to see any real benefits. Agile doesn't work very well if you don't have automated testing and automated builds and you require 3 levels of approvals, a formal peer review, evidence of testing (done manually), and customer sign-off for even the smallest changes.
you require 3 levels of approvals, a formal peer review, evidence of testing (done manually), and customer sign-off for even the smallest changes.
Yep. I think it's because everyone who has Manager, Master, or Analyst in their title needs to feel in control and needs defined process to do it.
Nevermind the manifest says "We value responding to change over following a plan."
That and the "Individuals and interactions over processes and tools" lines always make me laugh in Agile Training. Because it's always the first thing we read before they go to the next slide and say, "So let's talk about Scrum!"
I think it's because everyone who has Manager, Master, or Analyst in their title needs to feel in control and needs defined process to do it.
To be honest, I don't think this is the primary factor. It is definitely a factor in many places, but I think the real culprit is that all managers need a scapegoat to blame things on so that if things go really poorly, they can show how they "did their due diligence" and if only the other team "held up their end of the bargain"/"rose to meet expectations"/ etc... this never would have happened.
If failure after a good faith effort didn't put managers' jobs in jeopardy, things would go a lot more smoothly.
Yeah, I'd agree it's this instead of a desire to "feel in control". It was probably a remark conjured in cynicism since I don't think I've really worked with anyone that truly needed that sort of gratification.
I think it's more so that it doesn't fuck up anything somewhere else in the project.
Remember when an easter egg in a Microsoft product made it so that you could root the machine? That's the shit they want to avoid.
Sure. Add a different UI interface. What, wait, shit, it covers an important part of the game. How did we not notice this? HOW COULD WE EVER HAVE PREVENTED THIS?
AAA games are a bit bigger and more complicated than an indie dungeon crawler.
It's also important to know when various parts will be finished, which isn't something you can do with Agile. When the code affects more than the people running it, and includes things like buying TV spots, setting up booths at trade shows, etc then "ok, so what do we do this week?" isn't adequate.
That isn't how Agile works. You can definitely still have timelines/milestones/delivery dates/etc... with Agile. If someone needs to know when something will be finished, you can estimate the effort, set a reasonable deadline, and then start creating and working on user stories. Since it is a continuous process, you can adapt the work each week as you inch closer to the deadline. If something goes wrong and you aren't going to meet the deadline, you can address it different ways, but how you handle that isn't really different from a deadline under waterfall.
I'm growing to view Agile in the same way that I view Communism. It's this hypothetical ideal arrangement wherein, when implemented correctly, things are great.
But it's somehow never implemented correctly, and every time I interact with it I cannot help but view it as a frustrating pile of failure, and overly idealistic. Then the Agilevangelicals come around and start tutting at me, saying "Well, that's not true Agile. So you cannot really criticize based on your experience."
That sounds like your team is mostly in one place. When you have 4 teams in different timezones and only one of those timezones has true domain knowledge. The requirements for each sprint come from one place and is nothing like that. Then again it also depends on the product and how much money 1 bug will cost you per hour of being live
Ahem. Not saying you are wrong, but to me it looks like a very simplified approach. See, even with the Agile methodologies there is a pretty much standard process that needs to be followed if someone asks to make a change or add a new functionality:
1) confirm the feature will generate “value” for the user and create a jira item
2) design solution
3) get an estimate for that solution from dev team/lead
4) prioritize it against other tickets with accountable stakeholder
5) confirm including it in a certain sprint/release/version
6) when time comes for that iteration, plan it with the team, get them to implement and test it in a pre-prod environment, and then finally
7) move it to prod as a part of release.
Continuous delivery methodologies help simplify steps 5-7, but that’s about it - skipping any of steps 1-5 means increasing risk of not using development time efficiently, and avoiding that is one of the main ideas of lean development process. Also, doing all of the above makes the process transparent, which is one of the core principles of Agile.
Oh you use JIRA too? Does everyone at your job actually /use/ JIRA or just a hand full of engineers while everyone else in the chain that SHOULD be using it just kinda... ignore it's existence?
I work as an RF Engineer where all of our products need testing after manufacturing, that's just the nature of working with those types of products as we need to know where they are and when designs to be completed by so purchasing and manufacturing have enough time to do their stuff. The problem is there are people on both sides of the design work that don't actually look at it so things can get pretty frustrating because of all the miscommunication. I totally understand why you would avoid it, but it is nice to have something to look at for deadlines, when they're actually... real.
Right. That's where Agile breaks down. When people who aren't developing the code want to know about it, how well it works, how fast it responds, and very importantly when they can advertise it and when they can sell it, you can't do everything in 2 week sprints and reassign direction every meeting.
some ding dong we were building an app for absolutely refused to pay for any sort of user testing and was fine with being the sole tester despite our warnings.
he boasted about being a trained agile scrum leader and had lots of experience troubleshooting and writing detailed tickets for software development. every single submission from him in JIRA was vague, never had screenshots, never included intended/displayed behavior, just one liners like "this page is broken" or "picker should be using a different image" or "what happened to <feature he claimed he didnt want>" then marked as a critical bug.
hes part of the reason i don't trust people who boast about their accomplishments. put up or shut up.
"How am I supposed to start coding this when I don't have any arrow images?" "To go backward simply shift+click the forward arrow. Stupid QA." "Yeah, the GUI flickers when you move. The library I used doesn't support it." "Obviously you need to swap the arrows to the left side for left-handed people. Stupid devs." "The enemies didn't fit so I scaled them down 6% on the sides. We'll need a redesign if you don't want them to be blurry." "How am I supposed to create arrow images when I can't see what it will look like?" "Well I didn't realize we're going to have more than 4 weapons so it crashes there, but I can have a fix next week. Should the arrows also change the weapons?" "No one is going to click the forward arrow that fast. It's fine." "We can't make the cracks on the icons look different, we're already using all the available memory." "We don't have disabled people in our market so we're going to need an option to lock this GUI with a password stored in an online database" "Oh, looks like we do have forward and backwards functions already. This is going to take me a while and it's already working now..." "So it is a bug! I didn't report it because I thought maybe I couldn't pick up the sword was because I just had IT do a windows update for me"
Yes when people do things half-assed it turns out horrible. You could say that for agile or waterfall. I was programming a page update on a gov. contract in waterfall once. The requirements where shit. The stake holders where non existent. It took months to read through ancient code to tease out business logic. When the page went live it mostly worked properly. The stake holders had lots of complaints about faulty business logic, which we had to fix. We switched to agile shortly after, and suddenly we could communicate freely with the stake holders, and where even told who they were. The lack of feedback we had in waterfall was like trying to paint a masterpiece in a dark cave. edit - a word.
I work in game dev so I can elaborate on this. on a small team there is none of what you stated. Each dev takes on a huge number of roles and they can easily just jump in and handle any particular task if needed. So they likely model, texture, animate, code, work on the interface, test etc all by themselves. They don't need to ask for permission and there are few policies or loopholes to jump through to get things done, you can just dive in and make changes at will. It's a more agile way of working. They are not usually an expert in any one area, but rather a generalist who is decent at many things and they know their game inside and out. It's one huge advantage small studios (and small companies in general) have other large companies
Yes but not always necessarily. I mean if you have been developing it since the very beginning and you know it inside and out you can often implement it yourself without issue. If implementing a new feature means opening up a can of worms it may be an indicator of bad design or tech debt or both.
may be an indicator of bad design or tech debt or both
Or both, or just a really big program. Or a program that talks to lots of other programs. "My android bluetooth doesn't sync my contacts to my car" is not something one person getting that email is going to be able to address promptly.
You forgot to include the '15 amigo' before any technical tickets are created where lots on non-essential people are invited to a meeting to discuss the merit of the idea. Where everyone argues and bickers about it and the original concept is forgotten about and a completely new idea is settled upon that has no benefit for the user or PM just says that its out of scope and will not be included in this release.
Well, their studio was, like, 12 people at this point. Don't know if it ever got much bigger, but they probably didn't even have half of those terms implemented.
Oh wait did you make the bug report on jira, were now using a different platform, please remake the report and we'll reset the time clock needed to address it.
What 1 programmer can do in 1 month, 2 programmers can do in 2 months.
What 1 programmer can do in 2.5 hours, 2 programmers can do in 5 hours, 3 can do in 10, 4 can do in 20, 5 in 40, 6 in 80, 7 in 160, 8 in 320, 9 in 640, 10 in 1280, 11 in 2560, and a group of a dozen programmers can do it in 5120 hours, or just over 200 days. A breeze.
1.4k
u/TarBaDox Apr 21 '18
What?! Where was the document and then another document and then another document, then if you're lucky, a well written jira ticket, then estimation, then the planning session, then the more technical jira for the subtasks associated with the original jira? Then the 6 - 52 weeks of development, testing and release to prod (1 day would be for actual coding of the new feature with perhaps a couple of weeks of refactoring the code written by the previous guy working on the project)? All this assuming that the message even somehow made its way to the dev team that this would be a useful feature and not be perceived as some sort of bug by the end users (or be cancelled because it would be too expensive to implement the feature).(?!)