Opinions needed.. (no, really! :))
-
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. :rolleyes:
-
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.
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.
-
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.
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.
-
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 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.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 :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.
-
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).
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
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.
-
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 :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.
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 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. -
Brent Jenkins wrote:
One other issue, I'm an old-time coder (44 years old, started coding when I was 8), not a great people person.. (many of you may be surprised to hear that one! :laugh: ) - these guys wear ties, have all the business spiel, great talkers and presenters.. makes it difficult to convince the guys higher up..
Then let your bosses decide wether they want to believe their talk or their results - and then they must act accordingly.
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.Ha.. back in the office this morning and there's an email asking if we're all available to work weekends through to January.. :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.
-
A few thoughts. You need to weaponize your knowledge. 1. Be aware of the difference between developer Agile and MBA Agile. It sounds like these folks are MBA style. Use that against them. 2. You say they dress and talk well. Throw out a few design pattern names. Hopefully they don't know them. That may cut them down to size and impresses management. 3. Make them fight among themselves. Tell one that their module must do this and talk to this other person's module thus. "You do not have a choice". Enforce that 4. Make a high level design and ask the/any programmer where their work fits into it. .... Youngster....
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.
-
Ha.. back in the office this morning and there's an email asking if we're all available to work weekends through to January.. :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.
I remember a meeting with a boss and his underlings where he was told that they were selling their product too cheap and that they were losing money on each item sold. His response: "Then we must sell more. Underlings, make that your top priority!" Sometimes I think that they don't put fools into a rubber cell with a tight jacket anymore. They just make them a manager somewhere.
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. -
They're coding for code-sake! :laugh: Too bad the final product isn't just a set of algorithms you're selling. :laugh: :laugh:
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
raddevus wrote:
They're coding for code-sake! :laugh:
That's exactly it, the product is treated as some kind of theoretical university project that never needs to be delivered..
raddevus wrote:
Too bad the final product isn't just a set of algorithms you're selling. :laugh: :laugh:
At this point, it really doesn't matter what the final product is - it'll probably never be delivered in any case :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.
-
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
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.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.
-
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.