From the outside, agile might look like a single set of practices. But once you get into it, you see that agile practitioners swear by many different techniques. How do you figure out which are right for you and your team?
Never fear, the Pragmatic Agilist has you covered. Here is a rundown of some pros and cons of various agile frameworks and techniques.
(Except where noted, all definitions come from the Agile Alliance’s Agile Glossary.)
Behavior-driven development (BDD)
Definition
BDD is a practice where members of the team discuss the expected behavior of a system to build a shared understanding of expected functionality. It synthesizes and refines practices stemming from test-driven development (TDD) and acceptance-test-driven development (ATDD).
Why it works
BDD puts the focus on delivering specific functionality rather than the smallest possible unit. This is important because it ensures you are delivering the value the business needs.
How it can disappoint
You’re measuring functionality but not necessarily the quality of the underlying work. Unless you are also doing test-driven development, you run the risk of building the right thing the wrong way—with code that is harder to maintain or extend later. Also, there are fewer software tools available to support BDD.
Distributed agile
Definition
My take: Distributed agile refers to the use of agile team members in different locations, organizations, and even time zones. Rather than in-person meetings, distributed agile teams use instant messaging, email, videoconferencing, and other tools to coordinate their day-to-day work.
Why it works
Distributed agile makes it possible to escape any constraints of space or skills and experience in your immediate location. Modern collaboration tools like Slack, Skype, Teams, and Hangouts have made this possible. You can actually work together on stories without being in the same place and ask questions without disturbing your coworkers’ flow.
Trust, rapport and communication are still essential. That’s why distributed agile works best when you have at least two teammates in any given location, they meet face to face periodically, and understand each other’s language and culture well. It’s helpful to have the whole team within a short flight and similar time zones so you can easily collaborate physically as well as virtually when needed. That team solidarity makes all the difference when you’re trying to crack a tough problem, get business or user feedback, or just onboard new team members.
How it can disappoint
Agile works best when there is fast, frequent communication through standups and other formal and informal collaboration. That’s why traditional agilists believe it only works when teams are 100-percent colocated.
My experience is that you can absolutely achieve this strong collaboration across a time zone or two, but it starts to fall apart when there are significant time-zone, language, and culture gaps. The point of a standup is for the team to communicate and move forward. You can have a decent global status meeting but trying to pick a time where everyone can be effective in a global standup is extremely difficult, if not impossible.
Kanban
Definition
“The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. It also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP), and stop starting and start finishing. The Kanban Method gets its name from the use of kanban: visual signaling mechanisms to control work in progress for intangible work products.”
Why it works
Kanban is good for scenarios such as managing support tickets where you don’t always know when the work is coming in. It’s especially useful when you may have an alternate method of measuring value/productivity, such as defects closed. Kanban also allows you to spend less time in “overhead” activities like daily standup, demos, and retrospectives.
How it can disappoint
Kanban can be difficult for teams new to agile because the process is not clearly defined like it is with other methodologies. There is no demo, so the team doesn’t get feedback from the business about whether they’re delivering the right thing. And because there is no sprint retrospective, improving your process can be difficult. You can easily get stuck in a bad process indefinitely.
Pair programming
Definition
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard, and mouse among the pair). The programmer at the keyboard is usually called the driver; the other, also actively involved in the programming task but focusing more on overall direction is the navigator; it is expected that the programmers swap roles every few minutes or so.
Why it works
Pair programming is designed for working through complex tasks. It’s also great for knowledge transfer when you’re onboarding a new developer. With Pair programming, you improve overall quality.
How it can disappoint
Pair programming can be overkill for routine tasks, such as when a pattern has already been established, or when creating value objects. Having two developers working on these tasks together is probably not the best way to spend the business’s money. Also, some developers are much happier and more productive working on their own. I suggest you let them. I’m an advocate for pair programming, as long as you give your teams some autonomy about when it makes sense and when it doesn’t.
Scrum
Definition
Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience and make the appropriate adjustments.
Why it works
Scrum offers clear definitions of process. This means team members know exactly what’s expected of them. There are lots of checkpoints to make sure you’re continuing to deliver value and not going off the rails. Overall, scrum is a great methodology for product development.
How it can disappoint
Scrum is a struggle when teams only know the processes—“the things we do”—without fully understanding why we do them. For example, a daily standup is supposed to be a quick huddle to provide transparency and uncover roadblocks to move a project forward. But a bad standup can turn into 40-minute status report. It might make the business feel good, but it doesn’t propel the work. Similarly, retrospectives without candid reflection can turn into “pat on the back” sessions instead of opportunities to improve future sprints.
Test-driven development (TDD)
Definition
Test-driven development is a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests), and design (in the form of refactoring).
Why it works
TDD enforces better quality programming. With TDD, you write just enough code to satisfy the test. This results in more modular, leaner code that is not only tested but more extensible and maintainable. TDD also leads to reduced total cost of ownership (TCO). You have fewer defects. You also catch defects earlier in cycle when it costs less to fix.
How it can disappoint
TDD can take four to six months to gain proficiency. During that rampup period, TDD will slow you down. TDD also requires additional upfront investment. But that is eventually offset by lower long-term costs.
While these are some of the most common agile practices, this list is far from exhaustive. The important thing to bear in mind is that agile isn’t a rigid book of rules and regulations. It’s a flexible, iterative approach to software development that’s especially well-suited to businesses striving for a product mindset, with its emphasis on agility, speed to market, and customer experience. Different organizations will get there in different ways, but all of them can benefit from finding a flavor of agile that works for them.