|
|
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.
|
|
|
|
|
As project lead / tech lead I assigned work, and when it was due (done), it was "unassigned"; and they were given the next task; and I managed any updates to completed work (integration and integration / system testing).
This was possible because a proper design and partitioning of the problem and solution was done beforehand.
"Agile" means "no planning" for most ... (And with "no plan" you can't really fail; so it's all good).
|
|
|
|
|
- If your team schedules 160 points, but can only deliver 40, the first thing you need to fix is to stop scheduling 160 points. 160 sounds suspiciously like 4 people x 40 hours a week. In case you haven't heard, people don't spend 8.000 hours a day coding. The go on vacation. They go to meetings. They get pulled off coding to fix tooling issues. They get pulled off to fix bugs. They yak about the Superbowl. But no matter what your points are, your record of delivery is the best estimate of your future capability.
- If you have a critical delivery in a couple of short months (counting the Christmas holiday no less), it's time to 'fess up to senior management and your customers right now so they can mitigate the negative effects of the code being late. Abandoning your process right before a big deliverable is not a highway to success. Changing your process will make your schedule more uncertain, not less.
- Writing tests may take as much time as developing the code; that's just the way it is. Test-first is a great way to wring out a design, too. Tests are not what the Agilists call "documentation". They are talking about 500 page Software Requirement Specifications and such. You complain that bugs are escaping module test and getting into demos. Abandoning your testing process is unlikely to make that better.
Longer term, there may be some positive changes you can suggest to your team. Trust the team. If they want to do the right thing, they will want to improve on weaknesses in their process.
- Make the team schedule larger refactorings as if they were story points. This will increase the visibility of what they are doing. If all they want to accomplish is refactoring, then maybe there's something wrong upstream, like poor design. Test-first is supposed to help wring out the design. If it's not working in this team, ask the team if it is valuable enough to retain.
- Consider adding code reviews. Don't allow refactorings to be checked in if the team doesn't agree that it improved something. People hate working for a week and having it thrown away. Once this happens a few time, your team will become more focused on the need for any change they propose. Consider design reviews too, to make sure code needs refactoring before refactoring it.
- Engage the team in a conversation about the bugs that escape module test. Honestly, my experience is that good module test finds most new bugs. Maybe some modules are not well tested. Maybe some modules are a big sticky mess that is difficult to test. If so, maybe that is what needs refactoring. If that's not feasible, maybe it's time to invest in some dedicated testers to do system test on a recurring basis. If your bugs are in a tracker of some sort, it's possible to do a causal analysis to see what part of your process injects the most bugs. Maybe introducing static checkers...
Most importantly, management must lose their ego and stop blaming the team. Software takes as long as it takes. If it's taking 4x as long as you want it to take, this is more likely a management problem than a team problem. It means you need 4x (or 5x) the team. It means spending on better testing. It means investing in more tracking, more analysis, and more process. Or it means scaling back your expectations.
|
|
|
|
|
SeattleC++ wrote: 60 sounds suspiciously like 4 people x 40 hours a week
We have about 15 devs (me included).
SeattleC++ wrote: Writing tests may take as much time as developing the code; that's just the way it is.
It's taking about 10x the time it takes to write the code.
SeattleC++ wrote: Make the team schedule larger refactorings as if they were story points. This will increase the visibility of what they are doing. If all they want to accomplish is refactoring, then maybe there's something wrong upstream, like poor design. Test-first is supposed to help wring out the design. If it's not working in this team, ask the team if it is valuable enough to retain.
Yes, I think this is happening a lot..
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.
|
|
|
|
|
It is possible to have too many unit tests. Especially if they are testing lots of internal functions. Mostly you want to just test the external interfaces and if the internal functions are working properly the external ones will too.
And of course as you've found out automated tests are great but can never replace an actual person using the product. You need testers, even if it's the CEO and receptionist.
Agile is not against design, btw. Spend some time locking down those external interfaces and then DON'T CHANGE THEM. Combined with unit tests only on those external things, you can develop really quickly by relying on the mostly static tests to catch regressions.
Stick to it. Even if you find out your external interface design could be better, unless it's really screwed up STICK with it. Fix everything in version 2.
And exercise more control during story creation to keep people on track. If something works already, keep it and work on something that is broken.
|
|
|
|
|
Agile is evil. It no longer values the coders and ends up in a blather fest. Let the non technical types have meetings and then put someone with tech knowledge in charge of assigning the work and coordinating the project. He should also have coding work. Assign someone you don't like to speak with the blatherskites.
Agile breeds black holes.
|
|
|
|
|
It sounds like they aren't breaking problems up appropriately. It also sounds like the team is too large. We have a team size of only 2 developers, but we never take anything over 8 points and we are very cautious about those 8. We also rarely take over about 20 total points per sprint. If they only deliver 40 per sprint don't let them commit to more than that. Something else can always be pulled in later in the sprint if they get done early.
Also, "Needs to be delivered by XX date" is almost always a bad way of thinking. It will cause a lot more defects and a lot more problems, and will usually cause the software to be delivered LATER than it could have been. Software is done when it's done. You may want to go back and say, "Well, we can't have the entire project by that date, but what is the minimum that will still be usable?" They will almost always say, "All of it," and then you get to say, "Well, then it will be YY date, at the very earliest, but we can give you (some subset of user stories) by XX date and deliver the rest later."
|
|
|
|
|
What I've seen is programmers now who are terrified of writing code. They don't feel like they can write a simple for loop without a unit test (written first!) to show it works.
Then you take all the unit-test passing code and plug it together and find it is all still buggy because unit tests don't catch everything and the most subtle bugs occur in integration (especially with anything event driven).
My favorite sayings are "you don't ship tests" and "customers don't buy tests". What ultimately matters to the business is to ship working code. Absolutely write tests for subtle algorithms or pieces of code that have proven buggy. Writing tests for code that has to be refactored (for performance for instance) is great to prove that the behavior is unchanged. But it seems the modern programming culture puts all the emphasis on unit testing as if that is a panacea for delivering working systems.
And don't forget that writing test suites for code that doesn't ship due to being un-needed or because it is delivered too late is completely wasted time.
Maybe these guys haven't been on a project that failed due to being delivered late, and they have to learn the hard way.
|
|
|
|
|
Great comments, I agree 100%..
Carlosian wrote: Maybe these guys haven't been on a project that failed due to being delivered late, and they have to learn the hard way.
Their previous project took 4 years to fail and cost around £25 million. Odd how they haven't learned anything from that! Even odder that they weren't all kicked out.. 
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.
|
|
|
|
|
The bad news: You are probably toast.
The good news: You know this now, not on the ship date.
Agile is not a magic wand, you still need engineering skill.
However, Agile processes are designed to expose problems. It worked.
Given lots of test effort and still shipping bugs it sounds like a competence problem.
How to deal with that is up to you and your organization.
Sorry I can't be more specific as I have not hit that particular problem.
|
|
|
|
|
Maybe you've got a few things the wrong way around.
Are you asking too much of the team in too short a space of time?
If this sprint and the one prior is only delivering 40 points instead of the anticipated 160, then perhaps that is too much. Even if you didn't do unit testing and just went straight to system testing would the 160 be realistic?
Remember to apply S.M.A.R.T. objectives for your team. That might help keep things focused. You're probably doing this anyway, but direct your team to complete the most critical changes in a sprint first, so the least critical changes can roll over. If you're delivering the important stuff then perhaps your management will overlook the shortfalls in delivery. At least for a while.
Take another look at the project plan/road-map. Has enough time been allocated to testing? I'd say a rule of thumb would be 1 hour of dev should have 1 hour of testing. Even better to have 2 hours of testing. You could consider the act of maintaining unit tests goes into part of the testing time. Maybe that is the difference between 160 and 40 points - there is a whole bunch of time for unit test development that isn't accounted for. You may be able to justify an extension to the development based on actual performance and gaps in the project plan.
If the subject of extending the team comes up in that context, definitely go for more testers, or more developers dedicated to supporting the testers and/or unit tests. Testers and junior devs tend to be cheaper so you could get more bang for your buck there.
As you've pointed out in your post, a lot of time can be sunk into testing one way or another. Even if you didn't use unit testing & CI there would still be a test team that is likely to not inherently have the skills necessary to reset systems, write scripts and generate test data. Inadvertently the testers could be a drag on your dev team, so make sure they have access to dev skills. Even if that means assigning a developer specifically to that role. To put it another way, sacrifice one dev to testing so everyone else can get on with their jobs!
If this still doesn't get the delivery you want, then don't be afraid to ditch the unit testing entirely. Your team will hate it. Maybe it will bite you in the arse later; but later is for those that survive the deadline. However, if you do, then make double sure that your system testing is giving you good coverage.
Finally, my old PM used to say that the first thing he did with a failing team was to reduce (not increase) headcount. I think there's been some studies on this, but basically those that are left behind tend to have tighter communication channels with each other, where they don't spend time having large meetings or email discussions. For whatever reasons, it's an opportunity to trim out team members that aren't a good fit for the team in that particular project environment (high-pressure & short lead times). I think it was about 5 devs to be optimal, but be careful to do some more reading on this subject.
That's it. All in my opinion. Take it or leave it as you see fit. And Good Luck!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
