Opinions needed.. (no, really! :))
-
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.
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.
-
W∴ Balboos wrote:
Agile - an MBA's idea of how programming should be done.
It's too bad it has descended into that. I often talk about he _heart_ of Agile as it is defined by one of the two original "creators" of the Agile methodology in the following book: Scrum: The Art of Doing Twice the Work in Half the Time[^] It's really a great read and if you were to read it I believe you'd find, as I did, that Agile is a set of processes pulled together into a methodology that explains how real work is done. But, alas, it is described in so many places so poorly.
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:
alas, it is described in so many places so poorly.
Of course it is! That's because it demands that lowest priority be given to documentation!
I wanna be a eunuchs developer! Pass me a bread knife!
-
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.
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!
-
raddevus wrote:
alas, it is described in so many places so poorly.
Of course it is! That's because it demands that lowest priority be given to documentation!
I wanna be a eunuchs developer! Pass me a bread knife!
-
R. Giskard Reventlov wrote:
Simple: toss out agile and do it properly.
I was too chicken to post anything like that in public. (pssst, I think I was the tenth upvote on the comment)
R. Giskard Reventlov wrote:
Oh, and fire all the script-kiddies and get some real coders in.
Disagree; totally. Age is irrelevant. Yes, experience does count, but it's a matrix thing, not a linear one. I'm Not sure of this at all, so ask a real lawyer or Human Resources pro, but I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members. With that caveat, and reading your description, I highly suspect that your teams contain *some* members with very low verbal skills, and *some* members with very high verbal skills. My sole opinion: That is the root cause of what you are describing. Second factor: The Agile Approach. At times, I am convinced that the whole thing was intended to be a hoax, much like Administratium. (Go look it up if you've never seen the word before.) Third factor: Money. You have used financial forces to induce, entice, and goad people into professing personal belief, adherence, and agreement with The Agile propaganda (^H^H^H^H^H^H^H^H^H^H development methodology). Put those three factors together: [1] Disparate verbal skills, [2] The Agile Approach, [3] Financial forces; and I believe that what you are describing will happen in pretty much any project that requires software, firmware, electronics, website interaction, databases, whatever. The self-contradicting paradoxes within The Agile Manifesto are so rampant and so wantonly linguistically absurd that I truly wonder how much alcohol is present in the bloodstreams of those people who make the decision to use it. Turbo-charge these paradoxes with financial forces, then apply them to teams with no formal assessment of personal verbal skills among them, and, well, that's what you get ! My sole opinion. Anybody else who believes this has to pay me a dollar.
Interesting response!
C-P-User-3 wrote:
With that caveat, and reading your description, I highly suspect that your teams contain some members with very low verbal skills, and some members with very high verbal skills.
I have no idea what this means in reference to my post. I am guessing you are taking the phrase script-kiddies and misinterpreting it. By script-kiddies I mean developers straight out of uni with little to no experience of the real world. All of the people in the team are articulate and smart (young or old).
C-P-User-3 wrote:
I think it's against the law to test for verbal skills with respect to any business decision with employees; whether they be prospective, contract, or full time W2 staff members.
I have no idea if that's true or not. Regardless, you (or anyone) is not going to hire someone for a job that is incapable of communicating their ideas or displaying knowledge of development. That is the point of an interview. Anyway, think you may have the wrong end of the stick here.
-
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.
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!
-
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.
Get rid of Agile and TDD and start using standard software engineering practices. Your team appears to be completely focused on the process and not the development of an application. This is what happens when you use a lot of the newer concepts in development instead of sound development practices that have been proven over many years of studies and research...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Agreed, but I also like the "latest and greatest" thing.. it's more about using it as intended and where it makes sense.. for example, I quite like Angular 2 - myself and another long term developer (from my team) created a working demo app for these guys. The Angular TS code was hand-crafted (very lightweight) with a simple ASP.NET web API back-end, and successfully integrated with a 3rd party system.. But these guys got their hands on it, deleted and refactored code, insisted on using Angular CLI which has led to them breaking pretty much everything, and they now need PowerShell scripts to be able to deploy anything to Azure (yes, really!).. it's a mess and doesn't work, but it's now sort of testable.. :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.
One of my pet peeves is with people who take apart something I have laboured over and perfected, only to completely mess it up. It happens so often that I just sit back and watch the fun these days.
We're philosophical about power outages here. A.C. come, A.C. go.
-
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.
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!
-
Foothill wrote:
Nothing gets a programmer's motor running quite like a really sexy algorithm.
It's true. I too have fallen in love with my own code. :laugh: Other people's code is boring though. Meh. :-D
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.
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.
-
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.
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.
-
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.
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).
-
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.
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
-
That was my recommendation, but that's off the table. These guys won't let go of Agile (I'm not against Agile, btw, but these guys are fanatics of [their interpretation of] Agile).. I tend to concentrate on getting finished products out fast with as few bugs as possible (while accepting that it's impossible to avoid 100% of bugs). Unit testing gets added for complex functionality but ignored for standard run-of-the-mill stuff.. has anyone seen any articles promoting rapid application develop (but without 3rd party frameworks) over Agile? I'm really looking for some evidence/white papers covering different ways of running the project - something that can possibly be enforced on the team, considering their poor performance so far.. 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..
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....
-
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.
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.
-
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. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups. Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
raddevus wrote:
Many people (developers) have no real process. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups. Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
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.
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.
-
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.
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."
-
Mark_Wallace wrote:
That's because it demands that lowest priority be given to documentation!
That's a funny catch-22! :laugh:
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!