this post was submitted on 10 Dec 2023
86 points (93.9% liked)

Technology

34987 readers
406 users here now

This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.


Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.


Rules:

1: All Lemmy rules apply

2: Do not post low effort posts

3: NEVER post naziped*gore stuff

4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.

5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)

6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist

7: crypto related posts, unless essential, are disallowed

founded 5 years ago
MODERATORS
 

Are agile scrums an outdated idea?

Here's a video on YouTube making the case for why agile was an innovative methodology when it was first introduced 20 years ago.

However, he argues these days, daily scrums are a waste of time, and many organisations would be better off automating their reporting processes, giving teams more autonomy, and letting people get on with their work:

https://youtu.be/KJ5u_Kui1sU?si=M_VLET7v0wCP4gHq

A few of my thoughts.

First, it's worth noting that many organisations that claim to be "agile" aren't, and many that claim to use agile processes don't.

Just as a refresher, here's the key values and principles from the agile manifesto: http://agilemanifesto.org/

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

* Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
* Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
* Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
* Business people and developers must work together daily throughout the project.
* Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
* The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
* Working software is the primary measure of progress.
* Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
* Continuous attention to technical excellence and good design enhances agility.
* Simplicity--the art of maximizing the amount of work not done--is essential.
* The best architectures, requirements, and designs emerge from self-organizing teams.
* At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Your workplace isn't agile if your team is micromanaged from above; if you have a kanban board filled with planning, documentation, and reporting tasks; if your organisation is driven by processes and procedures; if you don't have autonomous cross-functional teams.

Yet in many "agile" organisations, I've noticed that the basic principles of agile are ignored, and what you have is micromanagement through scrums and kanban boards.

And especially outside software development teams, agile tends to just be a hollow buzzword. (I once met a manager at a conference who talked up how agile his business was, and didn't believe me when I said agile was originally a software development methodology โ€” one he revealed he wasn't following the principles of.)

#agile @technology #technology #scrum #tech #Dev

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 2 points 11 months ago

The goal of the sprint meeting is very straightforward:

  1. Everyone gets informed what everyone else got done yesterday, so they know where people are at
  2. Everyone gets informed what everyone else is doing today, same reason as above.
  3. Anyone who is currently blocked on a task can quickly ask for assistance, and with everyone in the meeting someone can jump on that or direct them to a person who can help
  4. Anyone who doesnt have anything to do can ask if anyone else needs help with anything

Its an all hands meeting meant for everyone to get their morning baseline "what is everyone else doing" understanding.

It's also extremely critical for company culture, morning standups keep individuals anchored to "who is my team" and "what do they do", so they understand when asked who so-and-so is and what they do here.

Without the standup meeting, you typically get situations where everyone is operating in their own glass boxes and they start to disconnect from the team. They have no idea what other people are working on, they have no idea what other people even do for the team, etc.

You dont want a situation where your developers have no idea what your QA team is busy with, and no one knows what the UX team is currently tackling. Thats how you get a lot of divergence and disconnect.

The standup helps keep everyone not only aligned, but also knowledgeable of whats coming up next.

Your devs hear about what the UX team is finishing up so they know that in a couple days thats going to be next on their plate, and your QA knows what the devs are finishing up so they know whats next to focus on.

You can consider the morning standup to be your cross pollination meeting for infoshare.