An Introduction to Agile Development, Part 1: Scrum vs. Kanban

TL;DR: Two of the most popular agile methodologies are Scrum and Kanban. They mainly differ in the handling of prioritization (once per sprint vs. continuous) and deadlines (yes vs. no). Yet, independent of the approach, the key to success is to ensure focus and continuous delivery by: 1) creating small enough, manageable tasks, 2) prioritizing based on impact, and 3) finding a good trade-off between technical and business goals.

Many teams in software development and beyond are using agile processes to manage their tasks. However, working in an agile environment raises a variety of questions. Sometimes this is due to inexperienced team members, sometimes due to management deciding to use agile methods without having understood them.

Today, I have the pleasure to discuss agile development and two of the most popular agile methodologies—Scrum and Kanban—with Dr. Andreas Both, the Head of Architecture, Web Technologies, and IT Research at DATEV. Before, Andreas and I worked together at Unister, Germany’s biggest E-commerce company at that time, where he supervised my Ph.D. thesis. In this series of articles, our goal is to make agile development processes more understandable to people new to the topic and to dive a little deeper into the specifics of each methodology.

Max: To kick off the interview, we are going to start with one of the questions that is posed most often when people get started with agile methodologies and that I had to answer on way more than one occasion: What is the difference between Scrum and Kanban?

Andreas: In my honest opinion the core difference is the time taken for prioritization and iterations. While in Scrum the team is prioritizing once in an iteration, and during the sprint mostly only pull tasks, in Kanban the tasks are re-prioritized continuously. Hence, a task might be the next to be pulled from the backlog even though it has been raised by the product owner just seconds ago. Based on my experience, Scrum teams are feeling more freedom and less pressure due to the fact that in most companies the sprint is a protected area where external disruptions are minimized. Hence, development teams have more options to organize and plan their work, which might lead to higher happiness.

Max: Are there also differences in handling deadlines between Scrum and Kanban?

Andreas: A Scrum team delivers at the end of the sprint the latest. Kanban teams do not need an actual deadline, but if it takes very long to finish a task this might indicate a problem with slicing the task at hand into small enough, manageable subtasks. However, this problem also appears in Scrum teams. So, the differences with respect to deadlines are not significant if the process lead takes care. I think the core capability is to maintain a continuous delivery process.

Max: What is the best way or process to prioritize tasks?

Andreas: Based on my experience I’d say an impact-driven approach has the best chances of resulting in a successful project. It provides the opportunity for failing fast if the project is not executable. However, a mature team is needed in most cases to ensure success following this approach. For instance, the capability of slicing large tasks into smaller ones is required, so that manageable tasks are created and can be prioritized. Within inexperienced teams, you often hear statements like “We can’t slice it into smaller tasks,” which frequently leads to saving-the-world huge meta-tasks. Of course, there is no best process for task prioritization—just suitable ones for the current team’s or product owner’s maturity level and the product context. For instance, a simple approach might also help to establish a good acceptance of the product by the users. Finally, to live a methodology is crucial. A product owner should never be in the situation to not provide a justification or methodology for his prioritizations.

Max: So, from this, I conclude the process is not crucial in your opinion as long as the prioritization ensures focus. A different issue is that while establishing a backlog many teams struggle to prioritize requests of different kinds. How do you handle the conflicts between business goals and technical goals?

Andreas: I think there is no short answer to this question. When starting a project I suggest to favor the business needs over the long-term maintainability. This is due to a typical observation that requirements are unclear at this point in time. Early ideas about useful architecture etc. often do not hold and lead to wasted investments. At the same time, you have to communicate permanently to the (product) management that these early results and the velocity at which they have been created cannot be considered as regular and long-term. After some time teams tend to claim a certain amount of time to work on reducing technical debt. It is a question of maturity of the organization whether the development team can actually invest time to achieve technical goals or not. Unfortunately, we had to fight hard for this and lost many times.

Max: Isn’t there a risk that this leads to unsatisfied developers?

Andreas: Yes, there is a risk for sure. Unfortunately, reality shows that it is really hard to argue against killer arguments from strategic product management like “If we are not finishing this feature first, then the competitors will win.” Therefore, the Scrum master and the product owner have to work seriously on communicating the global priorities of feature completeness, maintainability, adaptability, etc.

Max: Very true. But what is your suggestion for a fresh product owner for prioritizing also non-business goals, such as the elimination of technical debt?

Andreas: In my experience, the key to success is to transform technical goals into business goals by finding related business KPIs. Let’s assume that the development team is annoyed because there is no time to refactor the source code and implementing unit tests for a certain component. While doing some analytics one might discover that the same component often contains bugs which need to be fixed in the sprint instantly. Hence, the missing tests are a reason for missing the deadlines for completing new features—leading to the business goal effectively encapsulating the technical goal. If the process lead and the product owner work closely together, then these justifications might be easy to find. However, if you do not find a reason, you should also talk frankly to the development team that it will not happen … and sometimes you just need to show courage and frankly inform your product management about the plan of aiming for a technical goal and just do it without justification.

Max: What are typical examples of features that should be realized using Scrum on the one hand and Kanban on the other?

Andreas: In my opinion, Scrum is more suitable for development teams targeting product goals where they can predict the requirements of the business domain (at least a little bit). If this is not the matter, then blockers within the Scrum sprint are more likely, which reduces the predictability of results at the end of a sprint. On the other hand, Kanban can be applied more easily with teams working in less predictable fields (e.g., research teams) or which are triggered by external interrupts (e.g, IT operations teams). For larger teams, there are results from different domains that Scrum is doing better. However, if you have such a large project that several teams are required, then your teams really should be experienced in agile methodology anyways.

This concludes the first part of Andreas’s and my little introduction to agile development, where we mainly addressed general issues such as deadlines, prioritization, communication, and the differences between business and technical goals. Also, we’ve had a closer look at Kanban and how it is different from Scrum. In the next part of the interview, we will be paying more attention to the specifics of the latter. Stay tuned!

Advertisements

Talking Design Thinking with Abhijit De

abhijit-de“Sorry, we are out of stock!” is an unpleasantly common sentence customers of Indian retailers hear every day. This is because due to a lack of appropriate systems, retailers are having problems with maintaining their stock and accurately anticipating the necessary quantities of each product. With their business network Ganges, SAP intend to tackle this and other problems in the supply chain that prevent Indian retailers from making the most of their businesses. To be able to optimally achieve this, during the creation process Design Thinking was applied to understand retailers’ and the other involved parties’ needs and pain points. I have had the opportunity to talk to Abhijit De (pictured)—who was one of the driving forces behind Ganges—about their solution, the unique value Design Thinking has contributed, and its pros and cons.

Max: First of all, could you please give a quick intro of yourself?

Abhijit De: My name is Abhijit De. I grew up in Uganda, Africa, worked and lived in the USA for 15 years and spent the last 5 years in India. I have always oscillated, alternating between corporate jobs—Intel, Microsoft, Infosys, and SAP—and entrepreneurial start-ups. For the past five years, I was VP of new business incubation at SAP with a particular focus on business networks and IoT. I recently transitioned out of SAP to plan my next start-up. Additionally, I also hold a Master’s degree in Management of Technology as well as an MBA.

Personally, I like to help initiate and execute projects that have high impact on improving life on this planet. I like to travel and interact with different cultures. My motto is: “Work hard and play hard, but leave a better planet behind.”

Max: Together with your team, you have created SAP Ganges, which is a business network in the retail sector. What exactly is a business network?

Abhijit De: I had the opportunity to set up an innovation business at SAP and chose a business network in the retail sector. A business network is an IT infrastructure that allows different personas from different types of companies in one trade ecosystem to transact business together. One example for this is SITA, which is a travel network that allows airlines, hotels, travel agents, financial institutions, customers, airports, etc. to do business in a coercive framework and information infrastructure. At SAP, the executive strategy was in the direction of business networks with the acquisition of Ariba, which is a business network in procurement, Fieldglass, etc.

In the case of Ganges we were building a business network for the retail ecosystem. This means that retailers, wholesalers, FMCG manufacturers [fast-moving consumer goods], banks, fellow travelers, etc. can conduct business seamlessly.

Max: To create SAP Ganges, your team has applied Design Thinking; you have talked to numerous retailers and distributors to learn about their pain points. What is the unique value Design Thinking has added to the system compared to traditional engineering approaches?

Abhijit De: I believe there are two types of innovation: First, push innovation and second, pull innovation. Furthermore, all innovation manifests as one or more of the following frameworks: incremental innovation, disruptive innovation, fundamental innovation, and alternative application innovation.

A push innovation use case example would be Intel processors. Intel designs processors based on fundamental research innovation and it sometimes takes ten years to get from ideation to offering as there are long cycles of designing and building the technology fabrication plant. Hence, at ideation Intel cannot always accurately predict the types of applications that will use the said processor. This is a “build it and they will come” strategy. As such, Intel “pushes out” products and offerings without intensive end-user input.

A pull innovation use case example would be Apple’s iPhone 7 or Facebook. These are based on a deeper understanding of users’ pain points and their root cause analysis. Value created is accessed at the ideation phase of the product or service.

The Design Thinking and value engineering methodologies together work as a perfect process to mitigate most calculated risks. Hence help create a “viral” product or service as it results in “capabilities” of highest value to the “user”. It is grounded in time-to-market boundaries based on an additional feasibility and viability framework.

Max: What is the main disadvantage of Design Thinking?

Abhijit De: First, Design Thinking is a pull innovation methodology and not very effective on push innovation scenarios. Second, Design Thinking curtails radical creative or artistic opportunities. And third, Design Thinking does not dig deep into addressing ecosystem change nor does it address fellow traveler requirements. Examples for this are offerings based on new material innovation or fundamental research that cannot be improved using Design Thinking methodology effectively.

Max: In the official video about SAP Ganges, you say that your team did “constraint innovation”; that most of the project was done with zero budget and most of the work with crowdsourcing. Can you please dive a little deeper into that?

Abhijit De: Today there is a lot of waste of resources in corporate environments due to power plays, fiefdom politics, unaligned divisional strategies, siloed organization structures, etc. Constrained innovation starts with building effective networks within the organization to enable the empowerment and creation of vested stake holders, starting with internal fellow travelers. Nurturing win-win objectives between resource owners and your team/project creates a strong ecosystem of support that opens various types of resources as needed by your project [cf. Juggaar innovation]. Moreover, enabling systematic structured internal crowdsourcing also facilitates HR objectives in increasing employee satisfaction and growth.

Max: The main motivation behind the system is to maximize retailers’ businesses. What are the non-economic implications?

Abhijit De: There are several:

  1. Increasing financial inclusion;
  2. elevating the poverty level from $1/day to $2/day in India;
  3. banking the unbanked;
  4. optimizing the FMCG supply chains;
  5. moving to a cashless society;
  6. creating new channels and markets for cross-pollination, i.e., alternative uses;
  7. eliminating parallel economy; and finally
  8. increasing education and awareness reach.

Max: How do you guarantee your Design Thinking–based technology is available to those who need it?

Abhijit De: For this, we build on an awareness generation program due to success stories.

Max: Can you please explain in one or two sentences how this works?

Abhijit De: Based on use-case success stories we let the merit of the methodology speak for itself. For example, through articles in the Harvard Business Review etc.

Max: Where is SAP Ganges today?

Abhijit De: As all products and services need to have exit strategies, the corporate strategic focus changed and SAP Ganges was morphed into the SAP IoT world; meanwhile the Indian government has finally moved towards a cashless society enabling several similar business networks to germinate ecosystems with the same objectives.

Max: If a company came to you and said “We want to do Design Thinking because it’s hip and everyone else does it”, what would you tell them?

Abhijit De: Follow the “MAN” rule!

  1. Do you have the money?—It’s an expensive investment.
  2. Do you have the top down buy-in commitment?—authority
  3. Do you have the need?

Any two of these are sufficient to create the third, but all three are necessary to successfully enter into a Design Thinking–based project.

Max: To conclude the interview: What is Design Thinking?

Abhijit De: It’s a tool like many others with pros and cons and not always the right tool for every scenario. It is however a great tool/methodology that can design “viral” products and services when executed well.

Max: Thank you for taking the time to provide your insights on this topic! It’s very much appreciated!

(This article has also been published in theuxblog.com on Medium.)