The Agile beat up thread

[Meadmaker]

Originally Posted by gnome

The first time I heard of Scrum (never learned what the word meant)

It's a Rugby term. (It may also have some use for similar situations where a bunch of people are stuggling together, but I always associate it with rugby.)

[Filippo Lippi]

Originally Posted by Wudang

A blog post by Nic Ferrier
http://nic.ferrier.me.uk/blog/2014_1...-to-anti-agile






Rigid agile is an oxymoron. It violates a basic rule of "Individuals and interactions over processes and tools".

Interesting thread, especially Wudang's linked blog . I searched for the topic as "the man" is insisting I can be a "proper" scrum master on top of all my mainframe lead Dev tasks. Our "training" has been three, one-hour readings of a pdf*, so you can see how committed the organisation is to getting this right. Our (not IT) CEO has decided that Agile is the way and boxes have now been ticked. If/when it fails it will be our fault.

Not against it, just doubt we'll be given the time to do it well and I already know it's going to be "rigid Agile."


*a slide said all user stories or tasks, I forget which, have to be "estimable" in a mnemonic. I will never stop laughing

[Wudang]

When IBM was losing its way in the 90s I remember someone posting a nice analogy in an internal "forum". From memory "All this time we've been plough horses, slow and steady and getting the job done. We know how to plough fields, we're good at it. But now we're told we have to be race horses, be swift and fast. That's okay, we're flexible and we can change. But first we need to prepare the ground to race on. So we plough it. We know how to do that. We're good at it."

[Wudang]

And you simply can not learn to be a Scrum master like that. My wife got Scrum master certification and it was a week long immersive course and hard work. I am very much not a fan of Scrum as it's a school of Agile that just leads to endless bickering about whether something is "True Scrum" or not.

eta: We rotated the scrum master role* among the 4 devs in our team as that gave each of us a tick box in our assessments and shared the pain of hosting the meetings with stakeholders.
Your CEO sounds like an example from Nic's first paragraph

Quote:

There are two sorts of people in the world right now who are ******* up the production of software. The first, people who have no clue about software, is still the larger group.

eta2: *We didn't do scrum. We were agile and used a very light process to manage our work. Work referred to the lead as the scrum master but it was totally nominal in our case.

[Filippo Lippi]

I hold out little hope for proper training. When I was promoted to "lead" dev I asked to be sent on some "people leading" courses, because I want to do this properly. I was told, even though the courses were internal, there "was a cost, so no." Instead I was directed to a dozen, two page pdf's and five minute YouTube videos (several with broken links) under the title "personal effeciveness [sic]"

[novaphile]

Yeah, I'm a certified scrum master and I still think:

(a) Agile sucks; and,
(b) Agile is a work management methodology, not a systems development methodology.

[Filippo Lippi]

Yeah, we're definitely going to be doing Agile properly this time (WINK!)

[CriticalThanking]

I'm always part of some group doing specialized triage/fixes that doesn't fit the way Agile is implemented for other teams in the same reporting hierarchy. We continually mess up their metrics. I have these conversations several times each quarter.

"I know I have too many stories/tasks open at the same time for your metrics. I'll try to ask users to schedule their emergencies in different sprints from now on."

"Sorry, your leg was on fire. I apologize for putting it out instead of completing the planned fire inspection on time. I know that hurts your metrics. I'll do better next time."

[novaphile]

Originally Posted by CriticalThanking

I'm always part of some group doing specialized triage/fixes that doesn't fit the way Agile is implemented for other teams in the same reporting hierarchy. We continually mess up their metrics. I have these conversations several times each quarter.

"I know I have too many stories/tasks open at the same time for your metrics. I'll try to ask users to schedule their emergencies in different sprints from now on."

"Sorry, your leg was on fire. I apologize for putting it out instead of completing the planned fire inspection on time. I know that hurts your metrics. I'll do better next time."

Now I want to see a burn-down chart that includes 'leg on fire'.

As long as you weren't telling them that it was raining...

[8enotto]

The product ad just showed up on my YT feed so I let it play a bit.

It was promised that management of my projects would become so smooth and wonderful. The guy in that office sure looked efficient too. But all he really was doing was selling software.

This thread doesn't read like he was talking.

[Wudang]

Originally Posted by 8enotto

The product ad just showed up on my YT feed so I let it play a bit.

It was promised that management of my projects would become so smooth and wonderful. The guy in that office sure looked efficient too. But all he really was doing was selling software.

This thread doesn't read like he was talking.

The writer John Diamond had an article where he talked about getting a new irrigation system in his garden, underground pipes delivering water efficiently throughout it. Then he turned it on and all he had was the same garden except wetter. He still didn't have all the practices in place at the right time to have a good garden.
I can't remember what he used it as an analogy for but it works for agile, OOPS, and others. It's collected in his excellent book Snake Oil which has some wonderful analogies for alternative medicine.

[novaphile]

Originally Posted by Wudang

The writer John Diamond had an article where he talked about getting a new irrigation system in his garden, underground pipes delivering water efficiently throughout it. Then he turned it on and all he had was the same garden except wetter. He still didn't have all the practices in place at the right time to have a good garden.
I can't remember what he used it as an analogy for but it works for agile, OOPS, and others. It's collected in his excellent book Snake Oil which has some wonderful analogies for alternative medicine.

Hear hear!

Agile works very well if you have a fully developed set of requirements.
That's one of the reasons why I liked using Agile with RUP.

I'd never been exposed to RUP before, and certainly hadn't used it, and was dropped into a team that had no analysts. I was told: "You need to write use cases for us and stay at least one iteration ahead of the developers."

I gave the team three use cases and the first bit of the supplementary spec in the first round (NB. including class diagrams, requirements met by the use case, basic flow, and the first couple of alternative flows.) and the devs took them away to discuss.

Later that day they came back and said: "This is the best object-oriented design we've ever seen."

I had no idea what an 'object oriented design' was, and had no idea that I'd delivered a 'design' in any form.

The devs showed me where they had grouped collections on the class diagrams (circles around classes) to identify screens required and how elements from the basic and alternative flows defined the controls they needed to expose.

They divvied up the work via Agile/scrum methods, including daily stand-ups, where occasionally the devs would ask me for assistance in fleshing something out, or let me know that there would be an opportunity for me to generate and install a new snapshot so that I could confirm it the use case had been realised or not.

That is the power of a good methodology.

An analyst who has never even seen it before, can be churning out 'designs' and be productive in a week.

(NB. after the initial hump, which was a bit of a panic, I was able to get into a steady pace of updating/producing use cases and keep two iterations ahead of the team).

The idea that Agile can create the requirements by putting a user interface in front of the user strikes me as ridiculous for anything more complex than a one screen telephone app.

[Filippo Lippi]

Our Product Owners has been given "the training" and have decided that they have no time for it

[a_unique_person]

Originally Posted by novaphile

Hear hear!

Agile works very well if you have a fully developed set of requirements.
That's one of the reasons why I liked using Agile with RUP.

I'd never been exposed to RUP before, and certainly hadn't used it, and was dropped into a team that had no analysts. I was told: "You need to write use cases for us and stay at least one iteration ahead of the developers."

I gave the team three use cases and the first bit of the supplementary spec in the first round (NB. including class diagrams, requirements met by the use case, basic flow, and the first couple of alternative flows.) and the devs took them away to discuss.

Later that day they came back and said: "This is the best object-oriented design we've ever seen."

I had no idea what an 'object oriented design' was, and had no idea that I'd delivered a 'design' in any form.

The devs showed me where they had grouped collections on the class diagrams (circles around classes) to identify screens required and how elements from the basic and alternative flows defined the controls they needed to expose.

They divvied up the work via Agile/scrum methods, including daily stand-ups, where occasionally the devs would ask me for assistance in fleshing something out, or let me know that there would be an opportunity for me to generate and install a new snapshot so that I could confirm it the use case had been realised or not.

That is the power of a good methodology.

An analyst who has never even seen it before, can be churning out 'designs' and be productive in a week.

(NB. after the initial hump, which was a bit of a panic, I was able to get into a steady pace of updating/producing use cases and keep two iterations ahead of the team).

The idea that Agile can create the requirements by putting a user interface in front of the user strikes me as ridiculous for anything more complex than a one screen telephone app.

That RUP sounds suspiciously like the turn of the century methodologies.

[jeremyp]

Originally Posted by novaphile

Hear hear!

Agile works very well if you have a fully developed set of requirements.
That's one of the reasons why I liked using Agile with RUP.

Every methodology works well with a fully developed set of requirements. Agile recognises that this is not always possible and tries to mitigate the issues that arise when you get the requirements wrong.

I’ve worked on a lot of “Agile” projects but none of them really embraced the philosophy. In fact, it occurs to me that none of them even asked the participants to read the Agile manifesto. You’d think that would be important on an Agile project.

How many people on this thread have read it? How many know that Scrum predates Agile?

[Wudang]

Technically yes Scrum started before the Agile Manifesto was published but the working practices which that described were long in use with things like spiral development etc.
The manifesto just crystallized existing working practices under a single banner.

[jeremyp]

Originally Posted by Wudang

Technically yes Scrum started before the Agile Manifesto was published but the working practices which that described were long in use with things like spiral development etc.
The manifesto just crystallized existing working practices under a single banner.

I've been on a number of SCRUM projects and they all failed to be Agile in various ways. But people think they are "doing Agile" if they have sprints and daily stand ups. Almost nobody understands what Agile even is and I bit maybe one in ten of the people I've worked with on "Agile" projects has read the Agile manifesto.

In fact, I read it again this morning to remind myself before commenting on this thread and I am surprised to find that one or two of the points are actually unworkable in the real world.

[Wudang]

Which ones?

[novaphile]

Originally Posted by jeremyp

Every methodology works well with a fully developed set of requirements. Agile recognises that this is not always possible and tries to mitigate the issues that arise when you get the requirements wrong.

I’ve worked on a lot of “Agile” projects but none of them really embraced the philosophy. In fact, it occurs to me that none of them even asked the participants to read the Agile manifesto. You’d think that would be important on an Agile project.

How many people on this thread have read it? How many know that Scrum predates Agile?

When one of my projects moved to 'Agile' I distributed an introductory article that explains the basic principles and included the manifesto.

The management responded by saying: "We're doing Agile by NOT adhering to anything in the manifesto."

For me the employment history was Waterfall, RAD, Extreme, Scrum, Agile.

Or as my brother often said: "Whatever it is called this week."

[Wudang]

Originally Posted by novaphile

When one of my projects moved to 'Agile' I distributed an introductory article that explains the basic principles and included the manifesto.

The management responded by saying: "We're doing Agile by NOT adhering to anything in the manifesto."

For me the employment history was Waterfall, RAD, Extreme, Scrum, Agile.

Or as my brother often said: "Whatever it is called this week."

That is one of the problems with agile (small a). To me there has to be a certain degree of winging it. Which begs the question of how far you can do that before it stops being "Agile™". For me a key is needing competent software engineers who can work independently and as part of a team, not an assemblage of "coding clerks" who can turn specs into code.

[jeremyp]

Originally Posted by Wudang

That is one of the problems with agile (small a). To me there has to be a certain degree of winging it. Which begs the question of how far you can do that before it stops being "Agile™". For me a key is needing competent software engineers who can work independently and as part of a team, not an assemblage of "coding clerks" who can turn specs into code.

But if you have competent people, you can probably make almost any approach work.

[Wudang]

Originally Posted by jeremyp

But if you have competent people, you can probably make almost any approach work.

No. Read Lister and Demarco "Peopleware". Most technical projects fail for sociological reasons. https://en.m.wikipedia.org/wiki/Peop...ects_and_Teams

[Filippo Lippi]

Just reading the bit in Peopleware where they show the correlation between poor performance in "coding competitions" and lack of work just as we're about to go back to the office where they've increased the number of desks in our bit by 60%.

Motivational? You bet your arse!

[Wudang]

Also worth reading this https://blog.acolyer.org/2015/11/11/...ory-of-devops/

I worked with him on a project and he's really solid in practice as well as theory.

Quote:

The 2015 State of DevOps survey found a 200x (two orders-of-magnitude) gap in lead times between the best and worst performers. Not just a little bit better, or 2x better, or even 20x better, but 200x! And the best performers aren’t just moving faster, they’re also delivering higher quality: 60x fewer deployment failures, and a 168x faster MTTR in the event of a failure.

[novaphile]

Originally Posted by Filippo Lippi

Just reading the bit in Peopleware where they show the correlation between poor performance in "coding competitions" and lack of work just as we're about to go back to the office where they've increased the number of desks in our bit by 60%.

Motivational? You bet your arse!

Yes, in my case, it motivated me to retire.

How they thought that jamming even more desks into an environment that was similar to being trapped in a cage with screaming poo-flinging monkeys*, would make our jobs easier is beyond me...


* And that's just the managers.

[Filippo Lippi]

The "worst performers" had less than 49 square feet, I've just measured, I've got 35, and that's being generous