Agile is the current day water fall model. I mean in spirit on in factual procedures.
>>I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings
I completely understand this feeling. The problem is so plain and simple. There are teams that win because of heroics, they achieve something big. Those management types who lack the chops to be heroes simply try to turn heroics in a process.
So what they basically do is, watch a team win. Instead of realizing its the interesting/challenging nature of work combined with things like lesser distractions, strong deadlines and well aligned monetary incentives that count, they rater look into common set of patterns that they would do. The net result is they end with a really boring process.
If you think to be successful you have to do X, Y and Z steps you are doing it wrong. X, Y and Z are catalysts, enablers or at most methods to keep you sane while you pursue a higher purpose.
My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.
My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.
It's a bit of a tangent but I've also observed this. So much that I've started calling it the "cucumber-complex".
Once infected the team not only writes excessive unit-tests to validate things like that
a method-call to 'foo' does indeed call the method 'foo'. But they also wrap these unit-tests in quite elaborate parsers in order to "express" them in pseudo-english.
The hilarious (cucumber-specific) aspect is how they usually start by writing their tests in plain RSpec or Test::Unit and then go at implementing the parser to make it "tell a story".
the most important bit, i think, is that a cucumber test suite is documentation that cannot go out of date, because if it does your test breaks and you have to fix it, thereby updating the documentation aspect of it.
> Agile is the current day water fall model. I mean in spirit on in factual procedures.
I think the problem is people sticking to a particular process, thinking it's the definition of "Agile". Rather than responding to change and the individuals in the team.
As our team was growing to the point where planning sessions were taking several hours we switched to just in time planning. A couple of developers could give a lightweight estimate of work at any point. Planning became just a 30min discussion with stakeholders to prioritise work, and we'd dig into implementation details as a team when we actually started working on something.
This would obviously not work for everyone. My point is that we responded to the problem and adapted our process to change in the team and environment. It's the 4th point on the agile manifesto http://agilemanifesto.org/
Retrospectives should give an opportunity for teams to do this if done right.
someone should tell everybody that it is not us or them, but we.
unit test help us but not them? How can that be true if they pay your salary. If tests make you more efficient, so becomes the/their team (we/them as you please). In the end even the customer is influenced by good unit tests, or any other improvement for you.
Bottom line: stop thinking us vs them, think we.
>>Agile is the current day water fall model. I mean in spirit on in factual procedures.
>>My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.
Whenever I read opinions like this all I hear is "Wah wah wah. I'm old and I don't like learning new things. What's wrong with the way I've always worked? Wah wah wah, managers."
The problem with unit tests and a certain type of manager is that they see the unit test coverage as something that must be managed to be as close as possible to 100%, when this is arguably a waste of effort.
Agile has been around for many, many years. I think the Agile Manifesto is a teenager by now. There are a lot of people well into their careers who have "always worked" the so-called Agile way.
Sure, but I don't see why an effort to study how successful teams work and distil in a methodology needs to be derided by other programmers.
Most managers I've worked with just wanted some transparency and predictability to the process. Waterfall failed to provide that and now the industry is experimenting with Agile.
I find it distasteful when developers grumble to each other about having to perform basic tasks such as unit testing (TDD, BDD or whatever). I've worked with far too many 1/10x developers to know some kind of process is required to keep them on the straight and narrow.
There is no magic bullet, but I think it's time we stop snorting in derision at the industry's attempts to reduce the unpredictability of building (and maintaining!) complex software.
>>I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings
I completely understand this feeling. The problem is so plain and simple. There are teams that win because of heroics, they achieve something big. Those management types who lack the chops to be heroes simply try to turn heroics in a process.
So what they basically do is, watch a team win. Instead of realizing its the interesting/challenging nature of work combined with things like lesser distractions, strong deadlines and well aligned monetary incentives that count, they rater look into common set of patterns that they would do. The net result is they end with a really boring process.
If you think to be successful you have to do X, Y and Z steps you are doing it wrong. X, Y and Z are catalysts, enablers or at most methods to keep you sane while you pursue a higher purpose.
My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.