Channels ▼


Hybrid Software Solutions With Agile/Kanban

Essential in a Distributed Environment

One of the common misconceptions about adopting Agile methodologies is that they won’t work for global organizations. And, while most Agile implementations were first conducted in colocated development environments, since then a number of companies have successfully adopted these methods within large distributed teams.

In fact, at CDC Software (the company where I work), our more than 60 development teams are spread out over 8 countries and 14 locations. This type of distributed environment demands even greater collaboration and communication because of the high levels of communication and daily meetings required with Scrum.

Kanban Keeps Cloud Application Projects Moving

Another important element for consistently delivering quality software in a hybrid model is visibility into the progress of development projects. And that’s where Kanban can help — especially when the development team and project stakeholders are dispersed.

Kanban (which means “signboard” or “billboard” in Japanese) is a concept related to lean and just-in-time production. It’s a scheduling system that indicates what is being produced and where in the value stream it currently is, allowing you to visualize the work and deal with constraints. By having real-time visibility into progress, managers can understand what has been accomplished while concurrently looking at the remaining elements in the backlog. With that information, they can then make an accurate assessment about delivery. This enables development teams to stay on top of backlogs and ensure that they are elaborating stories in a timely manner.

This is especially important when working with cloud-based applications, because with SaaS, it’s not only about developing the software, but also about deploying it. So, while the development itself can still be performed using Scrum, there are other factors to be managed differently. For instance, you also need to decide when to deploy software to the test environment, when to deploy to the production environment, when to conduct upgrade routines and so on.

A Kanban board enables you to keep these pieces moving and monitor things such as where you are in the process, what pieces have made it to the production environment and what your cycle time is to deliver finished software. Just as important, it helps you identify where your bottlenecks are so that the team can focus on what’s causing them and get them resolved.

Benefits of a Combined Agile/Kanban Approach

Employing Agile and Kanban methodologies in the development and maintenance of hybrid software solutions is a powerful one-two punch that can yield tremendous business value while creating much more rewarding work environments.

Faster Release Cycles. For instance, at CDC Software, we are now consistently launching three-month service packs rather than the 36-month releases we were delivering prior to adopting these approaches.

One notable example of this improvement occurred recently. Our development team was working on a product that was expected to take 24 months to complete. After eight months of development work using both Scrum and Kanban, we had a workable product. It wasn’t where it would have been had we worked on it for 24 months, but it did not need to be. Our sales team took a look at what we had created up to that point and determined that it was definitely a very marketable product.

They had seen the progress every step of the way. They had provided feedback every two weeks over the course of those eight months. And they felt comfortable asking us to ship what we had.

Not only that, but they also realized that many of the features and functionality they had originally requested — which hadn’t yet been added to the project at this point — were no longer as important as they had once thought. Instead, they suggested we spend the remaining project budget in other areas that, based on recent market developments, were now much more exciting and marketable.

Reduced Waste. Not only were we able to quickly change direction, but we also saved a tremendous amount of development expense that would have had little impact on the product’s marketability. Instead, we were able to shift that budget to areas on which we could capitalize.

Had we been using a waterfall approach, we would still have been writing the detailed design for what we had planned to do, which was certainly going to take 24 months to complete.

Greater Focus. Scrum and Kanban also keep the development team focused on what matters. With Scrum, having to demonstrate the product every two weeks means no one is working in a vacuum. The requirements are clear and the deadline is set. This prevents engineers from getting carried away adding “cool” features that no one asked for.

This doesn’t mean that creativity is discouraged; in fact, ideas are highly encouraged. But Agile requires that, before action is taken up on any idea, each must first be written out as a story so stakeholders can evaluate and prioritize them. This keeps the project focused and on track.

All in all, we’ve been able to reduce development costs by 30 percent while also lowering product hardening from 30 days to three days on some products — all as a result of implementing these practices.

Improved Response to Market Demands. Finally, let’s face it: 24- and 36-month delivery cycles are unsustainable — especially in an environment where major new technology is being rolled out every few months.

Furthermore, these long cycles encourage the wrong behavior. When stakeholders know it’s going to take 36 months to deliver the next version, they will invariably submit every possible requirement they might need over the next three years. Conversely, when stakeholders can view and assess completed work every two weeks, they can be much more conservative and targeted with their requests.

Implementing Agile/Kanban Successfully

Implementing these pull methodologies involves tremendous change — change that is typically met with some degree of resistance. Here are some strategies for increasing the chances of implementation success.

Start Small and Use Pilot Teams. First, it’s important to start small and not try a big-bang approach. Going from zero to 20 Agile teams is a recipe for disaster, no just due to change management factors, but also because of the fact that Agile is an adaptive empirical process designed to adapt to fit your culture, team and work environment.

Instead, create small groups and start with pilot teams. This allows you to knock out the kinks, get it working in a more controlled fashion, and build excitement both within the pilot teams and in other team members as they see their peers having fun.

Educate. To be successful, pilot team members need to be educated on all the benefits the company will gain from this new approach. Just as important, they need to understand how they will personally benefit through improved communication, less friction within the team and with stakeholders and greater product quality.

Involve the Executives. Adopting Agile methodologies can make some executives uncomfortable because it shifts some control to the development teams. This is why it’s critical that key executives are involved from the beginning — so they can better understand why reporting mechanisms and process changes are a must.


One thing is for certain: a hybrid on-premise/cloud-based product line requires new approaches to developing, delivering, and maintaining software. By using proven practices from lean manufacturing, we can create much more rewarding work environments while improving time to market and increasing product quality.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.