[ARCHIVED THREAD] - I hate Non-Agile Development (Page 1 of 3)
Posted: 8/11/2014 3:27:26 PM EDT
|
Just venting here...
Spent the last 7 months farmed out to a leading tech company working in a very Agile environment. Just came back to my company from the endeavor to find a room full of morons who couldn't find their way around a scrum or user story if their life depended on it. - They are asking me the developer to create the acceptance criteria for the story I am working on - They are using story points in direct correlation to hours. So a story that has 12 hours of work is getting pointed out at 12. - They aren't taking into account QA/Testing - They are assigning me 120 hours worth of work in a 2 week sprint which I am only assigned to spend 70 hours and don't understand why I have a problem with that. - When said point about 120 hours was brought up they just adjusted the estimates down instead of removing tickets. - The PM is asking me to write tickets for him - The Dev lead is asking me to make decisions about what should be in the sprint and what order to complete tickets. - We are in the thrid sprint and don't even have a backlog of future tickets yet with a development plan (Dev Leads Job) - I just tried to explain that it's better to have too few stories in a sprint and you can add more later, then too many that you can't complete. SMH 
Plus, not too sound like a xenophobe, but I can't understand the english of the PM or Dev Lead. I'm looking for a new job... 
|
|
I've done both, currently drinking the Agile Kool-Aid.
Even the most seasoned Agile proponents I work with will state that it's more people than process. If you have 5 good engineers doing waterfall they can run circles around 10 average Agile developers. You need good people no matter what ideology you base your work on, IMO. |
|
Quoted:
I've done both, currently drinking the Agile Kool-Aid. Even the most seasoned Agile proponents I work with will state that it's more people than process. If you have 5 good engineers doing waterfall they can run circles around 10 average Agile developers. You need good people no matter what ideology you base your work on, IMO. Yeah, well people are definitely the problem here. They are pretending to do things in sprints, scrums, and so on but have no clue how that should actually work. It's the most ate up process I have been involved in in years. It doesn't help that the turnover at the company while I was farmed out was damn near 95%. So I think the company is failing and I am going to be smart enough to follow the others who have left out. |
|
the IT department where I work is filled with bufoons.
They claim they're doing "agile". I'm a product owner. This is a project to build a database with a lot of calculated / transformed columns. I've never actually sat and talked with the guys writing code while they're working. I sit with a business analyst and "data architect " and tell them what I want, they write up "Requirements" and send them to a developer, the developer writes some code (but apparently doesn't run it) and sends it to the "QA" person who then checks to see that the code does what the requirements document said it should do. Once in a while they ask me if I can do "qa" for a work item because the "qa resources got pulled onto other projects" (really? agile!). I always say "sure" but it usually goes like this: developer: hey project manager, the xxxxx column is ready to test pm: hey product owner acting as qa, the xxxxx column is ready to test me: select distinct xxxxx from shittydatabase.table sql editor: null me: hey pm, there's no data in the column pm: hey developer, there's no data in the column developer: hey architect, I did what you said, and there's no data in the column me: 
for the love of god, just give me two energetic intelligent programs and lock us in a room for two weeks. we'll come out and this fucking thing will be done. instead it's months and months and months of this shit. on and on. they don't understand the business they're working in, they don't take initiative and do anything unless you tell them exactly what to do. it's been months and except for the few things I've volunteered to act as "qa" on I've not actually seen any finished portions of the database. I'm sure it will look great once it all comes together. but hey, we get together once per day with the PM, business analyst, and architect to look at the "backlog", and once per 2 weeks for "sprint planning" so it must be agile
|
|
"Process", "Requirements"? Is that like a bigfeets?
More like, "Hey, we just installed $2m worth of 3rd party vendor equipment and software that you've never heard of until now. You'll be supporting this (in addition to all the other crap you're working on) without documentation or source code. And it all needs to be online and integrated with our existing systems by next week." |
|
We're in the middle of a transition to a scrum/sprint system. . .sucks. And by "middle" I mean "we've been 'fine-tuning' this process for 18 months now." And by "fine-tuning" I mean: see also - definition of insanity.
9am meetings every day in which everybody plays with their phone while somebody is talking. Sprints are defined. . .then redefined. . .then changed. . .then added to. . .and now suddenly we HAVE to release this thing, why isn't it done??? Project designers have meetings among themselves and then *assume* the developers will somehow find out what was discussed/decided in those meetings. Communication all one way. Give me 3 guys, scratch out what you want on the back of an envelope, and leave us alone. . .we'll get what you want (which may not be what you actually asked for). Posted Via AR15.Com Mobile |
|
Quoted:
We're in the middle of a transition to a scrum/sprint system. . .sucks. And by "middle" I mean "we've been 'fine-tuning' this process for 18 months now." And by "fine-tuning" I mean: see also - definition of insanity. 9am meetings every day in which everybody plays with their phone while somebody is talking. Sprints are defined. . .then redefined. . .then changed. . .then added to. . .and now suddenly we HAVE to release this thing, why isn't it done??? Project designers have meetings among themselves and then *assume* the developers will somehow find out what was discussed/decided in those meetings. Communication all one way. Give me 3 guys, scratch out what you want on the back of an envelope, and leave us alone. . .we'll get what you want NEED (which may not be what you actually asked for). Posted Via AR15.Com Mobile Small correction there. Nirts programming. Need it right this second. |
|
I typed up a lengthy post the other day but decided not to post it.
I've been serving as scrum master / agile coach to a team for the past 6 months. We were tasked with fixing a failed outsourced project that if we don't deliver by 11/15 my company won't be in business much longer. Any way we got everything I asked for including a team room, fully dedicated resources, I was allowed to not use the standard testing tool and instead use MTM which integrates with TFS so we now have full traceability between user stories and code (first time ever in my company.  . )
We are running 2 week sprints and actually deployed a critical functionality into production after only 3 sprints. (This was more than the outsourced team was able to do in 11 months last year. I bought Nerf guns for the entire team, we have a WII set up in our room, the rest of the company is jealous because people think we play all day but every two weeks at our demos they are blown away by the amount of work we get done. My team has the highest morale of any team at my company. Now I'm struggling because I can't get the support to scale what we've created. Leadership is scared at the change we will need to make to expand this (changes in roles, giving up control, executives not making every decision, etc). My company is so silo'd that we have specialists in every IT group. There's so much "that isn't my job, we need to request "x" from team "y". My team has learned to become cross functional which has threatened many others in the company. Right now I'm trying to convince leadership that they need to keep this team together and bring projects to this team and not break them up to assemble fractionally allocated teams for each project that comes along. If I have to go back to waterfall with partially allocated resources I'll probably find another job where I can remain agile. |
|
Going fake Agile is easy. Buy a Scrum tool and use it like every other task manager you've ever used. Talk about sprints and velocity and Fibonacci numbers. Hold 90-minute "stand-ups". Go weeks without any new running code. Plan on making your first unit and integration tests if there's time in a few months after this big push. And if you can find someone who knows how. No customer representative, no problem when you have 200 pages of use cases from last year. Be sure to future-proof everything you design because in Java it's basically free to make a code generator that could also be an analysis engine with a few tweaks. Oh, not a single "story" is done yet? Push it to the next sprint. Again. Look how flexible we are.
|
    |
|
Quoted: Oh arfcom... you get me. Glad to see others are as frustrated at things as I am  There's so much religious fervor. I was consulting with one team where the lead insisted on pair programming for every time you did anything, and had a chart to make sure that every combination of people paired off roughly evenly. Several where it was forbidden to talk about something taking hours or days. No, everything is T-shirt sizes even if nobody on the team knows what they mean. Or where we had a series of missed tasks that were screaming for someone to put together a simple list or chart showing tasks and people and dependencies but the project managers refused because it didn't fit their shiny new agile process. So I went off and made my own Gantt chart and got the conversation going and we discovered several missing pieces in 24 hours that had gone unnoticed for weeks. Or where test-first development is not just a mindset or a useful exercise for people who don't know testing. No, it's a rule. Never mind all that auto-complete that would have made it a breeze to write 100 unit tests after at least roughing in the real code, or that in writing the real code you might discover a simplification that eliminates the need for half of those tests in the first place such as removing a parameter or enum value.
|
|
Quoted:
There's so much religious fervor. I was consulting with one team where the lead insisted on pair programming for every time you did anything, and had a chart to make sure that every combination of people paired off roughly evenly. Several where it was forbidden to talk about something taking hours or days. No, everything is T-shirt sizes even if nobody on the team knows what they mean. Or where we had a series of missed tasks that were screaming for someone to put together a simple list or chart showing tasks and people and dependencies but the project managers refused because it didn't fit their shiny new agile process. So I went off and made my own Gantt chart and got the conversation going and we discovered several missing pieces in 24 hours that had gone unnoticed for weeks. Or where test-first development is not just a mindset or a useful exercise for people who don't know testing. No, it's a rule. Never mind all that auto-complete that would have made it a breeze to write 100 unit tests after at least roughing in the real code, or that in writing the real code you might discover a simplification that eliminates the need for half of those tests in the first place such as removing a parameter or enum value. Quoted:
Quoted:
Oh arfcom... you get me. Glad to see others are as frustrated at things as I am There's so much religious fervor. I was consulting with one team where the lead insisted on pair programming for every time you did anything, and had a chart to make sure that every combination of people paired off roughly evenly. Several where it was forbidden to talk about something taking hours or days. No, everything is T-shirt sizes even if nobody on the team knows what they mean. Or where we had a series of missed tasks that were screaming for someone to put together a simple list or chart showing tasks and people and dependencies but the project managers refused because it didn't fit their shiny new agile process. So I went off and made my own Gantt chart and got the conversation going and we discovered several missing pieces in 24 hours that had gone unnoticed for weeks. Or where test-first development is not just a mindset or a useful exercise for people who don't know testing. No, it's a rule. Never mind all that auto-complete that would have made it a breeze to write 100 unit tests after at least roughing in the real code, or that in writing the real code you might discover a simplification that eliminates the need for half of those tests in the first place such as removing a parameter or enum value. Sounds like they value processes over individual interactions. 
|
|
Quoted:
the IT department where I work is filled with bufoons. They claim they're doing "agile". I'm a product owner. This is a project to build a database with a lot of calculated / transformed columns. I've never actually sat and talked with the guys writing code while they're working. I sit with a business analyst and "data architect " and tell them what I want, they write up "Requirements" and send them to a developer, the developer writes some code (but apparently doesn't run it) and sends it to the "QA" person who then checks to see that the code does what the requirements document said it should do. Once in a while they ask me if I can do "qa" for a work item because the "qa resources got pulled onto other projects" (really? agile!). I always say "sure" but it usually goes like this: developer: hey project manager, the xxxxx column is ready to test pm: hey product owner acting as qa, the xxxxx column is ready to test me: select distinct xxxxx from shittydatabase.table sql editor: null me: hey pm, there's no data in the column pm: hey developer, there's no data in the column developer: hey architect, I did what you said, and there's no data in the column me: http://i.imgur.com/69YTHCZ.gif for the love of god, just give me two energetic intelligent programs and lock us in a room for two weeks. we'll come out and this fucking thing will be done. instead it's months and months and months of this shit. on and on. they don't understand the business they're working in, they don't take initiative and do anything unless you tell them exactly what to do. it's been months and except for the few things I've volunteered to act as "qa" on I've not actually seen any finished portions of the database. I'm sure it will look great once it all comes together. but hey, we get together once per day with the PM, business analyst, and architect to look at the "backlog", and once per 2 weeks for "sprint planning" so it must be agile http://i.imgur.com/69YTHCZ.gifhttp://i.imgur.com/69YTHCZ.gifhttp://i.imgur.com/69YTHCZ.gifhttp://i.imgur.com/69YTHCZ.gifhttp://i.imgur.com/69YTHCZ.gifhttp://i.imgur.com/69YTHCZ.gif 
|
|
Quoted: Sounds like they value processes over individual interactions. Quoted: Quoted: Quoted: Oh arfcom... you get me. Glad to see others are as frustrated at things as I am There's so much religious fervor. I was consulting with one team where the lead insisted on pair programming for every time you did anything, and had a chart to make sure that every combination of people paired off roughly evenly. Several where it was forbidden to talk about something taking hours or days. No, everything is T-shirt sizes even if nobody on the team knows what they mean. Or where we had a series of missed tasks that were screaming for someone to put together a simple list or chart showing tasks and people and dependencies but the project managers refused because it didn't fit their shiny new agile process. So I went off and made my own Gantt chart and got the conversation going and we discovered several missing pieces in 24 hours that had gone unnoticed for weeks. Or where test-first development is not just a mindset or a useful exercise for people who don't know testing. No, it's a rule. Never mind all that auto-complete that would have made it a breeze to write 100 unit tests after at least roughing in the real code, or that in writing the real code you might discover a simplification that eliminates the need for half of those tests in the first place such as removing a parameter or enum value. Sounds like they value processes over individual interactions. Hey, keep your manifesto to yourself.
|
|
My team is a scrum team right now and are pushing to go to Kanban. They can't see any value in the meetings that come with scrum and just don't want to be in them. Kanban just seems like assembly line development to me when nobody really talks about anything and you just push through as much work as possible.
As a product owner and dev lead I am continually frustrated because I can't map out release or sprints with any predictability. My company put me in a position where I'm not allowed to say no to any client requests and must work on their timeline. So at any moments notice my entire release, sprint, or even day could completely change. It makes managing things pretty much impossible. |
|
Quoted:
I hate any place that uses those Dilbertesque buzzwords This. Figure out a development model that suits the project at hand and use it. Don't worry about conforming to somebody else's existing idea of how it should or shouldn't be done. Look at what has been done for ideas and general guidelines, not as rules and strict frameworks. No one development model is the end-all-be-all for every single project. And sticking to a single "standard" model may very well be worse than rolling with a more hybrid approach. |
|
Quoted:
Just venting here... Spent the last 7 months farmed out to a leading tech company working in a very Agile environment. Just came back to my company from the endeavor to find a room full of morons who couldn't find their way around a scrum or user story if their life depended on it. - They are asking me the developer to create the acceptance criteria for the story I am working on - They are using story points in direct correlation to hours. So a story that has 12 hours of work is getting pointed out at 12. - They aren't taking into account QA/Testing - They are assigning me 120 hours worth of work in a 2 week sprint which I am only assigned to spend 70 hours and don't understand why I have a problem with that. - When said point about 120 hours was brought up they just adjusted the estimates down instead of removing tickets. - The PM is asking me to write tickets for him - The Dev lead is asking me to make decisions about what should be in the sprint and what order to complete tickets. - We are in the thrid sprint and don't even have a backlog of future tickets yet with a development plan (Dev Leads Job) - I just tried to explain that it's better to have too few stories in a sprint and you can add more later, then too many that you can't complete. SMH
Plus, not too sound like a xenophobe, but I can't understand the english of the PM or Dev Lead. I'm looking for a new job... 
|
" />
|
Quoted: Hours as story points? Fuck that noise right in the face. True Agile is awesome. One team I was on, it wasn't just any story points but it had to be Fibonacci sequence because revenge of the nerds or something. And we'd get into these ridiculous drawn out discussions like some task that was estimated at 13 points was marked done, then we found out that it had no unit tests so, uh, not really done. But we couldn't reopen the task and instead needed to make a new task for the next sprint with the remaining story points, but was the testing 5 points or 8 because obviously it can't be 6... This consumed the entire team for over 20 minutes, trying to fit this one minor task into the properly shaped hole. With none of that effort going to the much bigger question of how it was possible for someone working in the 21st century to check in code and mark it done and walk away without a single unit test, yet we were dying to know this same guy's estimate for work he doesn't know how to do on a made-up scale. It's almost like we reached such a breakneck pace of software development by the late 90s that we decided we'd better slow way down or we'd run out of work.
|
|
Quoted:
I've done both, currently drinking the Agile Kool-Aid. Even the most seasoned Agile proponents I work with will state that it's more people than process. If you have 5 good engineers doing waterfall they can run circles around 10 average Agile developers. You need good people no matter what ideology you base your work on, IMO. This is true. I have seen a lot of processes come and go, and a lot of coders come and go. Excellent coders do an excellent job no matter what. Excellent coders to a shitty job when management gets in the way. I get severely pissed off when a manager blames the coders for his shit impossible schedule, esp when software clearly stated the hrs involved. And this was a manager that moved up FROM software. He should have known better. Management is just stupid. Excellent coders get to code about an hr a day when the "process" gets in the way, and the support tools suk. We only rank about 6 of 12 on the Joel Spolsky test, so that will you a lot if you are familiar with that. ETA: that first statement is not true, based on the other 2 statements is it? haha. |
|
Quoted:
One team I was on, it wasn't just any story points but it had to be Fibonacci sequence because revenge of the nerds or something. And we'd get into these ridiculous drawn out discussions like some task that was estimated at 13 points was marked done, then we found out that it had no unit tests so, uh, not really done. But we couldn't reopen the task and instead needed to make a new task for the next sprint with the remaining story points, but was the testing 5 points or 8 because obviously it can't be 6... This consumed the entire team for over 20 minutes, trying to fit this one minor task into the properly shaped hole. With none of that effort going to the much bigger question of how it was possible for someone working in the 21st century to check in code and mark it done and walk away without a single unit test, yet we were dying to know this same guy's estimate for work he doesn't know how to do on a made-up scale. It's almost like we reached such a breakneck pace of software development by the late 90s that we decided we'd better slow way down or we'd run out of work. Quoted:
Quoted:
Hours as story points? Fuck that noise right in the face. True Agile is awesome. One team I was on, it wasn't just any story points but it had to be Fibonacci sequence because revenge of the nerds or something. And we'd get into these ridiculous drawn out discussions like some task that was estimated at 13 points was marked done, then we found out that it had no unit tests so, uh, not really done. But we couldn't reopen the task and instead needed to make a new task for the next sprint with the remaining story points, but was the testing 5 points or 8 because obviously it can't be 6... This consumed the entire team for over 20 minutes, trying to fit this one minor task into the properly shaped hole. With none of that effort going to the much bigger question of how it was possible for someone working in the 21st century to check in code and mark it done and walk away without a single unit test, yet we were dying to know this same guy's estimate for work he doesn't know how to do on a made-up scale. It's almost like we reached such a breakneck pace of software development by the late 90s that we decided we'd better slow way down or we'd run out of work. We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. |
|
Quoted: We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. Quoted: <cut> We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. I think it's fine for the teams it was designed for, where people knew the job but were getting too caught up in trivia: is it going to be 12 hours or 14? Just call it Medium or 8 story points or something and move on. It was a way of getting people to loosen up and focus on more important things like asking what works and what doesn't, which practices are busy work and which ones eliminate whole categories of problems.
|
|
Quoted:
We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. Quoted:
Quoted:
Quoted:
Hours as story points? Fuck that noise right in the face. True Agile is awesome. One team I was on, it wasn't just any story points but it had to be Fibonacci sequence because revenge of the nerds or something. And we'd get into these ridiculous drawn out discussions like some task that was estimated at 13 points was marked done, then we found out that it had no unit tests so, uh, not really done. But we couldn't reopen the task and instead needed to make a new task for the next sprint with the remaining story points, but was the testing 5 points or 8 because obviously it can't be 6... This consumed the entire team for over 20 minutes, trying to fit this one minor task into the properly shaped hole. With none of that effort going to the much bigger question of how it was possible for someone working in the 21st century to check in code and mark it done and walk away without a single unit test, yet we were dying to know this same guy's estimate for work he doesn't know how to do on a made-up scale. It's almost like we reached such a breakneck pace of software development by the late 90s that we decided we'd better slow way down or we'd run out of work. We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. We do t-shirt sizes. Small, Medium, Large, Extra large. Using Team Foundation Server as the tool. |
|
See you didn't make it by to fix my BB yet. How bout tomorrow? I'll bring you some gummy worms and Milano cookies?
J/k Agile isn't something you can do overnight. All teams need to buy-in and agree to dramatic changes in the way everyone works or the system will never work. And no amount of buzzword regurgitation will make agile successful. I believe the larger the company, the less chance of successfully implementing agile will be. With multiple helpdesks, multiple systems, multiple businesses, shared services, 10 different support teams, agile is dead on arrival at places like that. Agile needs cross-functional teams and well rounded employees, not ticket submitting desk jockeys. |
|
Quoted:
We do t-shirt sizes. Small, Medium, Large, Extra large. Using Team Foundation Server as the tool. Quoted:
Quoted:
Quoted:
Quoted:
Hours as story points? Fuck that noise right in the face. True Agile is awesome. One team I was on, it wasn't just any story points but it had to be Fibonacci sequence because revenge of the nerds or something. And we'd get into these ridiculous drawn out discussions like some task that was estimated at 13 points was marked done, then we found out that it had no unit tests so, uh, not really done. But we couldn't reopen the task and instead needed to make a new task for the next sprint with the remaining story points, but was the testing 5 points or 8 because obviously it can't be 6... This consumed the entire team for over 20 minutes, trying to fit this one minor task into the properly shaped hole. With none of that effort going to the much bigger question of how it was possible for someone working in the 21st century to check in code and mark it done and walk away without a single unit test, yet we were dying to know this same guy's estimate for work he doesn't know how to do on a made-up scale. It's almost like we reached such a breakneck pace of software development by the late 90s that we decided we'd better slow way down or we'd run out of work. We do that Fibonacci sequence stuff, but don't get consumed by it. I can see how that would be annoying as all hell though. We do t-shirt sizes. Small, Medium, Large, Extra large. Using Team Foundation Server as the tool. I miss TFS.
|
|
Agile is the latest favor of the month. You wait, in a couple of more years there will be a new better magical process that can take sub par developers and make them turn out quality product on time and under budget.
Seriously, I can no longer count the fads I've seen in the technology industry. At the end of the day, you've either got competent motivated people or you don't. |