By Esther Schindler
Software developers have long been motivated to optimize the process of creating good code. This involves improving your technical skills, such as understanding what you can achieve using a given programming language.
But that’s the easy part.
Any non-trivial software application is also an exercise in project management, which means maximizing the production of the entire development team (“What are we working on? How do we get it done?”) toward meeting the needs of the users whom that software is meant to serve (“Is it done yet?” “That’s not what I wanted!”).
That’s the hard part.
For nearly as long as software has been around, developers have tried to turn software development into an engineering process with known and controllable inputs and outputs—with mixed success. Along the way clever people have come up with a variety of approaches and methodologies hoping to solve that problem, from Agile to Waterfall, from Kanban to Scrum. Each one has its particular strengths and weaknesses, and optimal use cases.
This overview is intended to put some of the most popular methodologies in perspective, and hopefully clear up lingering confusion about exactly what they are and what they’re good for. Think of it as the least you need to know about each one!
Please remember, though, that these distinctions are not always easy to make. The definitions often are surprisingly muddy. To many people, the primary distinction is between Waterfall and Agile approaches, with Kanban, Scrum, and similar methodologies seen as subcategories of Agile, emphasizing iterative development. That’s the approach we’ll take here, but developers have been known to engage in passionate disagreements over just about everything having to do with these issues, starting with whether or not “Agile” should be capitalized!
Waterfall: Development processes flow downstream
Back in 1970—when mainframes walked the earth, when development projects were measured in years rather than months—Winston Royce earned fame by suggesting that software be developed in a linear sequence of processes. The waterfall software lifecycle recommends separate phases for requirements analysis, design, and development, much as water flows downstream and does not return to its source. In other words: First we decide what we need to create, then we design it, then we build it.
Waterfall methodologies work best when the requirements and product definitions are clear and fixed, with no ambiguities. If the technology is well understood, the project is relatively short, and the required know-how is readily available, this may be still be the way to go.
However, waterfall—sometimes called “big design up front”—lacks any way to revise plans along the way. Since working software is not produced until late in the project life cycle, any changes in goals can generate nasty, time-consuming, and expensive surprises. While many large organizations—especially those with strict compliance requirements—remain locked into waterfall methodologies, best practices now largely reject waterfall for complex projects, especially those with risk and uncertainty where requirements are likely to change.
Agile: Development in iterations
It can be easy to get lost in the folderol around Agile-the-buzzword. To grasp the basics, start by reading the original Agile manifesto. More than anything else, Agile is a flexible mindset, accompanied by tools and methods that encourage adaptability, collaboration, and responsiveness.
Agile development can help developers create software that actually does what the users want, and get that software to those users sooner than on a “big design up front” schedule. But Agile needs full involvement from all stakeholders. When business representatives don’t participate, developers build products that fail to meet customer requirements. And when downstream roles are omitted, release schedules slip.
“Agile” is a wide umbrella with many methodologies under its penumbra. These methodologies all share the attitude of being adaptive to change, and instantiating that flexibility using iterative development. Occasionally developers argue that a particular chosen methodology is something other (and better!) than Agile, but we’ll avoid starting any flame wars here.
More than anything else, Agile is a mindset. It’s based on the premise that application development should be a collaborative exercise for creators and users, and that doing so means finalizing a little bit at a time. That way, no matter what the development stage, there’s always a working application in users’ hands—and it just gets more powerful over time.
How teams actually go about delivering on that premise varies, however. Any organization “doing Agile” is apt to use at least one of the methodologies or development practices listed below, and likely several. It’s mix-and-match—savvy organizations tend to use whatever generates the best code.
Extreme Programming
Extreme Programming (XP) was spearheaded by Kent Beck, who in 1999 wrote the book Extreme Programming Explained. Its key tenets include an emphasis on frequent releases with short development cycles; pair programming (more about that in a moment); regular builds and integration tests; rapid and regular feedback; and keeping code simple, creating only the code that is actively needed.
With XP, developers sit down with users or customers who describe, in their own terms, what they want the application to do; functions and features are described in high-level business terms. These user stories are distilled to fit on a single index card, making it easier to predict and track progress towards the stakeholders’ goals.
XP also uses test-driven development (TDD). The automated unit tests are written first, before the code is created, to ensure code coverage and thus better software quality.
Another element of XP—sometimes used by other Agile methodologies as well—is pair programming, where two developers work together to create production-ready code. “Work together” means sitting side-by-side sharing a keyboard. One benefit of pair programming is that code is regularly reviewed by more than one person, which improves quality; another is its inherent sharing of personal and organizational knowledge.
Scrum
Scrum is less about the technical processes of writing and testing code (such as pair programming) than it is about teamwork. Scrum development teams break up a project into short time boxes with clearly defined work requirements, addressed in short time frames. The application’s features—user stories, again—are grouped into batches of deliverable, workable functionality that are created-and-deployed in one- to six-week time frames called sprints. Sprints encompass everything from design, development, testing, and customer validation for those features. By the end of the sprint, the new functionality is ready to go and usually deployed to production.
Another element of Scrum is its daily stand-up or daily Scrum meeting. These short status meetings keep everyone in the loop, as each team member answers three questions: What have I done since yesterday? What am I doing today? Do I have any roadblocks?
Kanban
The Kanban method, built on the idea of a signboard, aims for “just in time” software delivery using a visual process-management system. Its goal is to guide teams in what to produce, when to produce it, and how much to produce. As with other Agile methodologies, the idea is to make small but impactful changes often.
A Kanban board works by visualizing workflow. It can record and track “what needs to be done, by whom, when” so developers and their users can understand where they are today and use change management approaches to evolve from that point. The board (either a physical one or a virtual equivalent; there are several tools available) manages the flow of work through the system towards the overall goal. Kanban boards are helpful in keeping developers focused on finishing a current task before starting a new one.
Scrumban
Scrum and Kanban use time blocks in different ways. Those using Scrum (as least in a pure sense) choose what will be addressed in the next sprint, and lock themselves into that feature set until the work is complete. Kanban lets developers change the items in the queues at any time; the work flows from one story to another, with no set “sprint end.” Originally designed as a transition from Scrum to Kanban, Scrumban is a hybrid of the two approaches that uses Scrum as a way of working and Kanban to view how they work.
Lean Software Development
The idea behind Lean software development comes from a commonly held view of manufacturing processes. The premise is that every process and resource must directly contribute to creating something of value to the customer, and anything else you do is wasteful. Led by Mary and Tom Poppendieck and their book, Lean Software Development: An Agile Toolkit, the Lean software development principles emphasize that developers should only create code that answers a discernable user need. Like “just in time” manufacturing, Lean development suggests you make decisions as late as possible, avoid assumptions, and focus on speed to market. With Lean, developers are encouraged to see the whole—to focus on the entire product experience rather than its pieces.
Lots of other choices
There are plenty of other software development methodologies. We didn’t go into Feature-Driven Development or the Rational Unified Process (RUP), for example, but these are also popular choices.
It’s also important to emphasize that while all of these processes have their gospel, by-the-book versions, in the real world they’re most effective only if you contort them to your team and project’s particular needs.
In fact, if you are looking to switch or upgrade your programming methodologies, it often makes sense to read the books and then start a rote implementation for a few weeks to see how it works. Then once you have some experience using it to address real problems rather than speculative ones, you can begin to strip out things that cause problems or don’t add value while adding new stuff that makes sense for your team’s needs.
About the Author
Since 1992, Esther Schindler has made a living by translating from Geek into English. Find her on Twitter, Facebook, and Google+, where she’s sure to distract you from getting productive work accomplished. View posts by Esther Schindler.
