Opinions needed.. (no, really! :))
-
If you are Agile then this should be brought up and addressed in the sprint retrospective meeting.
It is.. every retrospective is the same: "why did we only deliver x points when we committed to [much bigger] y at the start?" My answer's the same every time, but the next day we start the same process again.. :doh:
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.
-
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.
-
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:
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.
-
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 :thumbsup:
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.
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. :thumbsup: [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.
-
Michael Breeden wrote:
You need to weaponize your knowledge.
They're masters at this part of it all.. Had a meeting a few weeks back where I got a spiel about this process, that pattern, "re-hydrating entities".. basically re-loading the data from the database, but why say something in half a dozen understandable words when you can talk in paragraphs on a podium in front of clueless management? :laugh:
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.
Well, you could perhaps go to the lowest possible level and just tell the truth. "We aren't getting anything done here". Really, could you ask what the "value" is or the "deliverable"? That is what Agile is all about. Really, talking at a podium in front of management? That sounds too late in any case.
-
Someone who keeps some kind of tally and owns a whacker? :omg:
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.
Yes, and if that does not works we can also get some chains and overseers with whips :-)
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 fucking 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. -
It is.. every retrospective is the same: "why did we only deliver x points when we committed to [much bigger] y at the start?" My answer's the same every time, but the next day we start the same process again.. :doh:
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.
160 points were promised but only 40 delivered OK - so now your velocity is 40, which means you cannot promise more than 40 in your next sprint. Then - if that gets done, slowly increase the velocity to towards your target. Also - use customer value to choose the most impactful 40 points and deliver them first. Don't make the stuff that delivers real value wait for the HiPPO driven requirements.
-
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.
-
Be very careful about changing anything right before a deadline. * 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 teste
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.
-
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.. :doh:
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.
-
160 points were promised but only 40 delivered OK - so now your velocity is 40, which means you cannot promise more than 40 in your next sprint. Then - if that gets done, slowly increase the velocity to towards your target. Also - use customer value to choose the most impactful 40 points and deliver them first. Don't make the stuff that delivers real value wait for the HiPPO driven requirements.
Duncan Edwards Jones wrote:
OK - so now your velocity is 40, which means you cannot promise more than 40 in your next sprint.
In theory that's correct. In reality it means little more than delivering a checkbox and a text field on a page.. 15 developers, 2 weeks, personally I'd expect more.
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.
-
Yes, and if that does not works we can also get some chains and overseers with whips :-)
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 fucking 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.You might be on to something.. get off it quick! :laugh:
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.
-
You might be on to something.. get off it quick! :laugh:
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.
Dang, my last project management courses were in Egypt. We got some nice pyramids built back then.
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 fucking 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. -
Duncan Edwards Jones wrote:
OK - so now your velocity is 40, which means you cannot promise more than 40 in your next sprint.
In theory that's correct. In reality it means little more than delivering a checkbox and a text field on a page.. 15 developers, 2 weeks, personally I'd expect more.
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.
In my opinion, 15 developers is far too many. I'd suggest you work out how you could do a velocity of 20 with 2 developers, then cut your project into independent chunks of 20-ness.* (*20 arbitrarily chosen to define the point)
-
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 :laugh:
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:
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.
-
In my opinion, 15 developers is far too many. I'd suggest you work out how you could do a velocity of 20 with 2 developers, then cut your project into independent chunks of 20-ness.* (*20 arbitrarily chosen to define the point)
Duncan Edwards Jones wrote:
In my opinion, 15 developers is far too many.
It is.. our morning stand-up takes forever and covers a lot of stuff irrelevant to many in the team. Most places I've worked at I've been in teams of 1-6, and they worked much better.
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.
-
Duncan Edwards Jones wrote:
In my opinion, 15 developers is far too many.
It is.. our morning stand-up takes forever and covers a lot of stuff irrelevant to many in the team. Most places I've worked at I've been in teams of 1-6, and they worked much better.
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.
Also it sounds like you are project-managing at the "Task" level which is way too low level...see this talk: GOTO 2014 • Implementing Programmer Anarchy • Fred George - YouTube[^]
-
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.
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
-
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.