The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
...developers themselves decide on how long implementation of a feature would take,
In my experience, the non-technical PMs and BAs ignore what the engineers say about how long a task should take, and simply pick whatever suits their promises to management. The scrum approach is fine for deterministic manufacturing processes, but wholly unsuited to almost all software development. Kanban is a better approach, as software development time estimating is a venture best accomplished with a crystal ball. There are usually too many unknowable variables when it comes to estimating time.
I think you read too much blah blah or is in a poor working environment....
From the last 5 company I work on agile is kind of we decide what's next every 2 weeks... And also it's not other methodology. Like it's NOT waterfall. (I dunno what other "methodology" there are.. and Project Manager love these, so they need a name to describe what they do)
Not sure what you are saying about 'reading' blah, etc. I described what I was experiencing - a poor work environment created by the Agile leader and management conducting kindergarten classes for adults who they believe are not responsible and need to be herded around like cattle.
We had every 2 week intervals as well; and after removing daily standup times and business meetings, we all realized we were only developing about 2-3 days a week; which is ridiculous and expensive.
I think this rant is more against scrum than against agile in and of itself. I also think that mindlessly implementing Scrum is a very bad idea.
The scrum ceremonies (stand up, planning, review, and retrospective) all take too much time in 2-week sprints. Personally, I think that for any kind of mature product, 2 weeks to develop a shippable feature is too short, unless you can do it all in parallel, which is unlikely.
Agile should be about taking the ideas that work for you, your team, and your project. And it requires that management and client understand what you're doing.
As for pair programming: that is not a necessary part of agile. I never worked in a full pair-programming environment (I don't believe it would work), but pair programming sessions do yield good results, IME. It doesn't double the cost, because it's much more likely to be correct and it helps in sharing knowledge around in a team.
That said, if your employer starts talking about implementing SAFe: run and don't look back.
The Agile Manifesto is tiny, the implementation is the problem.
Scum is an implementation of agile.
How people implement it, and then actually execute on it is the pain point.
Pair programming (or over seeing a junior) via screen share is far better for ME (emphasis on opinion) then sitting next to someone and the screen further away then sitting on own computer and seeing their screen.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I agree that the implementation is the issue, and I think that the OP suggests that it's the Agile perfectionists who ironically don't embrace the spirit of the thing and force the processes and tools of agile implementations to prominence over the individuals and interactions.
I've never worked in an Agile office, but I do love the manifesto, if not the reports of implementation. In our office, we meet twice a week for basic concerns and discussion of things upcoming, and we share online workspace in a way that allows us to be an extra pair of eyes on any issue (not paired programming, but old-fashioned lending a hand). I would like to have more input into future projects, especially the refactoring and updating of the site, as the agile way seems to inspire.
1: Pair Programming
2: Cubified Environment
3: Poorly Run Meetings
In all the Scrum training I've received no mention of paired programming at all.
As for the open workspace, that is just ridiculous. More frequent communication != distracting work environment.
Also, our morning meetings are timeboxed to 15 minutes - so poorly run meetings aren't Agile either.
If you're in a poorly run Agile environment then yes, it will be chaos and a waste of time; however that can be said for any poorly run methodology.
Actually, I went from a large monolith company to a smaller company that respects our work environment and abilities, and leaves us to do our job we were hired to do, not attend kindergarten every day.
Someone correct me if I am wrong, wait - I'm in the lounge, that happens naturally here....
My perception, and it's been a few years that the roots of agile come from extreme programming (there is a great book somewhere here, maybe my attic) which with the exception of pair programming, opened my eyes to some serious issues in our industry. At the time, I was a manager of a DB development team. After I read this book, my conclusion was we're doing this wrong.
This is where Agile just made things way too complex for me. KISS is better for project management - hence I understand the OP's rant. Nuggets and epiphanies I pulled from this book:
Customers set features. Customers won't know exactly what they want until you put something in front of them. Customers lie. They think they know what they want. Beware.
The requirements / features will change. Stop your bitching. You best have a management model to deal with it. I've listened to developers complain for 40 years about changing requirements. It's normal. I think agile addresses this with gold plated story boards, etc. I don't know. Just recognizing the facts that customers do not know what they want and things will change is the first step in recovery.
Customers do not do estimates. The people doing the work do. Again, over many years I have seen really smart people go green and puke having to come up with estimates. Software and systems development is hard. The people doing this work (not customers, PMs, management) are the ones that should be estimating. What I have seen again and again is a developer coming up with an estimate, it's too long, and some individual whacking it by half or more to meet some artificial schedule. The developers never learn how to properly estimate in this environment, so the entire system is set up to fail.
I actually consult with a well managed company. I truly mean that. Even so, they make these same mistakes. The only way customers are allowed to change the schedule is to change the priority of the features they want. They are actually starting to understand this. Even so, how many of us have been asked, "How long will this take?" with no requirements, no feature list, no h/w spec, etc?
This gets back to estimates. I've seen estimates get whacked to meet artificial delivery times (usually there is a trade show involved ) and then listen to PMs and management complain bitterly that "the development team missed their scheduled commitments" when in fact, they hit their estimate but missed management's.
This is THE great lie, and the Extreme Programming book brought it out in a simple and well explained manner. It was an epiphany to me. At the time, I was struggling with estimating projects, and the book exposed the underlying fallacies of this nonsense.
The rest of agile? all I know is that currently the agile team is growing and the development team is shrinking. That's another story...
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I agree wholeheartedly. The principles found in the Agile Manifesto bear little resemblance to the resource-wasting, bloated bureaucracy of what is considered "Agile" today. Among the worst of the offenders in this current implementation is landing non-technical PMs and BAs in charge of managing software projects. Experienced software engineers can learn good project management and business processes FAR easier than non-technical business types can learn software engineering.
FWIW, if you the reader have nothing better to do, here are some Linked articles I wrote a while back that are still true today and address this topic.
Couldn't agree more. The customer facing side of agile with quick turnaround times and continual feedback is good. The management side is mostly crap. Pair programming? Who came up with that? That's way out there in left field. Agile is based on "collectivism" where the whole team "owns" everything which basically means nobody owns anything. When you don't have ownership for what you do, you are less likely to take care of it. Whens the last time you washed and vacuumed out a rental car before returning it? When you have complete ownership in what you do, its your baby and you will naturally do whatever it takes to make it a success. Its human nature. Developers should own the code they work on. If it breaks, they should be responsible to fix it. If its a success, they get the credit. Developers should be involved in all of the high level meetings with the customer, setting priorities, etc... In fact, there should be less project managers, more software engineer / rock star / project managers. Developers should be managing their own projects.
I agree with you, aside from your point that just talking to each other is enough in large teams. From a certain team size on (maybe ~8+ programmers), I don't see how it can work without agile. In an innovative environment, where the project goals change several times over time, it's almost impossible to keep everyone heading in the same direction without any formal procedures. I also find them painful, but I see the necessity.
It has it's place. In the right place it can work well.
My 2c. Any methodology can be made to work with the right people involved. I've seen really slick implementations of Agile that were doing great work. More often though I've seen really sick implementations of Faintly Resembling Agile (Fragile) that are like a big ship in search of an iceberg.
I think Agile is reliant heavily on the cohesion of the people and their shared vision in a way that other approaches do not suffer. And in my experience it gets worse as the team size grows.
The only other thing that I would add is that the current fad for Agile for everything is dangerous. Agile procurement, Agile quality control. . .For starters it does not fit well with fixed price solution procurements in Government.
I've only got that because they are short-staffed at Herself's work - so she couldn't get to her one on the 8th and had to reschedule. So I cheekily asked if I could get mine at the same time as her since it's an 80 mile / 130Km round trip.
And they said "Yes, if you can make it for 11:20". Can we? Oh yes!
Gah! I'm actually looking forward to be stabbed with a needle ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
Last Visit: 31-Dec-99 18:00 Last Update: 17-May-22 21:18