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

  • pixxelkick@lemmy.world
    2·
    1 year 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.