The Agile Cult
-
Lucky you. https://codeproject.global.ssl.fastly.net/script/Forums/Images/smiley\_smile.gif So I guess if management says you WILL do pair programming, you will refuse. Pair programming is part of the Agile manifesto. We even had a seminar on how great it is. Nothing helps you concentrate more than some person breathing down your neck all day, or, you breathing down theirs. The fact that some companies/leaders/managers do not force it - great for them. Now get rid of the rest of the nonsense so we can get something done.
Member 14840496 wrote:
Pair programming is part of the Agile manifesto.
That statement is patently untrue. Any qualified Agile guru will tell you so.
-
Member 14840496 wrote:
Pair programming is part of the Agile manifesto.
That statement is patently untrue. Any qualified Agile guru will tell you so.
Sorry for the choice of words. This will fit better... Since pair programming is a practice of XP it's had a lot of influence in the agile community. As a result it's often mentioned as an agile practice - meaning a practice that's commonly used by people on agile projects. But that's an observation not a prescription. Emphasis on "commonly used" here. Never heard of this nonsense until Agile came out. So change manifesto to connected with.
-
The group I was in was doing Agile already, but without the kindergarten classes. But since pair programming IS part of Agile, not practicing it means that one is not doing pure Agile.
-
Member 14840496 wrote:
But I guess at some point we all need to grow up out of kindergarten and not have to explain to adults what they should have learned growing up.
That's exactly what I thought I as read it. On the Agile thing...I really do like the 12 Agile Principles[^]. They are great guidance. And that's it. Just really good guidance -- not strict rules or specific methodology, just really nice guidance. But, THE IT INDUSTRY & PUBLISHING INDUSTRY couldn't sell that for $50 - $3,000 a pop so they had to stretch it out. :rolleyes:
Assuming that it was written by someone considered an agile guru, here's my reaction to the 12 Agile Principles. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Only if this doesn't compromise quality. Maybe valuable implies that. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Be careful not to get whipsawed, which will give no one a competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. This depends on the maturity of the system and how the new software will be deployed. If it's for acceptance testing or proof of concept, fine. If it's for end users in a large organization, it's asking for trouble. 4. Business people and developers must work together daily throughout the project. Nonsense. Developers need uninterrupted stretches of time to focus on, duh, development. This makes it sound like they can be frequently interrupted with constantly changing requirements, requests for progress reports, or other things that should be handled periodically, not daily. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Wonderful. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. It depends on the type of information. Written communication is often more effective because it records information and can be updated. Face-to-face is good for things that can be handled one-on-one or in very small groups--otherwise it implies calling a meeting, which can really slow things down. 7. Working software is the primary measure of progress. As long as you don't take this to mean that building a prototype puts you on a direct path to having a product. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Meaningless in the absence of specific recommendations. 9. Continuous attention to technical excellence and good design enhances agility. No process is more important than these, and no process can compensate for their absence. 10. Simplicity--the art of maximizing the amount of work not done--is ess
-
Huge difference between being a good Agile instructor and being a good dev manager. The former requires good speaking skills and good knowledge of the material. The latter requires good listening skills, a great BS filter and the ability to herd cats.
Even more important for being a good dev manager is the ability to shield the team from external nonsense.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Member 14840496 wrote:
Pair programming is part of the Agile manifesto.
That statement is patently untrue. Any qualified Agile guru will tell you so.
I agree. As I recall, pair programming came from Extreme Programming pre-dating "agile". Agile brings some *limited* sanity to the dev process, but it's mostly from the Xp book. Some consultants got a hold of it and made much $$.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Agile smagile. I'm enjoying myself much more now that I'm a team of one and can just code.
Real programmers use butterflies
you are weird. you will never approach a customer. Thou must be cloked. Just kidding. :)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
you are weird. you will never approach a customer. Thou must be cloked. Just kidding. :)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
You're not entirely wrong. I am weird. But I eat customers which involves approaching them, especially when they're unsuspecting.
Real programmers use butterflies
-
I agree. As I recall, pair programming came from Extreme Programming pre-dating "agile". Agile brings some *limited* sanity to the dev process, but it's mostly from the Xp book. Some consultants got a hold of it and made much $$.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I thought xtreme programming had something to do with drinking dangerous amounts of mountain dew and never getting laid.
Real programmers use butterflies
-
"Agile" doesn't force anything.
warning, member *** is an old fart and has not adjusted his/her BS filter :) No disrespect intended. I'm pondering the gripes. What *I've* seen is a somewhat whorish worship of the process rather than the product. But I admit most of my exposure has been to management that is "goaled" to achieve agile with no support, no resources, no understanding of the process, etc.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
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)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
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.
-
Team-of-one is the best.
-
Richard MacCutchan wrote:
o we followed the rules until the deadlines got too near, when we were told to revert to our normal mode of working, and get the job done.
That's funny. You were less agile with Agile, but more agile without it. :rolleyes:
-
The group I was in was doing Agile already, but without the kindergarten classes. But since pair programming IS part of Agile, not practicing it means that one is not doing pure Agile.
Pair programming as intended is wasteful and almost never done. But sharing office space with one or more coworkers and exchanging small setbacks, roadblocks, pointers and basically rubberducking and soundboarding each other has worked very well for me in the past. Indeed I hope my next workplace will have such an atmosphere. As a programmer with ADHD I do poorly alone - I may write a metric crapton of code in a week and gaze at all wikipedias articles for a month because SQUIRREL!
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
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
-
Pair programming as intended is wasteful and almost never done. But sharing office space with one or more coworkers and exchanging small setbacks, roadblocks, pointers and basically rubberducking and soundboarding each other has worked very well for me in the past. Indeed I hope my next workplace will have such an atmosphere. As a programmer with ADHD I do poorly alone - I may write a metric crapton of code in a week and gaze at all wikipedias articles for a month because SQUIRREL!
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
In most offices, you ARE in a shared space for sound-boarding - I did it all the time. I do not have a problem with that. And I have no problem going over to others and describing issues/ideas. Most mature adults will do that on their own, and not require a sheep herder in order to force it. And as (supposedly) mature responsible adults, we all should be doing what we need in all aspects of application development. We should not need to be 'forced' by Agile tactics to accomplish what we are supposed to be doing without it.
-
You're not entirely wrong. I am weird. But I eat customers which involves approaching them, especially when they're unsuspecting.
Real programmers use butterflies
lol. You'll just confuse them. Back to the lab with you. I've worked with a couple of people with really high intelligence and passion (over the years). Nothing wrong with the rest of us or you, but some of you are just in your own little orbit. I made sure to send food to engineering from time to time. *Always* got my bug fixed.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
In most offices, you ARE in a shared space for sound-boarding - I did it all the time. I do not have a problem with that. And I have no problem going over to others and describing issues/ideas. Most mature adults will do that on their own, and not require a sheep herder in order to force it. And as (supposedly) mature responsible adults, we all should be doing what we need in all aspects of application development. We should not need to be 'forced' by Agile tactics to accomplish what we are supposed to be doing without it.
I never got into the pair programming thing, but I just had a small epiphany. Do PCs work with two keyboards? A keyboard and mouse is probably the most peculiar thing about a developer (one of the reasons why I hate new laptops - getting used to the keyboard). I just have this vision of two developers beating each other with keyboards.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
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
And you need Agile to perform those 4 items? They all seem like common sense to ME (emphasis on opinion too).
