Agile Scrumban – Built on the Fabric of Scrum and Kanban

Scrumban, a hybrid of Scrum and Kanban flavors of Agile, offers the best of both worlds. Scrumban ensures that a highly versatile workflow management is achieved by integrating the flexibility and visualization of Kanban into the structure of Scrum. Scrumban thus offers a middle ground to the Scrum’s structure overhaul, and Kanban’s unstructured approach – making it useful for both development and maintenance projects.

To fully understand Scrumban, let us first understand the main individual characteristics of Scrum and Kanban.

Scrum

  • Small, cross-functional self-organizing teams
  • Work is split into a list of small deliverables, sorted by priority
  • Prescribed roles- Scrum Master, Product Owner, Development Team
  • Short fixed length iterations with potentially shippable code demonstrated after each iteration
  • Approach is to inspect and optimize the release plan, and update priorities
  • Retrospectives occur after each iteration

In Scrum, the work to be done for the next sprint is chosen beforehand, and the sprint is then locked till the work is done. And at the end of the sprint duration, the queue is empty.

Kanban

  • Workflow Visualization through Kanban Board
  • No prescribed roles
  • Limits WIP – limits the items in process at any given time
  • Measures lead time and optimizes the process to improve the lead time

In Kanban, the work keeps flowing, and although the size of the queue is limited, the items in the queue can be changed at any time.

Scrum and Kanban: The Divide

Both these approaches have their own pros and cons, and work on different ideologies. Whereas Scrum has a set of prescribed roles, Kanban has none. Meetings are an integral part of Scrum, while Kanban has no such requirements. Besides, unlike Scrum, Kanban does not have a fixed time limit for development.

Let us observe how Scrumban fixes this divide, and coalesces  an ingenious approach absorbing the best of both.

Scrumban

Introduced by Corey Ladas, Scrumban was initially developed as a method of transitioning a development team from Scrum to Kanban. However, it has evolved as a methodology on its own, combining the finest elements of both Scrum and Kanban.

Scrumban Methodology: Filling the Void

  • Scrumban makes iterations short and optional while imbibing Kanban’s approach of continuous workflow. Items are worked upon as and when they appear, with no prioritized and committed product backlog items. Prioritization on demand technique is normally used.
  • Scrumban has a definite team, but only requires roles as needed. There is no definite number, and roles are more specialized and less cross-functional than in Scrum teams. Team members are free to choose the task they like using the pull system.
  • Scrumban boards are used like Kanban for workflow visibility with the columns – ToDo, Doing, and Done. The board is persistent – only the tasks and priorities change.
  • Like Scrum, Scrumban involves daily meetings, however, embraces on-demand planning at regular intervals, rather than sticking to release-planning meeting or retrospectives at the end of the sprint like Scrum.
  • Like Kanban, Scrumban does not have a specific time constraint. Through the use of WIP limits on columns within their task board, the team limits itself. In Scrumban, a WIP limit is normally equal to the number of people in the team, but can be expanded based on work specifications.
  • Like Kanban, Scrumban relies on measuring the lead time and cycle time as the key metric to estimate the average time of completion of a specific task.
  • Feature Freeze is used in Scrumban when project deadline is near, which implies that the features the team already has for development can only be worked on, and no additional features can be added.
  • Finally, triage is critical as Scrumban does not embrace estimating. Scrumban triage enables termination of less significant features in order to complete essential features on time.

Scrumban definitely brings in the best of both worlds, however, application of Scrumban is not conducive for every environment and culture. Scrumban is apt for fast-paced processes or projects that require continuous product manufacturing with dynamic environments. Let us understand the applicability criterion for Scrumban.

Suitability of Scrumban

To sum up, Scrumban is ideally suited for:

  • Projects that involve great deal of unexpected change to user stories and priority reworking. For example- maintenance projects like event driven work or help-desk/support.
  • Teams focused on new product development or continuous management improvement.
  • Projects where Scrum is constrained by workflow issues, resources and processes.
  • Teams that require both structure of Scrum and flexibility of Kanban.
  • Transitioning to Kanban, where minor methodology changes are required to limit disruption.

Indubitably, when used aptly, Scrumban leads to better quality, reduced lead time, application of Kaizen and JIT principles along with waste minimization and process improvement. A word of caution is that before applying any methodology, it is imperative to understand the basic principles of all the agile methodologies currently in practice to determine the befitting approach for the project specific needs. The company and team readiness to adopt that approach also matters.

With skilled resources and expertise to understand the intricacies of various agile approaches, we at Astegic have developed a Scrumban Framework – SBDEFT (Scrumban Driven Engagement Framework for Testing). SBDEFT is developed with an aim to deliver the benefits of both the approaches, Scrum and Kanban, in a pioneering way in an outsourced context. Our experts are adept at understanding and implementing the approach that best suits your project, whether it is Scrum, Kanban or Scrumban. Moreover, our TRAF (Testing Requirement Analysis Framework) ensures validating QA /Testing requirements in the early stages of development to serve you with the best approach.

A Journey to the IoT World-II

This is a three part series

Testing Challenges in an IoT Framework

In connect to our previous blog, we may rightly define Internet of Things (IoT) or our ‘Cobweb’ as the new gigantic ‘tech-wave’ disruptive to the existing technologies with no apparent parallels, at present, or in near future. But what’s so unique about it?

It’s not an ordinary cobweb which is superficially connected, rather each thread of the cobweb can sense the activities of each and every other thread, and can communicate with it in real time. Stating differently, IoT implies- flawless communication of devices among the internal and external environments in real time through the exchange of data and split-second information, enabling intelligent decision- making. Sounds fascinating? It certainly is exciting for the users, however, not so appealing for the testing world. Let us comprehend the reasons.

Dealing with an Avalanche of Internet-Enabled Devices

IoT framework implies further increase in the existing heap of devices, making testing on all real devices a sheer impossibility. A wide range of traffic patterns, big data, different types of interfaces, numerous OS, networks, locations, and device specific features, poses a complex matrix of possible testing scenarios, making the QA testing task highly sophisticated and challenging.

Difficulties in Ensuring Hyper-connectivity Across the Multi-Layered IoT architecture

With the multitude of sensors and actuators collecting huge chunks of data through multiple networks, the task of dynamically collating and displaying streams of data in real-time may cause storage-analysis paralysis. Therefore, Quality Assurance testing for ensuring device interoperability for perfect user interaction will require numerous tests to run for longer time span to ensure reliability, compatibility, and security, in turn, hitting the time to market the product. Besides, can security be ensured even after that?

Security and Compatibility Concerns

The inflow of constant stream of data will make it crucial to ensure data safety. Scrutinizing that data does not leak when being transmitted from one device to another,  and is properly encrypted, will require comprehensive testing solutions.Moreover, resolving the compatibility issues for integrating various controller devices in the existing systems for data generation is another challenge.This will not be a straightforward task and a lot of knowledge and understanding will be required along with time considerations.

Hence, security issues and testing for backward compatibility with upgraded versions will be major areas of unrest for the testers, especially when speed to market matters, and when trade-off is not an acceptable option.

HP study reveals that 70 percent of IoT devices are vulnerable to attack, and IoT devices averaged 25 vulnerabilities per product, indicating expanding attack surface for adversaries.

Source: Android Authority

This reiterates the need for thorough end-to-end agile testing solutions. Is it easy? Let’s see.

No Substitute for Agility

The need for faster releases will pull agility to the mainstream. Though both Automation and Manual testing may be required for the IoT apps; however, testers and organizations stuck with slow traditional waterfall models will not be able to survive without updating themselves.

Speed to market will be the key, and automation and better communication will need radical changes in the current testing approaches along with the organizational set-up. What does it imply?

Challenges in Adopting DevOps

DevOps will become a norm as teams will be required to work more effortlessly and converse quickly to mitigate the higher technological risks. This will be a major bottleneck for traditional organizations who will need a complete turnaround, not just in technological terms but also in terms of dealing with the change. The need for agility and DevOps will further imply increased dependency on Open Source Frameworks that can enable faster and thorough testing across multiple platforms and devices.

Challenges of the Current Open Source Frameworks

The current Open Source Networks may not be able to cope up with the enhanced platform fragmentation, and future testing needs. The current frameworks require tester’s to do more work around test automation development, and around setting up the frameworks, which will be a mismatch to the sprawling network requirements in the rapidly growing IoT sector.

Setting up the suitable test framework for agile testing requires fast and incessant testing with an enhanced pace of development and quick release patterns. With IoT, it will get even more complex leading to longer test cycles, defeating the need for agility. Further, this can consume a huge chunk of the testing budget set aside by companies, posing a challenge, particularly for the small testing companies.

Can Testing Companies Manage their Budgets?

Accessing the next-gen automation tools to ensure faster and shortened SDLCs along with the need for elaborate testing in the IoT context could mean extensive cost to the company especially on hardware and test infrastructure.

In addition, companies shifting to Agile and DevOps approaches from the old traditional approaches will need to spend expansively. Finally, if the testers are not well trained, they shall not be able to decide the right tools or use them wisely, thus adding further cost to the company.

Companies Will Need Skilled Testers

Lack of skills can lead to a big hole in the testing budget of the testing companies. Emerging technologies like IoT will need new skill-sets, and this may require changing the current workforce or extensive training, both of which implies higher costs.

Conclusion

In a nutshell, with the adoption of IoT-platform, and device fragmentation will increase the testing complexities in multifold. Let’s make an attempt to highlight the major problem areas:

  • Security will be a big challenge and despite the need for longer test runs, the speed to market will remain a priority, posing a tradeoff.
  • Companies will be compelled to adopt Agile and DevOps and manual testers will not be able to survive without updating their skills.
  • The current Open Source Frameworks will not be sufficient. With the increase in a number of internet enabled devices, platform and device fragmentation problems will increase.
  • The changing landscape and increased budgetary requirements, with a need for radical change in the management mindset, will be a matter of great concern especially for mid-sized and small testing companies who may be forced to go out of business.

Let us try to comprehend if testing companies can prepare themselves before the IoT storm hits them in the face. Let us sneak into probable solutions to the testing challenges in our third and final part- Managing the IoT Storm- Probable Solutions to the Testing Ordeals.

A Journey to the IoT World- I

This is a three part series

An Introduction to IoT

With lots of noise around the word, IoT or Internet of Things is increasingly becoming the talk of the town. Still, many people are simply trying to grasp the fundamentals of what exactly is IoT, and Google is increasingly being fed with the technical jargon to understand the enigma. Let’s try to unveil this mystery.

IoT-  A Cobweb

Using the analogy, IoT may be referred as the cobweb created by ‘internet’ or ‘the spider’ that crawls across n number of devices connecting ‘each-other’ and the ‘user’. Sounds interesting?

Stating plainly, IoT is all about connecting devices to the internet. This includes everything from washing machines, refrigerators, lamps, wearable devices, to almost anything that you may think of, with an on-off knob. Likewise, the devices will be able to flawlessly converse with us, and with other devices and applications.

This implies that, effectively, the transformation caused by IoT shall be felt across all facets of life. As per Gartner, the number of connected ‘things’ will be around 25 billion, by the year 2020. But what does this connectivity mean to us?

Voyage from Cobweb to Silk

Ever thought of smart cities? Visualize smart traffic signals that control traffic in real time or smart cars that automatically sense these traffic signals in real time. What if your alarm clock not just wakes you up but also notifies your water heater to start heating water? This will simply mean that IoT will creep into everything, which implies – if it’s not connected, it does not exist!

This is merely an iota of what IoT may be able to achieve. Innumerable possibilities with endless connections have resulted in IoT being a much-debated topic. Let us understand what it takes to weave a perfect Cobweb?

The Layers of the Cobweb

Let’s unweave each layer of the cobweb to understand it better.

                         Fig: IoT Architecture Layers           Source: C # Corner

The IoT architecture begins with connected devices or ‘things’ with sensors and actuators, collecting and giving out data in real time, and these need networks to communicate and become useful, moving us to the Network and Communications layer. This layer enables rapid collection and transfer of data, leading to Management layer that stores, manages, and analyzes this data intelligently. Further, the managed information is then released to the application layer for proper utilization of the data accumulated.

This is how a multi-layered IoT architecture works, but can it work flawlessly? After all, the cobweb may suffer from weaving anomalies.

Cobweb in Jeopardy

Security will be the major concern with all the threads of cobweb intertwined. Someone hacks a piece of information from your smartwatch and now it gets easy to draw more information from all the connected devices you have.

This implies that privacy and data sharing will become complicated, and dealing with tons of data getting accumulated from billions of devices will make storage, tracking, and analysis, a challenging chore. This burdens the testing community with the challenging task of ensuring seamless integration of devices, with internal and external environments, along with safeguarding information exchange in the hyper-connected world across the multi-layered IoT architecture.

Safeguarding the Cobweb

As testers are already witnessing testing troubles caused by escalating device and platform fragmentation; the complexity is going to grow exponentially with IoT. Quality Assurance Testing that was successful with new innovations previously is going to stumble upon a paradigm-shift with a deluge of data coming from millions of sensors each day, enhancing the testing zone complexities.

Let us focus on the challenges that testing community is going to face in the next part of this series- Testing Challenges in an IoT Framework