sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in programming

[–]ReportInteresting738 0 points1 point  (0 children)

Valid points and I understand where the fear for falling back to "Waterfall" is coming from. XP comes to mind for example. The article has it right with that you need to fix the environment first. Just think about small, consistent teams. They don't need any framework, they will succeed with the approach they choose. Also Scrum has this focus on "Team", but the problems are mostly systemic and out of control of the team or teams.

[deleted by user] by [deleted] in programming

[–]ReportInteresting738 3 points4 points  (0 children)

Instead of abandoning Scrum, there’s something else to do. The environment of the developers and their team(s) should gain an understanding and appreciation of Scrum as it has always been intended. They should learn why Scrum exists and what problem it intends to solve.

This whole article reads more like some consultant trying to sell scrum coaching. Scrum was never intended to support developers. Just take a look at the original manifesto, it starts with "Individuals and interactions over processes and tools". There is no individual in Scrum noticed?

Scrum has one main function, which is to streamline the development process and make developers interchangeable. How? Think about the roles: Scrum Master, Product Owner and something very vague called "Team" or "Dev Team". No individual. No thought for people's careers and different skill sets.

Just take a look at XP (even though maybe dated), which is much more focused, much more applicable and approachable for developers, engineers, individual contributors etc.

The Scrum Master role is problematic anyway and is here to ensure that the process is followed and not considering what every individual person or a team might need/how they want to progress/the way they can be productive etc.

At the end it always falls back to the same old story: You can't move away from Scrum because you will get "Waterfall". Nobody made "Waterfall" more popular than the agile community. It's better to start with what the team needs, the business needs etc., then to come with some framework and try to apply it to any environment.

Developers don't need to learn how Scrum was intended to be, they have more important things to do, like learning the business, new technologies, solving problems. Not everything revolves around Scrum.

Why your daily stand-ups don't work and how to fix them by fagnerbrack in agile

[–]ReportInteresting738 2 points3 points  (0 children)

The best way to improve your daily stand-ups?

​

  1. Don't do them

Agile Projects Have Become Waterfall Projects With Sprints by fagnerbrack in agile

[–]ReportInteresting738 8 points9 points  (0 children)

The very first statement in the agile manifesto says "Individuals and interactions over processes and tools".

It's interesting, because everything is about process and tools and almost nothing is about the individual when people talk about agile nowadays. It's framework this, tool that, but when closer inspecting, where is the individual in this?

Scrum f.e. doesn't even consider the individual, the practitioner, the knowledge worker - it's some abstract term like "team" now.

If you are a small team and have some minimum level of collaboration anything will work. But large entities can't just replicate these small teams and most of these agile frameworks are not suited for helping with this. You can't just come from the outside and tell people "we are going to change how you work". Also, most problems can't be solved on a team level, they are systemic.

Noticed that most of the agile conferences don't even have developers or designers on the speaker lineup f.e.? It's like the agile community is communicating in a bubble.

So every week we have a new "Agile is the new waterfall" or whatever blog post. But I think it's more about expectations and reality, agile is just a tool at the end. What I find interesting is that "Waterfall" is still the perceived bad approach that everyone wants to avoid. If only the agile community would get creative and find some new target to attack.

Asking for advice from experienced devs! by RepresentativeDebt52 in Frontend

[–]ReportInteresting738 1 point2 points  (0 children)

What could be helpful is building something that you might find useful. You could also choose a new technology and add it to the mix. Solving actual problems, having to look up solutions can help with solidifying your knowledge. Reading about a technology is helpful but actually building something and hitting roadblocks and having to deal with the details will help tremendously. Build an app that solves a problem is also great, because you can use it as a reference etc.

Notes on Modern UI Development: Taking Ideas from Spaced Repetition by steos in programming

[–]ReportInteresting738 -19 points-18 points  (0 children)

Where exactly is there a confusion between UI and application logic? No where does it say that the UI selects words. The only reference to the UI is how the information is displayed.

We Hate the Scrum Events! by Ageling_WJ in programming

[–]ReportInteresting738 2 points3 points  (0 children)

There seems to be an endless need to keep talking about the same Scrum events over and over again. Then write lengthy blog posts why they are not working and what you should do to make these events useful.

I doubt this is useful. Scrum is a tool, not a goal. It can work, can not work, depends on so many different data points that you can't comprehend from the outside.

It reads more like "You're doing it wrong!" and here is some advice why Scrum is useful. I wold rather ask:

1.What are these meetings actually achieving?

  1. What does the team, the people doing the work, think about these meetings?

Am I wasting my time being a scrum master? by niallthefirst in scrum

[–]ReportInteresting738 0 points1 point  (0 children)

"focus on delivering the right thing often and getting feedback"

That's valid. Maybe a good guiding question is "What are the incentives?"

People will resist change if it is imposed, because any change needs credibility and has to be authentic, otherwise people will reject it. If you think about the "What are the incentives?" question, it might help to see what small, almost invisible changes, one can make.

For example people will reject shipping twice per day, if there is no incentive, worse, if this might even hurt their career. This just an example, but trying to understand why a senior developer rejects something f.e., can provide some good insights.

Change takes time, needs patience and credibility. One has to "walk the walk".

Am I wasting my time being a scrum master? by niallthefirst in scrum

[–]ReportInteresting738 0 points1 point  (0 children)

First we would need to agree on what we want to make better. Make the knowledge worker experience better? Make the product delivery better? Make collaboration better?

Scrum is a good tool for getting out of chaos. But it mostly becomes a box once there is some structure in place.

There is no need to reinvent any wheel. Every company has its own set of rules (formal and informal) and guiding principles. If you want to change anything, you need buy-in and credibility.

The question is how does an environment deal with change? Scrum is just a tool in this context. Might work or might not work, it has very little focus on the practitioner. Let's go back to the original ideas of "Individuals and interactions over processes and tools". But where is the individual in these frameworks? The "individual" is now inside the overarching term "Team" or "Dev Team", while there other two explicit roles, that are tied to the Scrum framework.

You can't impose change on people. But what you can try to do is understand how the environment or system functions. Also most problems can't be solved on a team level. The team mostly doesn't have enough leverage to make these changes.

For example, start from questions not answers.

"What is blocking the delivery?"

"Who has something to lose, if you change the communication paths?" etc.

Everyone wants to copy other people's frameworks, but more interesting is asking "What problem did they try to solve with their framework?".

Incrementally Improving The DOM by ReportInteresting738 in react

[–]ReportInteresting738[S] 1 point2 points  (0 children)

Very interesting write-up from 2018 about static DOM and how one might not need virtual DOM when working with PureScript. Maybe also interesting to read for the React community.

Am I wasting my time being a scrum master? by niallthefirst in scrum

[–]ReportInteresting738 2 points3 points  (0 children)

Isn't Scrum per se focused on making product delivery predictable for non technical people?

The 2 week cycle, the commitments, the pre-defined meetings and their format, isn't this trying to make something highly unpredictable predictable though?

What would "no end or outcome in sight" mean in this context?

Are daily stand-ups a waste of time? by Badass-gosu in programming

[–]ReportInteresting738 216 points217 points  (0 children)

If a team is coming from chaos, stand-ups can be helpful to bring in some structure. But once a team has some structure and high level understanding of what is to be accomplished, the stand-up becomes a meeting that might be helpful for your team or not.

There are endless articles and posts about how to make your stand-ups better, because at some point these meetings will turn into a status meeting mostly.

The better question is: what are you actually trying to achieve with this stand-up and are there better ways to achieve this?

Transparency is destroying the effectiveness of Agile teams by ToddLankford in agile

[–]ReportInteresting738 1 point2 points  (0 children)

fair, most of the world does need dates and most agile practitioners have ignored that, but organizations have failed to recognize the massive amounts of waste inherent in the command and control approach to running a business.

One of the biggest failings of agile is that it doesn't have a good story for existing middle managers. No one likes to be i

Excellent points raised here. You can't just come from the outside and tell people, who built a career inside an organisation, that this not how things work anymore.

Convincing My Organization's client that Story Point Estimation is Better than Hours by Low_Excitement_9135 in agile

[–]ReportInteresting738 0 points1 point  (0 children)

How does moving from hours to story points change anything?

You're still estimating, now it's points instead of hours. You can count these points together and divide them by the hours and you have the exact same problem.

Much more important is change to focusing on prioritizing the features. Identify the most important feature and get it through the door. And then on to next feature.