By Earl Soukup

Agile methods are considered to be a light form of project management because there are fewer and less complex prescribed practices than those in traditional project management. The “Project Management Body of Knowledge” (PMBOK) is often used as the master guide for managing a traditional project. In fact, when adapted properly, the PMBOK can be used to manage a project using any method, but that is a discussion for another time.

Sometimes people ask, “Which Agile method is the best?” People have a tendency to want the “best” of something. It is a valid question, and it has a clear and emphatic answer: “It all depends.” It all depends upon the nature of the project, the nature of management, the nature of the customer, the nature of the corporate culture, and the natures of the team members assigned to the project. It is that easy.

“The 10th Annual State of Agile Report” (the Report) is a survey that was conducted by VersionOne during CY 2015. According to the Report, the most common methods for implementing Agile are depicted in the following diagram, “Figure 1. Survey Results.”

The top five methods are Scrum[1], Scrum/XP Hybrid[2], Custom Hybrid, Scrumban[3], and Kanban[4]. These five methods constitute 88 percent of all the methods reported as being used. Each of the remaining methods is used by 3 percent or less of those surveyed. A beginner or intermediate user should follow the examples of others and use one of the preferred methods. A usage rate of 3 percent or less is deemed to be too low to warrant consideration by a beginner. Even 5 percent, 7 percent, or 8 percent may be rather low, but their inclusion brings the total domain being analyzed to 88 percent of the total domain of respondents. The diagram emphasizes the relative importance of each method.

Methods two through five total 30 percent of the methods used, which is slightly over half of the Scrum method. Possibly the opinions of many people, teams, and customers are sufficient for making a decision without reading further, but for those analytical thinkers and explorers, let’s consider further.

In many respects Scrum is easier to learn and execute than the other four methods, since two of them are hybrids that require some experience and the Scrumban method requires the blending of two methods (Scrum and Kanban).

Though Kanban is the fifth most popular method, features of Kanban are present in the Scrumban method. Scrumban incorporates certain aspects of Kanban, such as the Kanban board or establishing specific limits to the amount of Work in Progress (WIP). In Scrumban there is a relaxation of the goal of establishing a cross-functional team; specialization is permissible. Scrumban is also easily usable for activities other than developing software.

Scrum is the most structured of the methods in that there are specific roles and specific rules.

• The specific roles are (a) the developers who produce the code, (b) the product owners who know what the product is supposed to do, (c) the scrum master who maintains the rhythm of development, and (d) an optional coach who helps a novice team or one that is seeking to improve.

• The specific rules are (a) to operate within specific time limits called “sprints,” (b) to plan tasks that can be completed within a sprint, (c) to work on only the most important tasks, (d) to hold a brief (15 minutes or less) meeting each day called the “daily stand-up” or “daily scrum,” during which only plans, progress, and problems are discussed, (e) to review and demonstrate the product to the customer at the end of each sprint, and (f) to review the successes and failures of the sprint in a group meeting called a “retrospective.”

Extreme Programming (XP) is based on the concept that “if some practice is good when developing software, then more is better.” Among the features of XP are constant code reviews, continual testing, continual integration, and anticipation of and handling of changes from the customer. Short time loops of all of these processes are promoted in XP.

The Scrum/XP Hybrid method can be considered as an extended form of Scrum because Scrum does not prohibit extensions. This method can include paired programming, continual integration, and, often, test-driven development. The Scrumban method may include these practices as well. Thus, there is a certain amount of overlap among the methods.

The Custom Hybrid method often means a hybrid of Scrum and Waterfall (the classical method for managing a project), but it can also refer to a hybrid of Scrum and some customization from the responding company. The survey does not provide details, nor does it require proof that the method claimed is even Agile, so the respondents who claimed to be using this method could be using a hybrid of Agile with something else or may only believe that they are using Agile without actually doing so. If the hybrid involves Agile and Waterfall, then it is likely that a contract or the customer requires such behavior (often contacts with a governmental agency). Hence, a hybrid method is needed, in which case a Custom Hybrid is the only method that can be used because it accommodates preliminary design, critical design reviews, and other milestones commonly found in governmental contracts. Under such circumstances, no other method would be suitable; therefore, the best method is the Custom Hybrid method. Sometimes the Scrum-Waterfall method is called Scrumfall, and it can perform rather well. Training is required for skillful usage.

Kanban is a Japanese word meaning signboard or billboard. Its use was developed by the Toyota Motor Corporation. In the area of software, items to be worked are on a status board or “Kanban board.” Team members can view the progress of a task as it flows through to completion. Limits on Work in Progress (WIP) are imposed, though as a team develops a rhythm, the limits may be altered. Developing cross-functional skills is not a goal; specialization is the norm.

Team members “pull” work as capacity permits, rather than having work “pushed” into the queue of work. A growing backlog should be avoided. Flow should be smooth. The priority of work is established by its assignment in the queue, and effort is focused on items of higher importance. Work in Progress is controlled by limits defined by the team.

Scrumban contains most of the basic features of Scrum with some modification and the addition of some features from Kanban. Scrumban relaxes the goal of cross-functional teams; specialization is permitted. There is an enhanced emphasis on flow and queuing. Within a sprint, the product owner can change the priority of any task that has not already begun. More planning occurs when the backlog (or “to do” list) drops below a desired level to keep everyone busy.

So which practice is the best? One way to decide is to select the practice that is best suited to the team, the task, and the character of the company. Every company develops a culture, and some methods mesh better with certain cultures, so it may be valuable to try different methods. The phase of a project should also be considered. The development phase is different from the maintenance phase. Though the same team could perform either phase, the rhythm is different. New features come from the imagination; problems come from the real world.

More Considerations

Extreme Programming (XP) was once a very popular method for developing software, but the latest Report indicates that the use of XP has declined to 1 percent. XP has developed and fostered some practices that have been adopted by other methods, but the exclusive use of XP has declined.

Let us consider the set of Scrum practices and the set of Scrum/XP Hybrid practices to be components of a superset identified as “Enhanced Scrum.” Assuming that this superset exists, some form of Enhanced Scrum is used for 68 percent of projects. Hmm! Could this be sufficient evidence on which to base a decision? Again the answer is “It all depends.”

The constituent practices incorporated to form a company’s Custom Hybrid method are too variable to analyze, since the practices are tailored to meet the specific needs of an organization. This method should be reserved only for teams that are very skilled with using Agile.

Returning to the superset, Scrumban consists of a merger of Scrum and Kanban. How complete that merger is can be debated, but a true Agilist permits an Agile method to be flexible with the goal of being effective, so let’s include Scrumban in the superset of “Enhanced Scrum.” (Figure 2: Enhanced Scrum) Enhanced Scrum could contain all of the features of Scrum, portions of XP, portions of Kanban, and other practices that might prove beneficial.

Of the five listed methods, Scrum is the most structured method. Kanban is much less structured — possibly the least structured method. The other methods fall somewhere in between.

Major differences between Scrum and Kanban

Clearly, Scrum has many more roles and practices, making it more structured. Other methods are more flexible and have more optional practices. These aspects are both the strengths and weaknesses of each method. The weakness of an optional practice is that while it may be necessary for a certain team, it is often omitted because the team ignores optional practices. A frequent misinterpretation by new Agilists is that documentation is not needed. This is another discussion that will be ignored here due to complexity, but some documentation is mandatory; for example, user manuals, problem reports, user stories, and project status updates.

Teams new to Agile will probably be making a transition from a more structured environment. Therefore, the team will be more comfortable with a structured but flexible method. Psychologically, it will be easier to make the transition to Scrum than to the even more relaxed environment of Kanban. Also, project management professionals and the executives of a company will probably be more comfortable with Scrum than with Kanban. For these reasons, Scrum would probably be the better method for developing a new product or making major changes to an existing product. For teams skilled with Agile and Scrum, the transition from Scrum to Extended Scrum should be rather easy if it is desired or appropriate.

After a product moves to the operational phase, product support begins. Problems will arise and be reported, so Kanban may be the better method during this phase. Problems will establish the rhythm as they are reported. Each problem will be addressed for the time required, and the size of a problem will not be an issue. Each team member can select a problem on which to work, or the team can swarm onto solving a problem. Thus, during a project’s life cycle, different Agile methods may be appropriate.

The Conclusions

For a product development team that is new to Agile, the more structured Scrum would probably be the best place to start. Training should be provided to avoid confusion among team members, managers, and other groups that will interact with the new Agile team. Without an understanding of Agile methods, outsiders may ask, “Why are you behaving like this, and why do you need my support so often?”

For a project involving mostly maintenance, Kanban would be a suitable method. Work focuses on each problem, irrespective of its size. An experienced team that does both development and maintenance might switch between Scrum and Kanban or use Scrumban.

The use of XP is fading, but many of its concepts are valuable, so they should be understood. An organization that examines XP may find it to be the most suitable method. However, the pool of experienced XP practitioners is smaller, so training will be almost mandatory.

So the answer to the question, “What Agile method is the best” remains clear: “It all depends upon what is to be done.” Has this helped?

Figures and Tables:

Figure 1. Survey Results ( Click to view image )

Table 1. A Comparison of Roles and Practices ( Click to view image )

Figure 2. Enhanced Scrum ( Click to view image )

References and Notes

  1. Scrum:
  2. Scrum/XP Hybrid:
  3. Scrumban:
  4. Kanban:


  1. The 10th Annual State of Agile Report.

Earl Soukup

Click to view image

Mr. Soukup holds a Bachelor’s and Master’s degree in Electrical Engineering, a Juris Doctor in Law, certificates for software development, project management, functional management, systems engineering, and Agile and Lean including being a Certified Scrum Master. He was a development and test engineer, manager, and project manager for both hardware and software. Also he developed and taught courses in mathematics, electronics, ethics, Lean, and Agile. He is an accomplished analyst.

Earl Soukup

Click to view image

Mr. Soukup holds a Bachelor’s and Master’s degree in Electrical Engineering, a Juris Doctor in Law, certificates for software development, project management, functional management, systems engineering, and Agile and Lean including being a Certified Scrum Master. He was a development and test engineer, manager, and project manager for both hardware and software. Also he developed and taught courses in mathematics, electronics, ethics, Lean, and Agile. He is an accomplished analyst.

« Previous Next »