Software Engineering is about more than just writing code. It is a complex process that has a lot of moving parts. Requirements gathering, planning, testing, deployment and source control management are just a few of the pieces to the software engineering puzzle. So how do we manage all this complexity? Software methodologies come to the rescue.

So what exactly is a software methodology? According to Wikipedia it is “A division of software development work into distinct phases (or stages) containing activities with the intent of better planning and management.” In a more general sense a software methodology is an organized way of building software. It becomes essential on projects where there is more than one person involved.

So why do we need a methodology? It is actually quite useful. A methodology helps us:

• Coordinate work among team members
• Better estimate cost and duration of a project
• Improve the quality of the product
• Facilitate efficiency

These are good things, right? Right.  So let’s dig in and learn about some of the more well known software methodologies.

Waterfall

Waterfall is one of the oldest methodologies. It was first described way back in 1956. In the Waterfall methodology, you move to a phase only when its preceding phase is reviewed and verified. It looks something like this:

As you can see, each phase is completed and then “falls” into the next phase, hence the name. While this methodology can work, it does not easily adapt to change. In this type of project, the software being built can sometimes become obsolete before it is completed!

Rapid Application Development (RAD)

During the late 1980’s and early 1990’s, a lot of new ideas began to surface surrounding software development and software methodologies. Many new methodologies emerged during this time. One of them was Rapid Application Prototyping, or RAD for short. RAD favors iterative development. Requirements are verified via the creation of “rapid prototypes”, which can easily be thrown away if they do not suit the business need. RAD is all about fulfilling the business need. This facilitates fast development of a high quality system at a low cost.

RAD also promotes use of software tools such as Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools and Database Management Systems (DBMS). The idea here is to use software to help build software. It was very innovative at the time, and a common practice today.

Agile

While I often hear “We use Agile” when talking to people about what methodology they use, Agile is not a software methodology. Agile actually stems from the Agile Manifesto, which was created by a group of software developers back in 2001 that were looking for lightweight methods to develop software. The manifesto is stated thusly:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There has been a lot of evolution and definition since those early days, and many software methodologies have matured using these guiding principles. I’ll briefly dig into a couple of them here: Scrum and Kanban.

Scrum

Scrum is probably the most popular of the Agile methodologies. It was created in the mid-nineties by Ken Schwaber and Jeff Sutherland. In Scrum, a cross-functional team works together to build software; there are no specialists and theoretically anyone on the team can take on any task.

There are three defined roles in Scrum: Product Owner, Scrummaster and Team Member. The Product Owner is responsible for gathering all requirements from various stakeholders, then organizing and prioritizing them in a product backlog. The backlog consists of user stories, which map to the various software requirements. The Product Owner is the authoritative source to answer questions about items in the backlog for the team. They are a customer proxy, so the team is given clear direction and not confused by mixed messages.

The ScrumMaster is responsible for making sure a Scrum team properly executes the practices of Scrum. The ScrumMaster guides the team to perform at their highest level. This involves removing any impediments to progress (called “blockers”), facilitating meetings, and working with the product owner to ensure the product backlog is in good shape.

A Scrum Team is a cross-functional group that takes on the development, testing and delivery of working software. This team drives the project forward. They are self-organizing and choose the work to be performed from the highest priority items in the product backlog. The optimal size for a Scrum Team is 5-7 people, although smaller projects can work well with smaller teams.

In Scrum, work is performed in time-boxed iterations, or Sprints. Traditional Scrum specifies an iteration length of 30 days, but many projects these days use an iteration length of one or two weeks. For each iteration, There are four key meetings (also referred to as ceremonies): Sprint Planning, Daily Stand-up, Sprint Review and Sprint Retrospective.

Sprint Planning sets up the team for a successful sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each  backlog item with the development team, and the group collectively estimates the effort involved for each item. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.

The Daily Stand-up (also referred to as a “Scrum”) is a meeting to quickly inform everyone of what’s going on across the team. It’s typically run by the Scrummaster. Each team member answers the following questions:

• What did you complete since last time we met?
• What will you work on today?
• Are you blocked by anything?

The Product Owner attends this meeting, but does not speak. Information gleaned from this meeting often leads to conversations that occur after the Scrum is over.

At the end of each Sprint, working software is presented to the Product Owner and other stakeholders in the Sprint Review. The team also reviews the total work accomplished for the Sprint to help them establish a Sprint Velocity. The velocity help the team when selecting the amount of work for future Sprints.

Finally, there is a Sprint Retrospective at the end of each Sprint. This is an opportunity to reflect on how the Sprint went and look for ways to improve the process. The Product Owner, Scrummaster and all team members participate. The are three questions to answer:

• What went well this Sprint?
• What went poorly?
• What should we do differently?

From the retrospective emerges a list of action items that can be applied to the next Sprint to (hopefully) make it run better.

There is a lot more to Scrum, and there are many books written on the subject. If you want to learn more, a good place to start is Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

Kanban

Kanban for software development has been adapted from the Toyota Production System. It leverages Lean principles and just-in-time delivery, which are manifested in a continuous flow of work. One of the key concepts in Kanban is to limit the amount of work in progress in any particular phase. This means that if we are limiting 3 work items to be in the test phase at any one time and we reach that limit, team members must rally to reduce the number of items in the test phase below 3 before work can continue in other phases (coding, code review, etc.).

Kanban is all about visualization of the workflow. Kanban Boards are used to show what work items are in what phase of development (Scrum uses a similar “Scrum Task Board”). This helps to quickly identify bottlenecks in the flow so they can be quickly removed by team members. A tool to measure Kanban performance is the Cumulative Flow Diagram. Each day, for each column in the Kanban Board, it tracks how many tasks are in each part of the workflow. This produces a mountain-like looking chart, which gives insight into the process, showing past performance and allowing the ability to predict future results. Here’s an example of a Cumulative Flow Diagram:

The key metric for Kanban is Cycle Time. Cycle Time is the amount of time it takes from the time a work item is started until it is delivered to the customer. The goal in Kanban is to reduce Cycle Time. This ties into the concept of continuous delivery, which allows for the rapid, reliable and repeated delivery of new features and bug fixes at low risk and with minimal overhead.

This just scratches the surface of Kanban. To learn more, check out the book Kanban: Successful Evolutionary Change for Your Technology Business by David Anderson.

Conclusion

Software methodologies help us build software products in a more efficient manner. These methodologies are constantly being improved and iterated upon. While there is no “right” software methodology, Agile methodologies are very useful for software projects, particularly when requirements are in flux. Here at Grio, we use a modified version of Scrum to run our software projects.

Do you use a particular methodology? Do you have a favorite? Let us know your thoughts in the comments.