There seems to be wide acceptance that Agile development methodologies are more effective than either the chaotic or Waterfall methods. Even the guy that first described Waterfall, Winston W. Royce, described it as "risky and invites failure" because of the absence of iteration. If only people had read that far.
Scrum is an iterative methodology that importantly includes an element of continuous improvement by way of the Retrospective. There's a wide variety of on-line training around scrum, the roles that people play and the ceremonies, but what of the culture? How does embracing Scrum change a development team and the wider organisation.
The changes to the development team are thorough. The expectation is that each feature will initially be delivered to an MVP, and that over time, as the product matures, some requirements will evolve while others will emerge. To be agile, you have to have CI, and you have to have tests. You rely on your tests because as requirements evolve, you will have to change the code that you wrote yesterday. In fact if it's code you wrote yesterday, that's easy. What you need to worry about is changing code that someone else wrote 6 months ago. If you have good test coverage, you can make changes with confidence, if you don't you're in trouble and the chances that you'll introduce a bug or break a feature that was previously working become sky high. Teams that are agile write code that is easy to read, giving the next developer confidence that they know what's going on, and teams that are agile maintain high test coverage to prevent regression.
If you don't read your code to yourself and fix up the naming so that it's clear and reads well, you're not being agile.
It takes discipline to reject stories that aren't correctly specified, it takes discipline to write just the code that implements and tests the User Story. It takes discipline to write a solution that is no more complex than the problem it's solving.
Outside of the Development team, probably the largest change is with product, but I'm not talking about their day-to-day behaviors,the JIRA gardening, the acceptance criteria. those things are doing agile. Being agile is aligning the developers with product. Making a product team that is funded on the understanding that they'll create the right product for the market because the product-oriented members of the team have an innate understanding of the customer's needs. Delivering a long lived product means long lived delivery, which brings us back full circle to code craftsmanship because a team that doesn't invest in refactoring, naming, test coverage, or design that supports change without fluff is not going to deliver at a sustainable, constant rate through the life of the product. As a matter of fact, I'd love to hear from Product people about this. If you were given the choice would you rather development teams delivered code without tests, craftsmanship or good design, so that they can deliver quickly at the start of a product, in the knowledge that delivery will inevitably slow down? Or would you rather have code delivered that was crafted well, was well tested, and supported a constant speed of delivery throughout the (5? 10? year) life of the product?
Ceremonies, JIRA tickets and scrum roles don't make you Agile. That's doing it, but it's not getting it.
Being agile means a having a real relationship with your customers, a desire to provide a solution that addresses their real requirements, and aligning your business and funding around products and the cross-functional teams that deliver those products. It means changing the way you deliver code so that you can support a product with a 5 or 10 year lifespan without getting into such a mess that at some point someone cries "REWRITE!".
