Choose the Right Agile Methodology With External Dependencies – Scrum VS Kanban

Choose the Right Agile Methodology With External Dependencies – Scrum VS Kanban
By Zakaria Khan

Introduction

Software development is a set of complex tasks. Many parties involvements and coordinated participation are necessary in order to achieve results. Agile methodologies explains some guidelines and provides more multiple framework to facilitate the development process. Two well known framework is Scrum and Kanban. It is important to select the appropriate framework for effective project management. Making a good choice will make the project run smoother and increase team members engagement. This article explains which framework could be a more appropriate choice when a project has too many external dependencies.

Scrum Framework in a nutshell:

Scrum Software development is a value driven iterative development process. Each iteration is called sprint. sprint starts with planning and end with a review and retrospective. Scrum defines 3 roles:

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

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

Development Team: At the beginning of the a sprint development team picks some of the features based on their capacity. Usually the most important features are picked first. Ideally, end of the sprint all features that are picked shall be done and shippable.

Kanban Framework in a nutshell

Kanban is a Japanese invention that mainly is a scheduling system for lean manufacturing and Just In Time (JIT) manufacturing. It is also viewed as an inventory control system for supply chain.

Kanban operates using “PULL” method. Demands are stacked and the production pulls requests from the demand according the capacity of the production. This philosophy is implemented in every station of production. A Kanban card is used to send signals from one station to another within the production line or even external supplier. A Kanban card generally states the demand. When a Kanban card is received that triggers an order to fulfill the demand stated in the card. Thats how Kanban represents a contentious flow of work in progress.

How Kanban can be applied in software development & Agile?

All demand orders from customer can be viewed software product development requirements/ requests. as the backlog for the software and product owner can be given the responsibility to make a prioritized list. whenever a Kanban card is received the higher priority work items shall go to the production. Systemization, Development and Test can be considered as three minimum station in software development production line. A work item is done when it goes through the entire flow. Once the last station is passed, it shall be shippable.

What is External Dependency?

Agile software developments teams are expected to be formed in a way that the development teams shall be responsible for end to end value delivery. However, an agile project could be consist of multiple development team. This article refers to a dependency as external dependency when a task can not be handled by the development teams involved in that project. Dependencies within different teams in a project is addressed as internal dependency.

Correlation between External Dependencies and Scrum and Kanban

When a Scrum development team can not finish a task within the sprint that task shall go back to the product backlog and re-prioritized so it can be pulled by the development in the future/next. One of the main philosophy of Scrum team is to make commitment at every sprint to complete all pulled task and make it shippable. Ideally, team should do nothing else but what they have committed to do. Another key aspect is that in Scrum an estimation of future

Kanban on the other hand accepts producing and/or supplying based on demand signal through Kanban Card. Kanban does not require estimation in future.

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

In this example let’s assume Enterprise “ABC” is developing a product “XYZ” where the enterprise is responsible for deliver the complete product both HW and SW. HW and SW development is defined as two separate project and both projects have respective project manager who regularly meets and synchronise the project time plan. For the SW project, HW is an external dependency. For the HW project, both components from external vendor and SW are external dependency.

Case Study: Agile Projects are running with scrum

Sprint-0

HW teams develops Component-1 & Component-2. SW team don’t start in Sprint-0.

Sprint-1

HW teams delivers component-1 & Component-2. They plan to start working on component-3, component-4 and 15% of the time for unexpected bug report.

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

SW teams take component-1 &2 develops software for both. Component-2 works fine sone send it to Integration and finds a few minor issues on component-1 so send it back to HW project.

HW teams hardly manages to fix within the 15% allocated time.

Sprint-2

HW teams delivers Component-1,3 and 4 to the SW project and plan to work with Component-5 & 6 with 10% (lower as component 5 & 6 are bigger) unexpected work estimation.

SW teams plan to work with component-1, 3, 4 and 5% (lower because more development to be done) unexpected work.

SW teams checks component-1 and send it to integration as it works fine. Almost immediately after they found problem with component-3 and 4. sends it back to HW. HW teams uses 10% and found its major issue and need longer time to solve. In the mean time integration is done with component-1 & 2. It is ready for SW to conduct an End-to-End (E2E) verification.

In this current situation SW teams are blocked because of all planned tasks are back to HW and HW don’t have the capacity to serve them. However, there are work to do for SW, i.e. E2E verification but that’s more that 5% unplanned capacity so the teams can not take the tasks.

In large enterprise this may often happen. Practically, scenarios may become a lot more complicated when teams are colocated in different countries and time zones. Scrum encounter challenges in this kind of scenarios. This enforces to break the sprint, re-plan set new goals which creates additional overhead. In addition, changing goals and commitments in the middle of a sprint may make a ripple effect and indirectly create unseen impediments.

Projects are running with Kanban

Let’s try to make a brief analysis of the case mentioned above using Kanban. In this analisys, both HW and SW projects have created 2 production lines. Every production line has a capacity of developing one component at a time. Kanban don’t require plan ahead so the SW teams could take in Component-1 & 2 E2E tasks without any disruption. Similarly, HW team could pull the chain for one component and start working on Component 3 or 4. From a framework point of view adapting to the situation like this would be OK as Kanban relies on continuous work flow.

Conclusion

Agile project management is about delivering right value fast. Choosing the right methodology can be the solo factor between failure and success.

Scrum is more suitable for development teams that has less external dependency since that allows teams to be able to predicts the future better and make a good estimation. For example, developing applications that are not embedded with HW or don’t have hard dependency on underlying platforms.

Kanban is more suitable when project tasks are triggered mainly by events. i.e. Integration, Development Support for already released products.

Visit AgileNightmare to learn more practical applications about Agile Enterprise Transformation

You can also legally download free agile eBooks provided by publishers.

Article Source: Choose the Right Agile Methodology With External Dependencies – Scrum VS Kanban