Introduction

Software development is a set of complex tasks. Multi-stakeholder engagement and coordinated participation are necessary to achieve results. Agile methodologies explain some guidelines and provide a more multiple framework to facilitate the development process. Two well known frameworks are Scrum and Kanban. Selecting the appropriate framework is important for effective project management. Making a good choice will make the project run smoother and increase team member engagement. This article explains which framework might be a better choice when a project has too many external dependencies.

Scrum Framework in a nutshell:

Scrum software development is an iterative, value-driven development process. Each iteration is called a sprint. Sprint starts with planning and ends with review and retrospective. Scrum defines 3 roles:

Product Owner (PO): The product owner is responsible for creating a prioritized list of all product features called a product backlog.

Scrum Master (ScM): The Scrum Master keeps the focus on goals and helps the development team remove impediments. The scrum master is also responsible for facilitating the scrum artifacts.

Development team: At the beginning of a sprint, the development team chooses some of the features based on their ability. Usually the most important features are selected first. Ideally, by the end of the sprint, all features that are selected will be ready and shippable.

Kanban framework in a nutshell

Kanban is a Japanese invention that is primarily a scheduling system for lean manufacturing and Just-in-Time (JIT) manufacturing. It is also seen as an inventory control system for the supply chain.

Kanban operates using the “PULL” method. Demands are stacked and production pulls requests from the demand according to production capacity. This philosophy is implemented in each production station. A Kanban card is used to send signals from one station to another within the production line or even to an external supplier. A Kanban card generally sets the demand. When a Kanban card is received, an order is triggered to fulfill the demand set on the card. This is how Kanban represents a controversial flow of work in progress.

How can Kanban be applied in Agile and software development?

All customer demand orders can be viewed as software product development requests/requirements. as the backlog for software and the product owner can be given the responsibility of making a prioritized list. Whenever a Kanban card is received, the highest priority work items will go to production. Systematization, development and testing can be considered as three minimum stations in the software development production line. A work item is done when it goes through the entire flow. Once the last station is passed, it will be transportable.

What is the External Dependency?

Agile software development teams are expected to be formed in a way that development teams are responsible for end-to-end value delivery. However, an agile project might consist of multiple development teams. This article refers to a dependency as an external dependency when the development teams involved in that project cannot handle a task. Dependencies within different teams in a project are treated as internal dependencies.

Correlation between External Dependencies and Scrum and Kanban

When a Scrum development team is unable to finish a task within the sprint, that task will go back into the product backlog and be reprioritized so that it can be driven by future/next development. One of the main philosophies of the Scrum team is to commit in each sprint to complete all the extracted tasks and make them deliverable. Ideally, the team should do nothing more than what it has agreed to do. Another key aspect is that in Scrum an estimate of futures

Kanban, on the other hand, agrees to produce and/or supply based on the demand signal via the Kanban card. Kanban does not require estimation in the future.

Let’s take a case study of Hardware (HW) and Software (SW) development with external dependency

In this example, let’s assume that company “ABC” is developing a product “XYZ” where the company is responsible for delivering the entire product, both HW and SW. HW and SW development is defined as two separate projects and both projects have a respective project manager who meets regularly and synchronizes the project time plan. For the SW project, HW is an external dependency. For the HW project, both the SW and external provider components are an external dependency.

Case study: agile projects run with scrum

Sprint-0

HW teams develop Component-1 and Component-2. The SW team does not start at Sprint-0.

Sprint-1

The hardware teams deliver component 1 and component 2. They plan to start working on component 3, component 4, and 15% of the time for an unexpected bug report.

The SW teams plan to work with Component 1, Component 2, and 15% of the time for unexpected bug reports.

SW teams take component 1 and 2 develop software for both. Component 2 works fine, just send it to Integration and find some minor issues in component 1, so send it back to the HW project.

The HW teams barely manage to fix it within 15% of the allotted time.

Sprint-2

The HW teams deliver components 1, 3, and 4 to the SW project and plan to work on components 5 and 6 with an estimate of 10% unexpected work (lower, since components 5 and 6 are larger).

The SW teams plan to work with component 1, 3, 4 and 5% (lower because there is more development to do) unexpected work.

The SW teams check component 1 and send it to the integration as it works fine. Almost immediately after they found a problem with components 3 and 4, it sends it back to HW. HW teams use 10% and found their biggest issue and need more time to resolve. Meanwhile, the integration is done with components 1 and 2. It is ready for SW to perform end-to-end (E2E) verification.

In this current situation, the SW teams are blocked because all the scheduled tasks have returned to HW and HW does not have the capacity to attend to them. However, there is work to be done for SW, ie E2E verification, but that is more than 5% of the unplanned capacity, so the teams cannot perform the tasks.

In large companies this can happen often. In practice, scenarios can get much more complicated when teams are located in different countries and time zones. Scrum finds challenges in these types of scenarios. This forces breaking the sprint, replanning, and setting new goals, which creates additional overhead. Also, changing goals and commitments in the middle of a sprint can have a ripple effect and indirectly create invisible impediments.

Projects are executed with Kanban

Let’s try to make a brief analysis of the case mentioned above using Kanban. In this analysis, both HW and SW projects have created 2 production lines. Each production line has the ability to develop one component at a time. Kanban does not require a plan in advance, so the SW teams could take over the E2E tasks of components 1 and 2 without any interruption. Similarly, the HW team could pull the string for one component and start working on Component 3 or 4. From a framework point of view, adapting to a situation like this would be fine, since Kanban is based on a continuous workflow.

conclusion

Agile project management is about delivering the right value quickly. Choosing the correct methodology may be the only factor between failure and success.

Scrum is more suitable for development teams that have less external dependencies as it allows teams to better predict the future and make good estimates. For example, developing applications that are not HW integrated or that do not have a strict dependency on the underlying platforms.

Kanban is best suited when project tasks are primarily triggered by events. that is, integration, development support for already released products.