|
Whomever is responsible for the 'team' or 'project' needs to define priorities and timelines.
If they are not being met, a determination needs to be made as to why and what the consequences are of not meeting the timelines: the project is not completed which results in lost revenue which can result is staff reduction for example.
If that person is you, address it with your management and ask what 'corrective' actions can be taken.
|
|
|
|
|
Unfortunately it is not me. It'd be a different team if I were responsible for it.
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.
|
|
|
|
|
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:
- Here's the features we need
- Here's the timeline and dependencies for each feature (remember Ghantt charts?)
- 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
|
|
|
|
|
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
|
|
|
|
|
Jon McKee wrote: 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.
Yep, we've got that (and I've brought it up many, many times).
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: 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).
This could be the reason why things are behind. Agile is about delivering new features on a regular basis, not refactoring code because someone doesn't like it. If code needs refactoring it should be a backlog item that is added to a sprint.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: Agile is about delivering new features on a regular basis, not refactoring code because someone doesn't like it. If code needs refactoring it should be a backlog item that is added to a sprint.
That's a good point.. I'll use that in the next meeting 
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: so I'm working with a team that's (relatively) young
Brent Jenkins wrote: unit tests written up front
I am not a big fan of test driven development, sounds good on paper, but it is shite in reality.
Also, I don't like working with a bunch of relatively young people. Been there, done that, f***ing nightmare and a half.
In summary, run to the hills, run for your life.
|
|
|
|
|
+5 for the Maiden reference.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
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
|
|
|
|
|
If it works: do not fix it.
What's the point of refactoring if no new feature is added in the end?
|
|
|
|
|
Lets all go the park and feed the pigeons - we would be more useful to at least the birds.
|
|
|
|
|
Agreed; bacon.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
modified 9-Dec-16 15:52pm.
|
|
|
|
|
Some good points here. I'm not actually against Agile, it's more down to how different companies interpret/implement it and here it's done as bad as I've seen anywhere. 
[Edit] We're a team of about 15 developers. Looking at the work we've got (from a technical aspect) I think that we commit to about the right amount (it works out to 160 points in a sprint). The problems all come at the time of implementation.
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.
|
|
|
|
|
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
|
|
|
|
|
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.
modified 10-Dec-16 23:36pm.
|
|
|
|
|
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.
|
|
|
|
|
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!
|
|
|
|
|
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!
|
|
|
|
|
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!
|
|
|
|
|
Ken Utting wrote: I'm inferring that you're one of the developers on the project, and not actually responsible for delivery of the product.
Yep, that's me.
Ken Utting wrote: 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.
I've been approached after a number of comments I made in the last retrospective (seems to be finally hitting home, albeit late in the process). Hopefully taking some of the comments here, I can try and have some kind of effect on the project - I hate seeing viable projects fail.
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
