Agility doesn't come from Scrum. Scrum provides an empirical framework of short cycles and frequent course corrections, and a lightweight management process that can respond to change, and embrace change.
Agility comes from the team embracing the values and principles of the Manifesto for Agile Software Development, and adopting agile engineering practices. (Doesn't have to be just the team. Could be the entire department. Or the entire division. Or the entire company.)
Developing features fast while sacrificing quality, stability and maintainability is a surefire recipe to be not agile. As you saw in those bunch of teams that suffered. :-(
For all the reasons Robert Martin pointed out in his book Clean Code.
To be agile requires the team to internalize agile engineering practices, as enumerated by Andrew Fuqua. Not all of them have to be adopted, but a good scrum master should be encouraging the development team to consider suitable ones to incorporate as a development team technical decision.
Even without agile, Scrum still provides a lot of value.
And agile, without Scrum, provides a lot of value.
Genuine Scrum and genuine agile together are a win-win.
But there are a lot of pitfalls that need to be avoided with Scrum. Which is why I say "Scrum is simple, but it ain't easy".
By far the biggest pitfall I've seen is management telling the team do Scrum, without management understanding that Scrum means management's own role and responsibility has to change to make Scrum work. Management needs to pony up a full-time scrum master as a facilitator and manager of the process; a servant-leader. Management needs to empower the team to be able to make technical decisions (which is a hard change for a command-and-control organization to successfully make that transition).
Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
The only thing I wanted to point out: Scrum provides sort of a framework that is required for getting good work done in an agile environment in a larger style.
Scrum itself doesn't make a team agile.
But at some point, there's always a need to get things balanced. In most cases there's a load of different stakeholders with conflicting goals and requirements. In most cases, too, there are business requirements concerning available development budgets, release cycles and the like. In most cases there will be a whole load of non-functional requirements and expectations. Too, in most cases there will be "planned" development vs. fixing "bugs" (ranging from actual show stoppers that bring your system down to that one button one special user wants to be green instead of blue).
I dare to say in most "real-world" organizations (larger teams, more than one stakeholder, ...), no matter how well a team embraces agile principles, you still will need some sort of process to resolve these issues - to figure out, in example, how to work with budget limitations or release deadlines in a sane way, or how to resolve conflicting goals by getting your things prioritized.
This is not "just" about agility, it's mostly also about getting a certain structure into things as agility, on the other side, also won't work if the whole team randomly starts talking to random stakeholders to get an idea of what to do next, or if stakeholders randomly provide some team members with whichever feature request they see as important that moment.
Scrum, with its roles and processes, provides a framework to answer those questions. And that's what I initially meant: If you have a team that commits to and embraces agile principles and values, Scrum helps you getting this into your whole environment in a meaningful way without wanting "agile" and ending up in chaos.
I think Scrum has a lot of value. (With or without agile.)
I think agile has a lot of value. (With or without Scrum.)
I think Scrum + agile together is a big win-win for both.
I think there are some dangerous pitfalls to Scrum that people ought to be aware of, so they can avoid those pitfalls. Because those pitfalls can give Scrum a bad name, and I don't think that's fair to Scrum.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agility doesn't come from Scrum. Scrum provides an empirical framework of short cycles and frequent course corrections, and a lightweight management process that can respond to change, and embrace change.
Agility comes from the team embracing the values and principles of the Manifesto for Agile Software Development, and adopting agile engineering practices. (Doesn't have to be just the team. Could be the entire department. Or the entire division. Or the entire company.)
Developing features fast while sacrificing quality, stability and maintainability is a surefire recipe to be not agile. As you saw in those bunch of teams that suffered. :-(
For all the reasons Robert Martin pointed out in his book Clean Code.
To be agile requires the team to internalize agile engineering practices, as enumerated by Andrew Fuqua. Not all of them have to be adopted, but a good scrum master should be encouraging the development team to consider suitable ones to incorporate as a development team technical decision.
Even without agile, Scrum still provides a lot of value.
And agile, without Scrum, provides a lot of value.
Genuine Scrum and genuine agile together are a win-win.
But there are a lot of pitfalls that need to be avoided with Scrum. Which is why I say "Scrum is simple, but it ain't easy".
By far the biggest pitfall I've seen is management telling the team do Scrum, without management understanding that Scrum means management's own role and responsibility has to change to make Scrum work. Management needs to pony up a full-time scrum master as a facilitator and manager of the process; a servant-leader. Management needs to empower the team to be able to make technical decisions (which is a hard change for a command-and-control organization to successfully make that transition).
Yes. I don't disagree here.
The only thing I wanted to point out: Scrum provides sort of a framework that is required for getting good work done in an agile environment in a larger style.
Scrum itself doesn't make a team agile.
But at some point, there's always a need to get things balanced. In most cases there's a load of different stakeholders with conflicting goals and requirements. In most cases, too, there are business requirements concerning available development budgets, release cycles and the like. In most cases there will be a whole load of non-functional requirements and expectations. Too, in most cases there will be "planned" development vs. fixing "bugs" (ranging from actual show stoppers that bring your system down to that one button one special user wants to be green instead of blue).
I dare to say in most "real-world" organizations (larger teams, more than one stakeholder, ...), no matter how well a team embraces agile principles, you still will need some sort of process to resolve these issues - to figure out, in example, how to work with budget limitations or release deadlines in a sane way, or how to resolve conflicting goals by getting your things prioritized.
This is not "just" about agility, it's mostly also about getting a certain structure into things as agility, on the other side, also won't work if the whole team randomly starts talking to random stakeholders to get an idea of what to do next, or if stakeholders randomly provide some team members with whichever feature request they see as important that moment.
Scrum, with its roles and processes, provides a framework to answer those questions. And that's what I initially meant: If you have a team that commits to and embraces agile principles and values, Scrum helps you getting this into your whole environment in a meaningful way without wanting "agile" and ending up in chaos.
Then we're on the same page. :-)
I think Scrum has a lot of value. (With or without agile.)
I think agile has a lot of value. (With or without Scrum.)
I think Scrum + agile together is a big win-win for both.
I think there are some dangerous pitfalls to Scrum that people ought to be aware of, so they can avoid those pitfalls. Because those pitfalls can give Scrum a bad name, and I don't think that's fair to Scrum.