Opinions needed.. (no, really! :))
-
I'd like to buy you a beer.
Regards, Rob Philpott.
and I'd like to drink that beer! :thumbsup:
-
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:
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).
Take 2 - and have everyone read this blog post[^] (no, not from me). :) 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
-
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.
If it works: do not fix it. What's the point of refactoring if no new feature is added in the end?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
- owns a large, heavy ClueBat.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
:thumbsup:
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
There's a process to everything. Many people (developers) have no real process. THey just write code. Just writing code is terrible. The book attempts to explain a process that a real person(s) can use to create a product, not just code. Those of us, like yourself, who have a process that actually creates valuable products have no need of such a thing and consider the writers of such processes as snake oil salesmen (and many are).
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:
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
-
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.
Lets all go the park and feed the pigeons - we would be more useful to at least the birds.
-
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.
Contrary to other opinions here, there is nothing wrong with Agile. Couple of thoughts to help you hopefully get a handle on this: First: the points. Is 40 points your true capacity? If you're doing 2 week sprints and only have 4 developers (as an example), then why are you scheduling 160 points per sprint? If your capacity is significantly higher than 40 points, and you're just not meeting it, then the scrum master needs to come down on folks who are taking a week to finish a 2 point story. Nip that stuff in the bud. A 2 point story should be done by the next scrum, and if it's not the SM needs to buttonhole the dev and ask him or her why, and how they're going to fix it for the next 2 point story. Second: Who is the owner? Who is prioritizing stories? I don't have a problem with technical debt stories, but if those stories are being prioritized ahead of critical defects or features, then you got the wrong people deciding priorities. The SM or PM needs to fix that ASAP. Last: Unit testing is not right or wrong, but if you're going to do it, then A) make sure it's in the story points and B) make sure unit test results are given the same weight as a fistful of air: A unit test is only there to let developers know if they broke someone else's code. Unit tests do not decide if a story was implemented properly. Only Business and/or QA make that call. Edit to add the real, final last item: If someone is doing work that's not part of a user story or defect, then they need to be at the very least kicked off the project. Possibly fired if your company wants to go that far.
-
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
W∴ Balboos wrote:
Just because they say so?
No, not just because Agile says so. I'm saying that code without a purpose isn't valuable to a company or a project. Developers often get stuck on code, but if the code isn't useful or usable the product suffers. Often, it is because developers are focused on other things like some beautiful algorithm. I like software that works and that is really the true goal of a real Agile project. Even this process that the OP has described isn't actually Agile, because they are missing a prime ingredient: product owner / visionary. Alas. :)
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 (free)^ Get C'YaPass in the App Store(free)^
-
The real answer could/should be dogfooding[^]. Make the developers use the thing themselves. It may be that the product / project is so overly boring that no one really uses it anyways so the devs descend into tweaking algorithms which are interesting to devs. Somehow transform them into thinking about actually using the product and how important the final result it. This may work. Edit My point here is that the problem you are describing is that there is no "product owner" / visionary who is really driving things.
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.
:thumbsup: Great comment, and appreciated by one who eats dogfood! :laugh: My company is so small that I provide frontline customer support and training for anything I develop. It's way different when your goal becomes to minimize phone calls/remotes/interruptions! I do think you wind up with better software in the end when devs interact with end users at some level.
"Go forth into the source" - Neal Morse
-
:thumbsup: Great comment, and appreciated by one who eats dogfood! :laugh: My company is so small that I provide frontline customer support and training for anything I develop. It's way different when your goal becomes to minimize phone calls/remotes/interruptions! I do think you wind up with better software in the end when devs interact with end users at some level.
"Go forth into the source" - Neal Morse
Thanks and I totally agree with you on your comment, especially...
kmoorevs wrote:
It's way different when your goal becomes to minimize phone calls/remotes/interruptions!
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.
-
W∴ Balboos wrote:
Just because they say so?
No, not just because Agile says so. I'm saying that code without a purpose isn't valuable to a company or a project. Developers often get stuck on code, but if the code isn't useful or usable the product suffers. Often, it is because developers are focused on other things like some beautiful algorithm. I like software that works and that is really the true goal of a real Agile project. Even this process that the OP has described isn't actually Agile, because they are missing a prime ingredient: product owner / visionary. Alas. :)
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 (free)^ Get C'YaPass in the App Store(free)^
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
-
Thanks and I totally agree with you on your comment, especially...
kmoorevs wrote:
It's way different when your goal becomes to minimize phone calls/remotes/interruptions!
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.
-
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
