Opinions needed.. (no, really! :))
-
Lets all go the park and feed the pigeons - we would be more useful to at least the birds.
-
As others have said, throw out Agile (and unit testing, huge waste of time mostly.) The problem with sprints is that they are essentially developer driven. Go back to good 'ol management 101: 1. Here's the features we need 2. Here's the timeline and dependencies for each feature (remember Ghantt charts?) 3. Missing the deadline will result in reprimand, pay reduction, or being terminated. It's time for the kiddies in diapers learning to ride bicycles with training wheels to grow up. ;) Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
In my opinion unit testing is a benefit to a project once it gets into maintenance and new features start getting added. I think the main problem is you see people unit testing brain-dead functions with every conceivable input so the unit test takes 10x longer to write than the function itself. Unit test at the first level things can actually go wrong. Seems like the main problem here is the team is breaking all the big no-no's. Premature refactoring (when the code is already "clean"), premature optimization, and using a development paradigm the team isn't familiar with (TDD).
-
In my opinion unit testing is a benefit to a project once it gets into maintenance and new features start getting added. I think the main problem is you see people unit testing brain-dead functions with every conceivable input so the unit test takes 10x longer to write than the function itself. Unit test at the first level things can actually go wrong. Seems like the main problem here is the team is breaking all the big no-no's. Premature refactoring (when the code is already "clean"), premature optimization, and using a development paradigm the team isn't familiar with (TDD).
Jon McKee wrote:
In my opinion unit testing is a benefit to a project once it gets into maintenance and new features start getting added.
Absolutely! In fact, 110% agreement with everything you said. Marc
V.A.P.O.R.ware - Visual Assisted Programming / Organizational Representation Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
raddevus wrote:
Often, it is because developers are focused on other things like some beautiful algorithm.
Nothing gets a programmer's motor running quite like a really sexy algorithm. They can be quite distracting. :-D
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
Foothill wrote:
Nothing gets a programmer's motor running quite like a really sexy algorithm.
It's true. I too have fallen in love with my own code. :laugh: Other people's code is boring though. Meh. :-D
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
-
It's surprising how streamlined an application UI can become when the programmer has to use the application often.
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
Foothill wrote:
It's surprising how streamlined an application UI can become when the programmer has to use the application often.
That is a fantastic point and so very true. Great stuff!
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
I agree with Marc Clifton that management seems poor here and to that one could add leadership. One thing that always interested me on the occasions I was involved in interviewing was how many completed projects the applicant had worked on. Many (large) teams are comprised of lots of people who have rarely if ever seen a project to completion. This is one of the real components of what is called experience. Without it individuals and teams have a fear of delivery. I have seen this a number of times and it manifests itself in many of the behaviours you have described. Why is refactoring needed on working code? It just prevents the project from advancing. Good design should isolate any issues arising from sub optimal code. I agree with others who have said that working on perfect tests for a product that never gets delivered is not the way. Agile aside somebody has to remind the team of what the goal is.
Peter Wasser "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Some points, from my experience: 1. Looks like the product owner is not prioritising the user stories. Not all features can have 'highest priority'. Also, looks like writing the unit tests is taking more priority than writing working code; this should reverse. The product owner needs to get more assertive towards setting priorities. 2. Sprint retrospective meetings are not held, or are ineffective in getting actionable points to the team members. Need to enforce the action items from these retrospectives. Task of Scrum Master. 3. Achieving 160 story points per sprint seems to be an over-realistic goal. Need to go after something more realistic, 40 - 50 story points per sprint in the short term, and slowly increasing to about 70 or 80 in the longer term. 4. Everybody in the team cannot be a leader. The junior members should be 'forced' to listen to orders from the senior members, and the Scrum Master should have the final say. 5. Also depends to a certain extent on the agile tool, rather the features provided by the tool used for agile implementation. If the activities of every team member are seen by every other team member on a daily basis, then this would dissuade the individual team members from prolonging the delivery of their user stories. The team members would not like to be seen as bottlenecks.
-
raddevus wrote:
THey just write code. Just writing code is terrible.
Just because they say so?
raddevus wrote:
The book attempts to explain a process that a real person(s) can use to create a product, not just code.
Well - real programmers, by this definition, are simply not real people. I can go with that because real programmers are better than real people! Apparently, by Agile standards, us real programmer earn our living by continuously doing the impossible. Mmmmmmm. Maybe.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
The difficult we do immediately, the impossible takes a little longer. Miracles by appointment only. :)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Simple: toss out agile and do it properly. Oh, and fire all the script-kiddies and get some real coders in. :-)
R. Giskard Reventlov wrote:
Simple: toss out agile and do it properly.
I was too chicken to post anything like that in public. (pssst, I think I was the tenth upvote on the comment)
R. Giskard Reventlov wrote:
Oh, and fire all the script-kiddies and get some real coders in.
Disagree; totally. Age is irrelevant. Yes, experience does count, but it's a matrix thing, not a linear one. I'm Not sure of this at all, so ask a real lawyer or Human Resources pro, but I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members. With that caveat, and reading your description, I highly suspect that your teams contain *some* members with very low verbal skills, and *some* members with very high verbal skills. My sole opinion: That is the root cause of what you are describing. Second factor: The Agile Approach. At times, I am convinced that the whole thing was intended to be a hoax, much like Administratium. (Go look it up if you've never seen the word before.) Third factor: Money. You have used financial forces to induce, entice, and goad people into professing personal belief, adherence, and agreement with The Agile propaganda (^H^H^H^H^H^H^H^H^H^H development methodology). Put those three factors together: [1] Disparate verbal skills, [2] The Agile Approach, [3] Financial forces; and I believe that what you are describing will happen in pretty much any project that requires software, firmware, electronics, website interaction, databases, whatever. The self-contradicting paradoxes within The Agile Manifesto are so rampant and so wantonly linguistically absurd that I truly wonder how much alcohol is present in the bloodstreams of those people who make the decision to use it. Turbo-charge these paradoxes with financial forces, then apply them to teams with no formal assessment of personal verbal skills among them, and, well, that's what you get ! My sole opinion. Anybody else who believes this has to pay me a dollar.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
My first impression is that the expectations of the team are too high. My second impression is that it's not clear to anyone what the acceptance criteria is. My third impression is that you're refactoring too soon.
-
W∴ Balboos wrote:
Agile - an MBA's idea of how programming should be done.
It's too bad it has descended into that. I often talk about he _heart_ of Agile as it is defined by one of the two original "creators" of the Agile methodology in the following book: Scrum: The Art of Doing Twice the Work in Half the Time[^] It's really a great read and if you were to read it I believe you'd find, as I did, that Agile is a set of processes pulled together into a methodology that explains how real work is done. But, alas, it is described in so many places so poorly.
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
raddevus wrote:
alas, it is described in so many places so poorly.
Of course it is! That's because it demands that lowest priority be given to documentation!
I wanna be a eunuchs developer! Pass me a bread knife!
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Brent Jenkins wrote:
In the last two week sprint, 160 points were promised but only 40 delivered.
Then rearrange the pecking order of the people who say how many points should be in each sprint. If the team can only deliver 40 points, then the sprint should cover only 40 points. If that makes people look lazy or slow, all well and good, because they'll get their @rses kicked, but as long as they're being allowed to make ridiculously high estimates (read: promises) for each sprint, no-one will take any @rse-kicking action. I'll bet if you looked through the sprint history, you'd find that the number has been creeping up for a long, long time (and possibly started as low as 60).
I wanna be a eunuchs developer! Pass me a bread knife!
-
raddevus wrote:
alas, it is described in so many places so poorly.
Of course it is! That's because it demands that lowest priority be given to documentation!
I wanna be a eunuchs developer! Pass me a bread knife!
-
R. Giskard Reventlov wrote:
Simple: toss out agile and do it properly.
I was too chicken to post anything like that in public. (pssst, I think I was the tenth upvote on the comment)
R. Giskard Reventlov wrote:
Oh, and fire all the script-kiddies and get some real coders in.
Disagree; totally. Age is irrelevant. Yes, experience does count, but it's a matrix thing, not a linear one. I'm Not sure of this at all, so ask a real lawyer or Human Resources pro, but I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members. With that caveat, and reading your description, I highly suspect that your teams contain *some* members with very low verbal skills, and *some* members with very high verbal skills. My sole opinion: That is the root cause of what you are describing. Second factor: The Agile Approach. At times, I am convinced that the whole thing was intended to be a hoax, much like Administratium. (Go look it up if you've never seen the word before.) Third factor: Money. You have used financial forces to induce, entice, and goad people into professing personal belief, adherence, and agreement with The Agile propaganda (^H^H^H^H^H^H^H^H^H^H development methodology). Put those three factors together: [1] Disparate verbal skills, [2] The Agile Approach, [3] Financial forces; and I believe that what you are describing will happen in pretty much any project that requires software, firmware, electronics, website interaction, databases, whatever. The self-contradicting paradoxes within The Agile Manifesto are so rampant and so wantonly linguistically absurd that I truly wonder how much alcohol is present in the bloodstreams of those people who make the decision to use it. Turbo-charge these paradoxes with financial forces, then apply them to teams with no formal assessment of personal verbal skills among them, and, well, that's what you get ! My sole opinion. Anybody else who believes this has to pay me a dollar.
Interesting response!
C-P-User-3 wrote:
With that caveat, and reading your description, I highly suspect that your teams contain some members with very low verbal skills, and some members with very high verbal skills.
I have no idea what this means in reference to my post. I am guessing you are taking the phrase script-kiddies and misinterpreting it. By script-kiddies I mean developers straight out of uni with little to no experience of the real world. All of the people in the team are articulate and smart (young or old).
C-P-User-3 wrote:
I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members.
I have no idea if that's true or not. Regardless, you (or anyone) is not going to hire someone for a job that is incapable of communicating their ideas or displaying knowledge of development. That is the point of an interview. Anyway, think you may have the wrong end of the stick here.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Declaring any manifesto, method, guideline or anything else as the right way off the bat is the wrong way. One need to first collect experience and then picking development metholodiges. Additionally, sprints aren't in the agile manifesto and Scrum, I assume that's what you're talking about, actually goes against the agile manifesto anyway! All in all, I think the team is misguided. It needs to read the agile manifesto again, especially the first line: People and interactions over processes!
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Get rid of Agile and TDD and start using standard software engineering practices. Your team appears to be completely focused on the process and not the development of an application. This is what happens when you use a lot of the newer concepts in development instead of sound development practices that have been proven over many years of studies and research...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Agreed, but I also like the "latest and greatest" thing.. it's more about using it as intended and where it makes sense.. for example, I quite like Angular 2 - myself and another long term developer (from my team) created a working demo app for these guys. The Angular TS code was hand-crafted (very lightweight) with a simple ASP.NET web API back-end, and successfully integrated with a 3rd party system.. But these guys got their hands on it, deleted and refactored code, insisted on using Angular CLI which has led to them breaking pretty much everything, and they now need PowerShell scripts to be able to deploy anything to Azure (yes, really!).. it's a mess and doesn't work, but it's now sort of testable.. :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
One of my pet peeves is with people who take apart something I have laboured over and perfected, only to completely mess it up. It happens so often that I just sit back and watch the fun these days.
We're philosophical about power outages here. A.C. come, A.C. go.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
I'm inferring that you're one of the developers on the project, and not actually responsible for delivery of the product. So, my suggestion is to talk to the people who do have that responsibility, state your concerns clearly, briefly, and without confrontation or rancor. Suggest a couple of things that would be the easiest to do and have some positive effect (reduce or eliminate testing of trivial code, increase focus of the sprints on features). Even if the people with responsibility for delivery are the biggest proponents of the team's current methodology, they should feel some concern as they see the project slipping away from them. And so they may eventually inform the team that they came up with a great idea, which is to reduce testing and shift focus to implementing features (snark). So, seek out allies, state your concerns, and try to build your credibility. Culture is hard to change, though, and so ultimately it may come down to finding a new one. Good luck!
-
Foothill wrote:
Nothing gets a programmer's motor running quite like a really sexy algorithm.
It's true. I too have fallen in love with my own code. :laugh: Other people's code is boring though. Meh. :-D
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
Narcissistic Programmer Disorder - a mental disorder in which a programmer has an inflated sense of their own code's importance, a deep need for admiration of their code and a lack of empathy for other programmer's code. But behind this mask of ultra-confidence lies a fragile self-esteem that's vulnerable to the slightest criticism. :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > 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. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Agile or any other process enhancement really should be bounced up against a proven methodology such a Lean 6 Sigma. It could be called a process as well but I would rather refer to it as a methodology as in its concepts it seeks to examine the processes of accomplishing things. Among how it seeks to reach these goals it sets objectives of doing so in the shortest time frame, with the least effort, and with least amount of handling. So, if I would find that Agile or any other snazzy process came along and was being inflicted on a team harming its productivity, I'd be quick to slam it up against these principles and more than willing to be ready to jettison any component that was in violation. There are always new and better ideas to be learned and utilized, but common sense and its application once applied never get outdated. They continue to work and work well beyond the latest fad.