Introduction
Software development is a complex set of tasks. The involution of many parties 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 for effective project management is important. Making a good choice will make the project work better and will increase the participation of the team members. This article explains which framework might be a more appropriate option when a project has too many external dependencies.
Scrum Framework in a nutshell:
Scrum Software development is a values-driven iterative development process. Each iteration is called a sprint. The sprint begins with planning and ends with a review and a 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 portfolio.
Scrum Master (ScM): Scrum Master keeps focus on goals and helps development team remove impediments. Scrum Master is also responsible for facilitating 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, at the end of the sprint, all the functions that are selected will be performed and shipped.
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 considered an inventory control system for the supply chain.
Kanban operates using the “PULL” method. The demands are stacked and the production pulls requests from the demand according to the production capacity. This philosophy is implemented in all production stations. 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 indicates demand. When a Kanban card is received, an order is activated to fulfill the demand indicated on the card. This is how Kanban represents a contentious ongoing workflow.
How can Kanban be applied in Agile and software development?
All customer demand orders can be viewed as software product development requirements / requests. as the software and product owner can be given responsibility to the to-do list to make a priority list. whenever a Kanban card is received, as long as the highest priority work items go to production. Systematization, development and testing can be considered as three minimum stations in the software development production line. A work item is finished when it goes through the entire flow. After the last station has passed, it can be sent.
What is external dependency?
Agile software development teams are expected to be formed in such a way that development teams are accountable for delivering value from start to finish. However, an agile project could be made up of multiple development teams. This article refers to a dependency as external dependency when a task cannot be handled by the development teams involved in that project. Dependencies within the 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 complete a task within the sprint, that task will go back to the product’s backlog and will be re-prioritized for development in the near future / near future. One of the main philosophies of the Scrum team is to commit in each sprint to complete all the extracted tasks and make them available. Ideally, the team should not do anything other than what it has agreed to do. Another key aspect is that in Scrum an estimate of the future
Kanban, on the other hand, agrees to produce and / or supply based on the demand signal through 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” in which the company is responsible for delivering the complete product in both hardware and software. 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 components of the external provider and the SW are external dependencies.
Case study: agile projects run with scrum
Sprint-0
HW teams develop Component 1 and Component 2. SW team does not start in Sprint-0.
Sprint-1
HW teams deliver Component 1 and Component 2. They plan to start work on Component 3, Component 4, and 15% of the time for an unexpected bug report.
Software teams plan to work with Component 1, Component 2, and 15% of the time for unexpected bug reports.
SW teams take component 1 and component 2 develops software for both. Component-2 works fine, just send it to Integration and find some minor issues in Component-1, so put it back to the HW project.
HW crews barely manage to fix within 15% of the allotted time.
Sprint-2
The HW teams deliver Component 1, 3 and 4 to the SW project and plan to work with Component 5 and 6 with an unexpected work estimate of 10% (lower as components 5 and 6 are larger).
SW teams plan to work with components 1, 3, 4 and 5% (less because there is more development to do) unexpected work.
The software teams check component 1 and send it to integration as it works fine. Almost immediately after finding a problem with component 3 and 4. it sends it back to HW. HW teams use 10% and found their main problem and need more time to solve it. Meanwhile, integration is done with components 1 and 2. You are ready for SW to perform an end-to-end (E2E) verification.
In this current situation, SW teams are stuck because all scheduled tasks are back on HW and HW does not have the capacity to service them. However, there is work to be done for SW i.e E2E verification, but that’s more than 5% unplanned capacity so teams can’t take on tasks.
In large companies, this can happen often. Practically, 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 you to break the sprint, re-plan, and set new goals, creating additional overhead. Additionally, 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 do a brief analysis of the aforementioned case using Kanban. In this analysis, both the 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 planning ahead so that software teams can perform E2E Component 1 and Component 2 tasks without any interruption. Similarly, the HW team could pull the chain for a component and start working on Component 3 or 4. From a framework point of view, adapting to the situation like this would be fine as Kanban is based on a continuous workflow.
conclusion
Agile project management is about delivering the right value quickly. Choosing the right methodology can be the individual factor between failure and success.
Scrum is best suited for development teams that have less external dependency, as it allows teams to better predict the future and make a good estimate. For example, the development of applications that are not integrated with HW 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 products already released.