|
Re^2: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship (useful)
by tye (Sage) on Jun 12, 2015 at 00:28 UTC
|
On the ground, in practice, in my experience, there isn't anything that Agile can accomplish that can't be accomplished without Agile. But it can also be a very useful toolset. It can be a burden if you have to fight too hard against coworkers who have too strong of a tendency to practice Agile soaked in too much Kool-Aid (that is, dogmatic attitudes will usually be a small problem but can also be a big pain).
It can be very useful to be able to get Agile adopted rather than work to get a whole laundry list of process changes adopted. And it can be particularly useful when you have to push back hard against Business/Product people who are aggressively impatient or demanding.
And I think there is some truth to the impression of Agile proponents that the various aspects of Agile work especially well when combined. And the principles of Agile can be useful for justifying improvements. But it is also my experience that refusing to "stray" from Agile is very harmful.
I think Agile makes a very good starting point for creating and maintaining a sane software development Process. You can also just study Agile and adopt parts of it or just use parts of it as inspiration to improve how your team works. But, in my experience, the teams that were based on Agile were closer to working well than the ones that weren't.
| [reply] |
|
|
Sounds like most 'sets of principles': read, understand, and apply judiciously; they can help you focus on what's important.
But try to impose them; dogmatically or automatically; and they become the focus. To the detriment of all else.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
|
|
I think these two lines are perhaps the truest things I've read about software development or anything else all day.
Dogmatically applying any set of guidelines as inflexible rules is both silly and against the definition of "agile" as a word and as the original movement. A team should make as much or as little use of a methodology or a mix of methodologies as works best for that team. Anything written in a book or taught in a class is just a starting point for a new team and shouldn't be an end goal.
| [reply] |
Re^2: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by Your Mother (Archbishop) on Jun 11, 2015 at 23:53 UTC
|
Divorce from bureaucracy is something that is made possible. An attempt to de-assembly-line an industry that cannot possibly work to its potential under that idiom; I know that you know this. In most corporate workplaces getting away from illogical or arbitrary and centralized process is pure fantasy and that very power structure is what is likely to scuttle any good practice and dress it the same chains as the same-old, same-old.
Regarding your other reply: hearing about something obviously doesn’t make it good either. I’ve heard little but “Six Sigma” for 15 years for example.
| [reply] |
|
|
Eons ago, we had a presentation by Motorola on Six Sigma. When they were done, we ask them, "What does Motorola stand for?". We got blank stares. For us, it was easy and was also on our business cards, "The finest in family entertainment".
James
There's never enough time to do it right, but always enough time to do it over...
| [reply] |
Re^2: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by GotToBTru (Prior) on Jun 15, 2015 at 04:27 UTC
|
I doubt there is anything done because it's "Agile" that isn't already being done by effective teams using other methodologies. I think Agile introduces effective processes to groups who haven't already stumbled upon them, or haven't learned them from experienced team members.
| [reply] |
|
|
Agile introduces effective processes to groups who haven't already stumbled upon them, or haven't learned them from experienced team members.
I think that's a very fair summation. I'd go further and say that it does what pretty much all commercially sold methodologies do: it promises to short-circuit the learning process.
But there are (at least) two problems with that:
- The calculator for kids syndrome: dependancy.
Whilst providing preteens with calculators appears to give them a head start for a few years; once they get to college age; that head start often results in a stall. One which many of them will never recover from.
Look at a high school math paper from the early 90s and if you look closely, you might notice something strange. (You probably have to come from the pre-calculator era to do so though.)
The way the questions are constructed -- whether they are simple sums or the wordy 'problems' form of question -- they are intended to be solved by someone wielding a calculator.
The differences are subtle; but for example; in the pre-calculator era, the numerical quantities in questions not directly aimed at testing basic arithmetic skills; were often carefully chosen so that the arithmetic required was relatively simple, if you were approaching the problem in the correct way.
Ie. where division was required, denominators and enumerators would usually cancel to simple, single digit reductions; powers and roots would cancel to avoid the need to actual calculate either; signs would balance out; and so on.
In this way, the test was about knowing or deriving the right formula and plugging the values in in the right places; not about re-testing the basic maths skills to calculate the final number(s).
With the advent of calculators, with them doing the actual calculations, paper setters no longer had to look for these simplifications; and so the kids never learnt to do the cancellation steps.
Role forward to college age (and the real world) and start dealing with probabilities or Taylor series expansions and the like; where instead of canceling out common factorial terms, or reducing by canceling power terms above and below; the kids try to calculate the values in full. With the consequence that intermediate terms exceed the range of their calculators; and they are dead in the water.
- The unrecognised problem syndrome.
When you reduce the learning process to a recipe-style set of steps; or que-card process; it fails to equip the learner with the learning-from-your-mistakes experience.
There is a popular TV reality program in the UK called MasterChef. Amateur chefs trying to produce professional (Michelin Star) standard dishes. At various stages the competitors are given the same recipes, ingredients and time to produce a recipe that the viewers have previously seen prepared by a professional chef. Then they are compared.
Given the same inputs, there are people that assume that they should all be able to produce the same outputs. They don't. The differences, often very marked, come down to ethereal, almost immeasurable things, like palette, experience and practice. Even an eye for color, artistic flair and a steady hand under pressure.
These are things that can't be short-circuited. They cannot be taught, they must be learnt. They cannot be instilled; they must be acquired.
Applied rote, without room for: learning by your mistakes; or master/apprentice mentoring; and by presenting all work in the singular form of user-stories; you may short-circuit a few months or a couple of years off the early learning process to obtain acceptable productivity more quickly; but you also introduce a plateau that can never be surmounted. There is no room in the system for the gifted to rise above that plateau; and no way for the level of that plateau to rise.
For the company, provided they can maintain a low-level of costs, which they can because there is no basis for individuals to become worth more than the standard rate; and replacing those who feel they want more becomes a simple process because the intake requirements are so low, this is good. Known costs * numbers = fixed overhead. Exactly what the accountant wants.
For the programmer looking for a career, it is all bad, unless they are one of those that would never progress beyond the most basic level anyway.
Present the 'products' of these methodologies -- programmers who expect all the work to be presented to them in the form of user-stories; and to work through each work item by a rote process of: if this do that; if this do that; -- with any task that does not comply with their expectations; and they are lost; because all the learning that was short-circuited -- how to gather requirements; how to prioritise those requirements; how to adjust and adapt their tools and working practices to the process of solving those requirements -- leaves them ill-equipped or unequipped to transition to the new reality.
It creates 'crisis fodder'. Young, willing, enthusiastic, (usually male) programmers that follow rote, slog through, burn long, and hard, and out.
In wartime, they are called grunts.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
Re^2: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
by jeffa (Bishop) on Jun 11, 2015 at 23:16 UTC
|
If your current development cycle is based on
- gathering ALL requirements for the project first
- then complete architecture and design
- then write the code
- then write the tests
- then deploy the code to production
then the Agile process can help you to achieve shorter completion cycles by focusing on shorter work cycles. The idea is to simply consume smaller chunks of work and produce potentially shippable product increments. This is very similar if not the same to release early release often.
There are many critical dependencies to making Agile/Lean work. There are many blockers to preventing it from working. If you ever have the privilege to join a true and successful Agile/Lean team then you will see that it works and it works well. Once the "pipeline" is successfully built and you see your checked-in code automatically deployed to test environments, etc. then you realize it is just an uber form of Clean your room.
I recommend this site http://agilemethodology.org/ to help understand the more involved portions, such as defining and implemented the necessary meetings that make this methodology so successful. The website has wonderful animated videos to illustrate the processes involved. Welcome to the future.
Update: Well BrowserUk, you can do whatever you want. If you want to learn more you can. If you want to continue to justify why you reject change, go right ahead. Just realize that you are considered a minority now and i for one am just glad that someone with your lack of vision is not on my team. For example, SSADM is specific example of Waterfall development -- which is pretty much the opposite of Agile, but one would not get that impression if they listened only to you. Thankfully we have Google and Wikipedia (and people who actually read what you link to).
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply] |
|
|
Welcome to the future.
That's what they said about SSADM back in the '80s. I rejected that back then; and I was right. Who's heard of it now?
Different methodology; same goals. The reduction of the Art of Programming to a paint-by-numbers process with interchangeable machine parts. (Programmers)
If you can reduce your programmer rolls to lots of Lil'boxes all made out of Ticky-Tacky then they can be managed as numbers in a spreadsheet.
No stars; commoditised salaries; zero-hours contracts. An out-sourceable resource, purchased on a world-wide spot market at the cheapest price.
Management has been falling for the hype for decades; and each new generation of programmers are all too ready to sign up with relish.
It may be your tomorrow; but its not mine. I did my time. Good luck.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
|
|
Different methodology; same goals. The reduction of the Art of Programming to a paint-by-numbers process with interchangeable machine parts. (Programmers)
That's been the attraction for management with every new process or programming method or language that ever gained a lot of buzz: the promise of being able to replace temperamental, expensive craftsmen with fungible, cheaper assemblers.
So if something gets a lot of buzz in industry magazines, I assume it's probably not particularly good for programmers or for the craft of good programming. It hasn't failed me yet.
Aaron B.
Available for small or large Perl jobs and *nix system administration; see my home node.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
I fully agree. Instead of writing up stuff myself - a link: Why “Agile” and especially Scrum are terrible which is a nice read.
TOC excerpt:
Specific flaws of “Agile” and Scrum
- Business-driven engineering
- Terminal juniority
- It’s stupidly, dangerously short-term
- It has no regard for career coherency
- Its purpose is to identify low performers, but it has an unacceptably false positive rate
- The Whisky Googles Effect
- It’s dishonestly sold
tl;dr:
Agile is a tool and mindset which doesn't foster individual or collective joy in business, but to extort maximum profit from programmers in the name of effectiveness, without regard for the very foundations of the latter: individual strenghts, weaknesses, handicaps, genius; and it invades privacy, which is a requirement to grow.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
| [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l]
[select] |
|
|
SSADM is specific example of Waterfall development -- which is pretty much the opposite of Agile,
No shit Sherlock!
Let me translate describe word this: "Different methodology; same goals.", just for you:
Do fings uvver ways, but same shit result.
Damn. I failed. Two of those words are more than one syllable.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
| [reply] |
