- Agile: This is a catch all term for a process intended to be responsive to customer needs. There are a number of processes that fall under "agile," including the "we make it our own." This is a cue to dig a little deeper and understand what that means.
- SCRUM: This is a project management process that describes how to interact with other departments -- not how to engage in the act of writing software. SCRUM is built on a few concepts, most notably the idea that the team signs up for a set of work and commits to finishing that work in a certain time period. The team's effectiveness is measured by how reliably it meets its commitment. Any slowdown is an indicator of a problem, whether a technical debt, training need, buggy software, etc. Many companies that claim to be using SCRUM are actually using "SCRUM, but...." As in, "It's SCRUM, but we're doing X differently."
- Kanban: This is a process that is more popular in blog posts than in actual use. The idea is to limit work in progress. If there are already X things in progress, then nothing else can be started until something else is finished. The problem with Kanban is that it doesn't help to time or estimate larger efforts (e.g., an entire release), so it's a pain for project management. It also doesn't work well on teams of specialists.
- Extreme Programming: This is a software development process that describes how to engage in writing software. It's often used with SCRUM or Kanban as a project management process. It involves an emphasis on making heavy use of refactoring, pairing, mentoring and test-driven development.
- Waterfall: This is often referred to with derision, and is considered unpopular though it's still common. Like Agile, waterfall encompasses a variety of processes. These are characterized by a separation of specialties, e.g., the design phase, implementation phase and testing phase.
Terms Software Engineers Need to Communicate Clearly
We're software engineers. It's rumored that we write code, test the product and debug problems, as well as draw boxes and arrows on whiteboards until we have an architecture we're happy with. In the end, almost everything we do is about producing awesomeness and solving interesting problems. Except when it's not, which is much of the time. As most of us discovered in our first job, we spend countless hours doing other stuff. We go to meetings. We report progress and at some point, we talk to nearly everyone dealing with the creation, development and sale of the product. When all is said and done, though, we're still communicating about the actual work. In a bid to make things as easy, reliable and efficient as possible, this work within the work is linguistically codified in the software development process. Here are a few of the more standardized terms that are most frequently employed. Use them wisely:
