|
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.
|
|
|
|
|
lmoelleb wrote: Your problem is bad management.
Show me a business problem that isn't. 
|
|
|
|
|
Member 14840496 wrote: But since pair programming IS part of Agile
Eh? I've been working in an agile environment for 5 years now and we hardly do any pair programming. In fact I have never pair programmed during that time.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
My partner in pair programming is DuckDuckGo.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
charlieg wrote: Do PCs work with two keyboards?
Yes, and 2 mouses as well. I even used dual mouse for a game...
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
|
|
|
|
|
Video or it didn't happen! 
Seriously, details please.
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.
|
|
|
|
|
LOL no big deal, in Gabriel Knight 3 there is a part of the game where you have to collect fingerprints and it requires a lot of clicking. My game craqshed, I had to redo it again and had no patience, tried using both the plugged mouses (dual boot system and one mouse didn't work on Linux) and I manage to click hyperfast using both hands.
I then used it a bunch of other times in some stupid minigames where a crapton of fast clicks were needed to have a slider go up, I forgot the games though. Also I had two keyboards on because my pro gaming wonderful keyboard... doesn't work in BIOS. So I have a basic second one always plugged in.
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
