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

What ’bout some fancy dashboards for ya? Power BI vs. Geckoboard

In my capacity as the chief data analyst of bitstars, it’s one of my key responsibilities to regularly compile all relevant figures concerning our web platform HoloBuilder. These figures are mostly intended for people who don’t have the time to dive deeply into some fancy but complicated statistics. Hence, from the user experience perspective it’s crucial to provide them in an easy-to-understand and pleasant-to-look-at form. A well-established way of doing so are data visualizations of different forms which are provided in terms of dashboards for optimal accessibility. Since we are currently redesigning our internal process for providing figures and statistics, I’ve done some research on two potential software solutions that could be used for this.

Requirements

Since we are talking about a solution for our internal process at bitstars, there is a set of company-specific requirements a contemplable software has to fulfill. In particular, these requirements are:

Moreover, there are two nice-to-haves:

In the following, I investigate two possible solutions—Power BI and Geckoboard—, which are evaluated against the above requirements.

Power BI

Power BI WebsitePower BI is a cloud-based business analytics service provided by Microsoft. It comes as a part of the Office 365 suite, but can also be used standalone. There is an online as well as a desktop version, whereas the latter has a significantly larger range of functions. Power BI distinguishes between dashboards (“[…] something you create or something a colleague creates and shares with you. It is a single canvas that contains one or more tiles.”) and reports [“one or more pages of visualizations (charts and graphs)”]. Reports can be saved in the Power BI Desktop file format (.pbix); dashboards can be shared.

Power BI comes with a rather limited range of integrable services, among which are Google Analytics (☑) and MailChimp (☑). AdWords (☑) statistics can be integrated via Google Analytics if your respective accounts are connected. However, integration for Facebook Ads (✖), Pipedrive (✖) and AWS (✖) is still missing. FB Ads integration has been requested, but is yet to be realized. There is moreover functionality to integrate data from Excel and CSV files (from your computer or OneDrive) or Azure SQL databases, among others, which also enables you to import your own custom data.

The basic version of Power BI can be used for free while Power BI Pro comes for $9.99 per user & month.

How to create a cumulative chart in Power BI?

Cumulative charts are not a built-in functionality of Power BI, but can be easily realized using Data Analysis Expressions (DAX, ☑). That is, you have to create a new measure in your dataset. Assume, for instance, you want a cumulative chart of your sales (to be accumulated, Y axis) over time, which are only present in your dataset as the number of sales per date (X axis). The DAX formula for your new measure would be as follows:

Measure = calculate(
  SUM('Your Dataset'[Sales]);
  FILTER(
    all('Your Dataset'[Date]);
    'Your Dataset'[Date] <= max('Your Dataset'[Date])
  )
)

(found at http://www.daxpatterns.com/cumulative-total/). You can then simply add a chart visualizing your new measure (Y axis) per date (X axis) to your Power BI report to obtain your desired cumulative chart.

Geckoboard

Geckoboard WebsiteGeckoboard is a web platform for creating individual dashboards that show your business’s KPIs (key performance indicators), e.g., unique visits to your website, Facebook likes or sales per day. The platform has built-in support for integration of a wide range of external data sources, including Google Analytics (☑), AdWords (☑), Facebook Ads (☑), MailChimp (☑), Pipedrive (☑) and AWS (☑) and many more (in fact, way more compared to Power BI). Moreover, Geckoboard supports CSV and Google Sheets integration for your own custom data.

Like in Power BI, there is no built-in support for cumulative charts. However, since it is easily possible to create those in Google Sheets (see, e.g., this link), they can simply be imported and visualized in Geckoboard as well (☑). Of course, this means an additional intermediate step is required.

Geckoboard offers no free plan. Paid plans start from $49 per month for one user and two dashboards.

Conclusion

Power BI Geckoboard
Cumulative charts (☑)1 (☑)1
Google Analytics integration
AdWords integration
Facebook Ads integration
MailChimp integration
(Pipedrive integration)
(AWS integration)
overall rating ⭐⭐⭐ ⭐⭐⭐⭐

Both tools miss built-in functionality for cumulative charts, but provide means for importing own custom data. When it comes to the integration of third-party services, Geckoboard supports a significantly lager range of available data sources. Because of this, I give Power BI an overall rating of 3 out of 5 (⭐⭐⭐). Since the pricing is more expensive and cumulative charts require an additional intermediate step, but the overall package makes a better impression regarding what we need at bitstars, Geckoboard receives a rating of 4 out of 5 (⭐⭐⭐⭐).

To summarize, if you’re fine with Google Analytics stats and some custom data imported via Excel files or an Azure DB, go for Power BI. Yet, if you rely on the seamless integration of a wider range of external services, you’re clearly better off with Geckoboard—unless you wanna implement the integration of the different services’ APIs yourself in a DIY solution.

1 These are given in parentheses because an additional intermediate step is required.