@zeeby4825

I remember in my school (we were like 16 at the time) we had an "agile workshop", we had to build a paper plane using agile

We had a buzzer that went off every time we had to do a mock meeting and stuff like that.

After some time everyone just ignored it and kept on building the plane during the mandatory meetings.

Probably a lesson in there

@jessevw932

1 scrum a day will keep productivity away

@JonKern

You can get snow blindness from reflections off of the snow/glaciers. There's more the the glasses than meets the eye.

@GreedoShot

i work for a fortune 50 company and agile is rammed down our throats but what we do is agile in name only. redundant scrum ceremonies, meetings about meetings, and an obsession with jira metrics, we're continuously pestered and micromanaged over arbitrary statistics that have no bearing on the work getting done because it ruined someone's graph. we do quarterly waterfall planning and people freak out when a task we had planned 4-6 months prior "spillsover" into the next quarter. we are a major proponent of the agile industrial complex.

my agile lead recently took a long vacation and for the first time in years i actually began enjoying being at work, it was strange and bizarre and, unfortunately, temporary

@elmersbalm5219

@14:00 there's a good example of when NASA tried to go through the engineering documentation to build the Saturn 5 engines. At that point, most of the engineers were retired and done passed away. The tattoo would be akin to reverse engineering, even with the documentation. In docs, you write down the difficult parts that you encountered. The obvious or the happenstance doesn't get documented but it is crucial for somebody who's skipping all the research that came before the final version.

@michaelm3691

Agile suck because every concept will inevitably get molested until it fits corporate culture. Consultants suck because the customers demand it.

@kipcrossing

Agile as a philosophy ✅
Agile as a methodology ❌

@dankprole7884

Anybody else think the thumbnail was prime?

@alexeiboukirev8357

In many companies Agile is Waterfall with milestones spaced two weeks from each other.

@Muaahaa

Velocity, planning poker and the rest is all Scrum or Kanban stuff. Agile says teams should reflect on how their are working and iterate on their process to get more productive. Then some other people started writing books about "How to do Agile", making up stuff like Scrum.

@TheBswan

My team is the good agile and I can't imagine a better way to work. We choose our own processes. Every other Friday we discuss whether our processes are serving us, whether they can be improved, etc.

We've reduced recurring meetings, crushed our backlog, and our manager regularly expresses gratitude for our ability to manage ourselves. 

Other teams worry about "sprints", quality is eschewed in favor of scrambling to meet arbitrary deadlines, and features don't get delivered on time anyway.

@elitara77

I was working for an Agile consultancy firm. We couldn't even stick to Agile in our own internal work. Agile only added a layer of process complexity, stress, micromanagement and meetings about meetings. I tried raising important questions about us turning more client-centric and actually listening to their needs, but no... we had things in the Kanban board to work on.

@slr150

15:04 I write tests at the module level(not units), all tests  limits their calls to a central facade that sits in front of the module's classes. 

After writing a parser for a DSL.  I told the team that, the best way to learn how this works is to change or comment out code and see which tests fail. You're also free to refactor as long as the facade  remains intact (which means no changes to the tests), if the test suite passes then you have not broken anything.

@jfftck

I have said it before and will say it again, managers have to be outside of the team and it needs to be run by the developers, and QA — if your team has one, and they need to have the developers to buy in to the work and they give the timeline. Once management is dictating that timeline, it isn’t Agile and is just a reimagined Waterfall and it will fail. I worked in a team that did control the process and did meet the our epics multiple times in a row, and the manager said that was the first time he had seen a team do that and that confirmed that the process does work when it’s not management really controlling it.

When the team runs the team, we would cancel stand ups when it didn’t make sense to have them, but retrospectives were always required and was highly encouraged to attend — this would then require actions that must be taken by the next retrospective and did result in improvements in the process. Planning poker ended up being very useful and we had a great time making sure that the requirements were clear and complete during this time, and this had to be clear to everyone.

@CreepyCreedy

I've seen agile work and work VERY well. However, it was only at small startups because we were able to actually be agile. Lots of very close collaboration with everyone. 

Once you go a an existing business, the business processes are somewhat antithetical to agile process. So the business is always trying to push software creation to be more like business process. So the question comes down to who determines process. If you let the business do it then you're not going to be agile.

@franksenkel2715

in mountaineering the glare is substantial especially on glaciers so you use the side panel to block the sun reflection off the ice/snow

@henningerhenningstone691

The international large enterprise I work at introduced both Agile (in the form of SAFe) and "Software Development Process Landscape" at the same time. These processes are so detailed that they even tell us how to write commit messages and how many times in the day to push our code.
Yah, go figure, it's all been massively downhill since that.

@CallousCoder

I remember reading the manifesto and couldn’t help to think: “this is exactly how we worked at the technical department for research and my first software house that I worked for”. 
And we didn’t even have sprints, and sprint planning and standups. Everybody had their project specs and they just worked on it. And if we got stuck or had other ideas we discussed it adhoc. And we decided what to do. We all worked in a part of the system. And only when they needed to integrate we had a little discussion about the interfaces.
And these were mission critical systems even! And nothing could plan these in waterfall. Because nobody knew how much a battery would deteriorate at -45C continuously. We knew it wasn’t great for a battery, and we found to our shock, that the two batteries didn’t even loose capacity at the same rate being encased made it even worse. And another colleague said: “you should also add a massive fan to chill one side more then the other, as those are the conditions on Antarctica. Suddenly we had a massive head scratcher where we had batteries with a 23% potential difference, discharging the other battery as a result. So we had to think to something to keep the batteries at the same temperature. 
In an agile way, we decided to test if we could change batteries to individual cells and alternate the two separate sources’ cells. That way we would have similar temperatures.
Managent doesn’t understand that engineering is basically finding problems, solving those problems. They think it’s a conveyor belt of standard worked out solutions. Or it was, we would’ve bought the product/parts. 

And those two departments I worked at, were ran by engineers 35/40 years experience. They have been there themselves, they know that given enough time a problem will be solved. And their experience knows when you explain a “problem” how complex that problem is. And they would either say: “Cut this wish! Try this! Iterate though!”

@vkc102

you're never safe with SAFe

@Starsky3022

Seeing this first picture I'd LOVE to see Prime do a video in the style of Peter Zeihan's hike videos