Since the early days of the Agile Manifesto, published in 2001, the number of Agile practices that fit with its core principles has increased dramatically.
If Agile territory had a subway, that would be its map.
Some practices, like continuous delivery and pair programming, have been around even since before the manifesto was released. Others, like user stories, kanban boards, and retrospectives, to name a few, became popular with the widespread expansion of Scrum, DevOps, and Kanban frameworks in the late 2000s.
Better yet, new practices are being developed to this day either by combining the old ones (ScrumBan, Water-Scrum-fall) or taking some known practices to the extreme. For example, test-first development approach was used originally in 1960’s NASA project “Mercury” and was taken to the extreme in, well, extreme programming (XP) methodology.
With so many practices available, the question naturally arises: How do we combine them effectively?
Here are a few tips.
Starting from scratch
Popular Agile methodologies like Scrum, Kanban, and Extreme Programming ease the transition into the Agile mindset of work. They are themselves, essentially, a combination of different Agile practices. The only difference is that these combinations were thoroughly tested and stood the test of time.
The main advantage behind popular Agile frameworks is that they are comprehensively documented. Scrum, for example, is such an established methodology that it has its own certification program. Since 2001, more than 750,000 scrum masters were certified by one of the biggest Agile communities, Scrum Alliance.
Many blogs and online communities share their insight and case studies of how they applied Scrum methodology to their work processes and there’s little to no chance you won’t be able to find working environments similar to yours.
Adhering to popular Agile frameworks enables you to use the wisdom of thousands of teams and to adopt thoroughly tested and effective combinations of Agile practices.
However, adhering to a well-documented methodology is just a start.
What if at some you point you were to decide that using Scrum in its out-of-box configuration is not enough for you and your company? Congratulations, you are now part of 78% of teams that combine Scrum with other practices. Don’t, however, keep stacking new exciting practices on top of each other expecting magic to happen. Agile is about flexibility, but it’s not about chaos. In order to keep things in order, you need to establish core practices.
Agile is about flexibility, but too much flexibility spawns chaos.
Simply put, core practices are what drives your team forward. Pair programming can be an excellent software development practice with benefits such as team-building, expertise exchange, and improved communication. However, pair programming doesn’t work for everyone.
Don’t be afraid to drop practices that don’t work in your environment. On the other hand, don’t easily drop practices that are part of larger Agile frameworks, e.g.retrospectives in Scrum. I’ve seen many discussions on whether retrospectives are important and I’ve been on teams that don’t use them at all to “save” some time. Often the opposite happens and the time is lost trying to fix mistakes that otherwise could have been prevented. The core practices of established frameworks are there for a reason and you better think twice before dropping them.
Always thoroughly test the practices you add with your core practices. Sometimes they may contradict each other, e.g. like test-driven development and feature-driven development processes. While the latter stands for delivering tangible working software repeatedly, the former presses that this software should comply with a number of mandatory tests before the release, even though it may be somewhat usable at this point.
You can also find case studies and articles about a combination of different practices, e.g. Scrumban. I don’t, however, believe they are documented well enough and should be taken more for inspiration than a carved in stone follow-through guide.
If you want to add certain practices to your existing workflow, first ask yourself “Why?”. Are you not satisfied with an existing framework or are hyped up about something that new approach offers? There’s nothing wrong with trying new things, just don’t become a hostage of a “Magic Pill” mindset.
Back to the roots
It’s true that there can’t be one way of work that would fit all the teams in the world. Every industry has its set of challenges. Even within the same industry, a team of five people may operate completely differently than the team of 15.
Eventually, your team will accumulate a number of different agile practices and this combination will likely be unique because of your unique working environment. There will be no guides written for you to check whether you are doing things right and not building Frankenstein’s monster.
If that’s the case, there’s one thing you can always come back to – the root of Agile, its manifesto:
No matter what the combination of practices you accumulated, if the resulting work process contradicts with Agile values, it’s not Agile anymore. Usually, the practices are not to blame though, it’s their interpretation.
So try out new practices and always improve your working processes, but don’t forget the basics. It’s about the mindset, not tools.
The Agile world is changing rapidly. Some practices become more relevant as trends change. For example, user testing is often a top priority these days and everyone is obsessed with creating the ultimate user experience in their products. I won’t be surprised to see new methodologies that put user satisfaction as a central metric for all working processes in the company. And I mean metric, like a number, not some vague company slogan “Clients first”.
Yet, no matter how many trends there are in the future waiting for us, one is clear: the Agile manifesto has stood the test of time, enabling us to freely combine a plethora of practices into a unified working process as long as we follow its core principles.