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/
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- 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.)
@ajsadauskas @technology
Funny video. He’s apparently doing real CD and his stakeholders know every day what’s going live. I don’t know how he works in detail, but very likely it’s pretty agile. It’s just not by the (scrum) book.
The authors of the agile manifesto were very experienced software craftsfolk and “just” pudlished their common sense. As the guy in the vid does. If devs communicate anyway, e.g. if you have rotating pair programming, you probably don’t need a daily …
I honestly believe that the people who complain about these aren’t using them properly or work for people who don’t know how to use them properly. People have been using some version of the huddle, standup, or SCRUM meeting for a very long time. Whether it’s useful or wasteful is probably more a question about the people who are using them.
@ajsadauskas @technology I use them mostly to gauge whether folks understand what they are doing and if not to start a side bar after the fact to course correct, early in analysis if possible.
My direct teams do work that is partly exploratory into domains they don’t understand so a 15 min check in to see who needs guidance each day saves pain and money.
I would say other teams adjacent to ours have turned theirs into order giving status updates. I’m no longer welcome at those.
@ajsadauskas @technology oh and they all hate me because their tickets ain’t done till I’m satisfied with the documentation
Working software over comprehensive documentation
I’ve experienced the logical conclusion of this in practice, in a company where the lead dev was then forced to do customer phone support, cause no one else knew how the software actually worked in detail. (This happened in multiple companies btw).
That sounds like taking the guidance to an absurd conclusion. In my org, we have either the product team or support team do acceptance testing, and support team validates the change in production at each release. The documentation isn’t comprehensive, but it is sufficient for all relevant parties to understand how the feature works.
Our documentation consists of:
- original story the developer takes up - must include requirements and designs (if relevant) before work begins, and ideally some additional examples from developers and QA for edge cases
- code-level documentation - comments, commit messages, etc as needed
- user-level documentation - best effort, usually maintained by the product team to help on-board customers
- notes from support - usually common problems and solutions
There’s no comprehensive documentation, but there is sufficient documentation that product team, developers, and support are on the same page. Each team creates whatever documentation they need internally. That means developers don’t waste a ton of time generating screen shots, technical documentation around new functionality, etc, they just create enough to move it along to the next person.
My company goes the opposite way and holds team standup and then a scrum of scrums after with everyone because my manager is fucking brain dead. Fortune 500 btw
Wow… You’d think they’d understand separation of concerns.
I’m a lead dev and I’ve never attended a scrum of scrums. I occasionally attend high level feature planning (POs + project managers), but never scrum of scrums. That nonsense is left to our scrum masters and project managers (I assume, I’ve never been).