71–80 of 133 posts
To the extent that I've seen development methodologies work, they appear to mostly fix organizational barriers that get in the way of The One Thing That Actually Works[1]: hire a small group of extremely talented developers and product designers and then let them work. [1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.
Earlier quoted context omitted.
I've read your comments a couple of times and still can't really see what you've added. You're talking about very abnormal situations. Companies that are so technically incompetent they have to hire you. And then saying that we should listen because in your abnormal experience of dealing with teams so dysfunctional they can't even ship bad software that agile at least gets them going a little bit. I suspect almost an…
I also disagree with the premise that these situations are very abnormal. Ours is a big field which expands outside of sunny California, where you can't walk a few feet without bumping into a rockstar coder. In the rest of the world where the mediocre is the status quo, Agile gets team members organized and motivated. Of course, if you could find rockstars, you'd hire them, solve many problems, and ship your product.…
Here there's dev meetups, Second Wednesday, Notts Tuesday and probably more regular events I don't even know about.
I've talked and worked with a lot of developers round here now as well as interviewed with a fair few companies and done their technical tests and talked to their lead developers.
A lot of them write better code than I've seen in the github repos of Californian 'rockstars'. And yes, there's plenty of bad code too, out-dated practices, people asking me if I know VB.Net. And yes one of the companies I worked at (oh so briefly) had terrible code.
No different from the Californian mecca I imagine. Do you think that only good developers go to SV. There's no magic forcefield keeping bad developers out of California. In fact because SV is so desperate you might even argue they probably have a lower average standard.
There's plenty of shipping, successful products coming out of this city and successful IT Teams working for other industries. And bad ones.
Scrum Agile works great. Keep it light and loose and watch the code fly. I don't know much about the other flavors or taking it too far into process but I've seen the amazing things Agile as a philosophy can do.
My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this.
The main differences I can tell between the two: this project we have a lot more documentation. All on wiki, but on the previous project, be barely had anything, and just asked people what the idea was and then did it. But my current project is at a bank, so it makes sense they want more planning and documentation, and less just figuring it out as we go.
At another job, our Scrum wasn't really Scrum. We had standups, but that was it. No sprints, no poker, no scrum board, no burn down charts. But what this article makes me realize is that that project may actually have been more agile. Very few formal planning meetings, lots of informal communication and programmers just doing what they're good at and calling the shots.
Earlier quoted context omitted.
It's a good question. But personally, I think that people would have stopped believing in waterfall approaches anyhow. Anybody sticking with 18-month release cycles today would seem like an idiot whether or not anybody had heard of Agile. And really, what a lot of supposed Agile teams are doing is really mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit and self-delusion.
I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.
That an emphasis on delivering software, on interactions instead of process, etc. seems normal and no different permeates the industry such that people see it as the status quo. I assure you, that is not how it used to be, and there is a huge difference other than less emphasis on documents.
All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who ar…
If you get people who aren't customer focused, aren't testing, and are wasting huge amounts of time in pointless meetings focus on their customers, do continuous builds, tests, iterative releases, and have fewer meetings I suspect you can and will reap significant benefits. But that isn't "agile" it's just some good practices with a label du jour. Good software companies were doing nightly builds twenty years ago (wh…
That said, the thing I dislike about this new "Agile has failed" meme is that it discounts how much the movement has changed the status quo. Sure it make sense now that small iterative releases, continuous integration, automated tests, customer collaboration, etc will produce better software. And yes there were teams that did this before Agile became popular, but it certainly wasn't the norm.
There used to be no standard way to write/run unit tests. The class of software called continuous integration server did not exist. Gant charts were completely normal planning devises.
I've worked in environments that literally believed that a senior developer could use uml to design the entire system down to the method level and then it would be a trivial matter for a junior developer to "fill it in". That sounds insane now, but it happened throughout the software industry.
Agile didn't fail, it worked so well it became the norm, and now the term is being co-opted by opportunists. That's sad, but let's not let that detract from the very real success story of the Agile software movement.
Earlier quoted context omitted.
I'm fond of, um, mine. :-D http://www.jamesshore.com/Agile-Book/ It has a section in the front that describes which pieces to read depending on which role you're in.
I second this. My team is about 18 months into our transition to agile, and it is a tough road. This book has been an excellent resource. The one gap is that it mostly focuses on greenfield projects. It does a good job of highlighting the parts where legacy systems will make agile more difficult, and I understand that spending more time on that would have made the book harder to understand. But we've had to do a lot…
Earlier quoted context omitted.
I'm fond of, um, mine. :-D http://www.jamesshore.com/Agile-Book/ It has a section in the front that describes which pieces to read depending on which role you're in.
I second this. My team is about 18 months into our transition to agile, and it is a tough road. This book has been an excellent resource. The one gap is that it mostly focuses on greenfield projects. It does a good job of highlighting the parts where legacy systems will make agile more difficult, and I understand that spending more time on that would have made the book harder to understand. But we've had to do a lot…
The big piece that we're missing is how to apply agile practices consistently when our velocity varies so significantly because of legacy code. Feathers' book gave us a long-term path to getting out of that issue, but we're struggling with the planning and communication side of things in the meantime.
Earlier quoted context omitted.
I think you missed the part where he implied that what programming culture considers "good" software is nothing short of a near-perfect to perfect technical implementation. In other words: what the other guy called "shitty" is actually the average. See also the odd thing that most people consider themselves better than average, which by definition cannot be true.
Yes, the idea that almost everyone considers themselves to be a better than average driver. I've always wondered with that whether the problem is with the question. What it's really checking is whether someone will admit to being worse than average, which is a very different thing to thinking you're worse than average.
Googling it, the example given is "starting conversations with strangers" and his theory is that people ignore the question they are asked ("how they compare with average") because it's hard/impossible to actually answer, and instead, without realising it, substitute an easy question ("are you good at x") and answer that instead.
I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved. Then support queries came in for the features we developed previously. At first a couple of team members would split off and work on the existing features while the rest of us carried on working on the new hotness. As we increased the number of (quite diverse) features, the more di…
* 'support queries' are actually bug reports: you're getting something wrong with your automated testing that's letting bugs get out into released code. Ideally you should have acceptance tests that make sure the code is doing what it should before you release it. Check what your team's criteria for 'Done' is - are they cutting corners to get things out the door?
* 'support queries' are actually missing functionality in new features: you're not getting all the requirements for the feature in the sprint where you implement it. You need to make sure the conversation with the product owner covers everything that the feature (user story) should do.
* 'support queries' are actually new feature requests: they should go in to the backlog and be prioritised along with everything else. You shouldn't let people push work into a sprint that hasn't been prioritised by the product owner.