|
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.. 
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Simple: toss out agile and do it properly. Oh, and fire all the script-kiddies and get some real coders in. 
|
|
|
|
|
Hire some goons to have a talk with the worst offender every week?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: Hire some goons to have a talk with the worst offender every week?
I think we've got that.. trouble is that the goons promote the guy every time 
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
What rank has he reached by now? Imperial commander of the order of the tweaked byte, fourth class?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Agile - an MBA's idea of how programming should be done.
And a + for you.
| Ravings en masse^ |
|---|
| "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: 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.
|
|
|
|
|
Another "Alas":
Writing a book, declaring a manifesto, and selling a bill of goods will not fix something that's innately broken.
| Ravings en masse^ |
|---|
| "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 |
|
|
|
|
|
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).
|
|
|
|
|
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.
| Ravings en masse^ |
|---|
| "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.
|
|
|
|
|
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. 
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.
Other people's code is boring though. Meh.
|
|
|
|
|
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.
|
|
|
|
|
Reminds me of parents who love to take videos of their children, and when you go over to their place, those parents show (make you sit through) those videos until you are beyond numb.
|
|
|
|
|
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
|
|
|
|
|
raddevus wrote: Many people (developers) have no real process. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups.
Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: I think that's nonsense.
There is a huge body of project failure stats that back it up.
|
|
|
|
|
raddevus wrote: Many people (developers) have no real process.
We got processes.. lots and lots and lots of processes, all documented, all heavily enforced.. that's part of the problem
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: lots of processes, all documented, all heavily enforced.. that's part of the problem
Yeah, it really is the problem. And at the root of that problem is:
Quote: the people who try to tell you what the process should be have never actually worked through the process themselves.
|
|
|
|
|
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!
|
|
|
|
|
Mark_Wallace wrote: That's because it demands that lowest priority be given to documentation!
That's a funny catch-22!
|
|
|
|
|
It's a cop-out, really.
There's no good way of fitting documentation into agile, so they just sweep it under the carpet.
No technical writer worth his salt will document a function until it's been completed and signed off -- which only ever happens at the end of the sprint, so there's no time left for the guy to learn what it is/does and document it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Actually, it's explained as...
... The implementation is the documentation.
It's a "forRealz" statement because they know that 99% of the time people create documentation then code and never update the documentation anyways so the documents never represent the implementation anyways.
But, alas, 6 one way, half a dozen the other. People will argue both ways and that pays the consulting fees. 
|
|
|
|
|
W∴ Balboos wrote: Agile - an MBA's idea of how programming should be done.
Agreed.. some parts are useful, the bits that work are common sense.. the rest can easily be binned.
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.
modified 31-Aug-21 21:01pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
