The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
How about appointing a team leader, a real taskmaster who
- does the sprint planning and prepares tasks - assigns the tasks - whacks them over the head when they complain about their tasks - whacks them over the head if they take too long - whacks them over the head when they mess with sometthing that's not their business - whacks them over the head if they have too many ideas - whacks them over the head for nothing once in a while, just to keep them on the edge
"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.
#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
Great comment, and appreciated by one who eats dogfood! 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.
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.
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).
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.
"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
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).
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.
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.
"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
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.