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:
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.)
My unpopular opinion: I remember when I was first introduced to #scrum. My first thought was "this is conceptually similar to #xp (extreme programming), but with best practices removed."
Two decades later and my views have evolved considerably, but I still see that projects developed under Scrum often fail, hard, at the technical best practices.
Ich muss grad für eine #Scrum-Schulung morgen den Scrumguide lesen und "Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.“
Meine Entwickler würden mir aufs Dach steigen verständlicherweise.
It baffles me how easy some people are to dismiss techniques and perspectives that are advocated by developers as "something for developers" and thus not for business or product management:
These are all concepts meant to improve delivering the right product and delivering the product right. Thinking it's merely developers doing their thing outside the realm or concern of product management is so detrimental to both.
Systems thinkers: remove the words "simply" and "just" from your vocabulary.
Anyone on the team can tell you about the problems they face. There's no value-add in throwing it back at them with "why don't you simply do things well, instead of poorly?"
If the change you're thinking of was easy to make, it would have already been made! Coming up with a 100% original idea no one's had before is very unlikely.
"There's a commonly held myth that a lack of a time-bound delivery commitment, such as a sprint demonstration, will lead to a lack of focus, laziness, and increasingly long delivery times. There is, in fact, no such evidence from more than a decade of #Kanban usage. The fear is one generated by those who sell #Scrum training and coaching for a living and wish to dissuade adoption of Kanban or customers from switching." (David J. Anderson, 2023 in 'Discovering Kanban', p. 108)
Looking for good articles/resources on facilitating a discussion on balancing a shared feeling of progress with a sense of urgency. #softwaredev#lean#agile#scrum
If Agility is the ability to respond to changes in a meaningful way, a huge part of that consists of the time it takes until this response is in the hands of the customer so that a feedback loop can form.
If that's true, what's the value of Discovery Epics or Stories, Spikes, Dual Track whatever...
I've been building software for over 25 years and I've never seen a team that was underperforming with clear guidance about what they were supposed to be building. The bottleneck is always management; when programmers have their work already cut out, and communicated to them, they ALWAYS get it done.
You know how to figure out how much is in a sprint? Work as fast as you can, then in two weeks see how much you did. What would you have done better if you had estimated the individual stories?
Ok, help me out here creative folks. My software engineering team needs a new name. Must be business appropriate, but funny is encouraged. We are an API team that supports searching for healthcare providers. Any ideas? #scrum#software#creativecoding#comedy
If a #developer fresh out of college still starts their career in a company in a #DevOps or #Agile transformation; if 6 months in they're convinced #Scrum sucks because they were forced to work with centrally misconfigured #Jira; if business still drops yearly roadmaps on scrum teams or "IT" for building them; if those teams are blind to infra concerns; if devops engineers are just ops engineers in isolated ops teams: then what exactly have we been transforming in the last few decades?