|
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.
|
|
|
|
|
Wrong forum. Make it a blog post.
|
|
|
|
|
Our team went through the same pain years ago, when consultants in the US tricked convinced management to go this route. So 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.
|
|
|
|
|
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. 
|
|
|
|
|
That's what I told my management when we were told we had to start doing (sorry) Agile.
Me: "We're already Agile, have been since the beginning of the project."
He: "Oh, but we'll use Scrum."
Me: "We looked at Scrum, and adopted a few of their ideas, but our project isn't suited to Scrum. Scrum would slow us down."
|
|
|
|
|
|
raddevus wrote: You were less agile with Agile, but more agile without it.
What this highlights is that whenever there is a Hot New Topic in town, it takes on multiple meanings:
1. The original meaning, which was usually a bottom-up, emerged kind of way in which developers, through trial and error, came up with a fruitful way-of-work that was a natural fit to them. In this case it was "agile" (no capital used), agile, as in, agility, flexible, to-the-point, and additionally to that, a team where members would operate in mutual trust and a shared understanding of the job at hand which turned out to be pretty darn effective.
2. The way it was landed into the belief system of a management party (colloquially referred to as "the boss"). This is no longer a first-hand experience and loses its initial authenticity and it much depends on a kind-of self-discipline exerted by the aforementioned manager, in how authentically and truthfully they process whatever information comes to them.
Now, it so happens that the position of manager is a major attraction to those individuals who have a combination of, say, being verbally apt, but factually feeble, and shall we say, gullible, or sometimes, just short-sighted. It's not hard to imagine how a fad can grow out of proportion in such hands.
|
|
|
|
|
I've mentally broken it into four five levels:
1. agile
2. Agile
3. "Agile"
4. Aaaaarrrrggghhhh!!!
5. The Madness of Cthulhu
Sounds like he's somewhere between 4 and 5.
|
|
|
|
|
I saw a single team that used the Agile methodology do great work consistently for several years - I suspect it is because the leader is skilled and capable enough to make any kind of methodology work.
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 is fantastic and the most successful way to go that I have seen in all my years. Small businesses were already doing Agile before Agile was even a thing.
But pair programming is all kinds of wrong, I'll agree to that.
|
|
|
|
|
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: it means that one is not doing pure Agile.
No. There are lots of flavors of Agile.
Regardless, take what is good and works for you from Agile and go with it.
|
|
|
|
|
This (in everything & in all ways)!!
newbie_12 wrote: Regardless, take what is good and works for you from Agile and go with it.
Nailed it!
|
|
|
|
|
And where did you get this strange idea that pair programming is required for agile?
|
|
|
|
|
Because it was forced on us by management.
I think Gerry Schmitz's response sums it up quite nicely.
|
|
|
|
|
Your problem is not agile. Your problem is bad management.
|
|
|
|
|
Interesting but the problem here is that the manager was also an Agile instructor/guru/etc.
Again, I will defer back to Gerry Schmitz's response - it applies here.
|
|
|
|
|
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.
|
|
|
|
|
As far as I can see, Garry and i say the same... Incompetent managers in charge of process or architecture decisions is the problem.
Neither should be the responsibility of managers. Having the manager being the process "guru" is even worse - no chance of a second opinion if he does not listen.
Knowing when not to apply a process - even if you had success with it earlier - is hard to do, and just because you are seen as a "guru" does not mean you have mastered this.
|
|
|
|
|
This article sort of confirmed my assertion. The article seems more like a psychology brief.https://codeproject.freetls.fastly.net/script/Forums/Images/smiley_biggrin.gif
Agile Ready Leaders Get Their Start in Kindergarten
Published on December 23, 2016
|
|
|
|
|
I searched for that article and found it[^].
It is interesting that the article goes all the way down to the basics of:
Quote: Consider the four basic tenets of leading in an agile environment (introduced in our first blog). Software engineer Kent Beck designated three of these as Be Honest, Be Kind, and Work in Small Increments. Jay added the fourth: Be Responsible.
|
|
|
|
|
Yes, I read it.
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 we need other adults to show us how we (as adults) should inherently act and work by default.
I agree with most of the Agile goals. My point is that it should be part of a personal practice that does not require herding people (like cats), spend excess hours and money to accomplish what responsible people should be doing, and if you do, then maybe those individuals are in the wrong career field.
|
|
|
|
|
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.
|
|
|
|
|
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 essential.
This also means developing software that can cleanly support known future requirements in the current release, even if that slows things down.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
Self-organizing sounds magical, so it must have implications of which I'm unaware.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Sure, the continuous improvement thing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
