A Better Agile Model

Although some consider Agile a lazy and unproductive approach to development, Bleum’s unique interpretation of the Methodology is achieving marked results for the company’s clients.

Nearly 76% of IT companies are currently claiming to use an Agile Methodology in their processes, with a high likelihood of even further expansion as interest remains high. Agile seems to be here to stay, at least in some form or other.

Some, however, are not so quick to jump on the Agile bandwagon. In his piece, Agile Software is a Cop-Out; Here’s What’s Next, Forrester analyst Mike Gualtieri disputes some of Agile’s core founding principles. In particular, he discusses why he feels that

“Business people and developers working together daily” is lazy.

Although Gualtieri’s article is now five years old, it eloquently puts forward standard objections to Agile – that are just as valid five years later as they were at the time. Bleum’s original response to this article from the time is below.

Can developers understand requirements without ‘hand-holding’?

Firstly, Gualtieri argues against the idea that it is impossible for developers to fully understand requirements without business people holding their hand. Secondly, the author stresses the importance of user experience in software development, but points out that business people are not necessarily the end user.

Therefore, requirements business people set may not actually be what an end user wants.

Ultimately, the author argues, this Agile principle results in uncertainty and mediocrity in production. While several of Gualtieri’s points are certainly true, he ultimately puts forth a one-size-fits-all critique of Agile. Individual experiences, however, refute his position.

At Bleum, we have been able to achieve great results by utilizing our own brand of Agile Methodology for development and client interaction. This includes a more holistic approach to the daily scrum, coupled with state-of-the-art technology which effectively brings Agile teams together around the world.

Bleum’s Agile Methodology Centers were created as a conduit of creativity and innovation. This includes not only real-time collaboration between a specific software  development team and business partners, but between offices, teams and verticals. The entire Center is set up with the best elements of Agile in mind, the most important element being the creation of a highly collaborative environment.

Wall-less work stations and video-conferencing facilities reach virtually into other offices to allow for ease of brainstorming, meeting and collaboration on the fly. Bleum has also taken the quintessential Agile sticky-note wall and created a bespoke software package to allow for real-time updates accessible between sites.

These are visible both on PCs and through the Center’s touch-screen wall. New notes can either be entered through a PC or by going up to the wall and entering information as you would on a mobile touch-screen device. This unique feature reduces the necessary frequency of meetings but increases the available time for innovation and collaboration.

The final elements in the Bleum Agile Methodology Center are user-experience rooms. These rooms are dedicated specifically to user testing, as Bleum recognizes user experience to be the most critical part of any development work.

How is Bleum’s approach to Agile countering Gualtieri’s main assumptions?

Gualtieri incorrectly assumes that Agile principles make all developers lazy, as most developers would “…rather stick with what they know.” In essence, this means that a constant reliance on business people stifles creativity and encourages a lack of domain knowledge. Bleum invests heavily in the domain knowledge of its associates. The company understands that domain expertise builds a better context around what a software project will accomplish.

Bleum’s continuous focus on advancing domain expertise is seen in its dedicated Centers of Excellence that manage and share industry-related knowledge. The added benefits of these Centers of Excellence include the ability to rapidly develop a thorough understanding of key business drivers and define competencies and assessments for ongoing employee development. This means that not only do Bleum’s developers fully understand business requirements without an acute reliance on business partners, but can better predict future business needs.

Gualtieri correctly points out that user experience is the most critical element in software development. What he does not agree with is Agile’s approach to achieving this superb user experience. He argues that those same business people who are setting requirements are not the end users. This means that there is often a “…dead reckoning…” along the wrong course.

Bleum’s Agile Centers offer up a more collaborative model allowing for opinions from third parties, including significant end-user testing. Bleum’s developers are well versed in white space and gap analysis, which enables them to take basic business requirements and create the best possible product for the end user.Instead of simply following requirement

Instead of simply following requirements set by a top global hedge fund partner, Bleum found gaps that led to the creation of a system that reduced trading latency for the firm by 400%. Bleum also analyzed critical gaps for an international non-profit partner, helping to shore up key legacy systems. The new framework has led to only two post-production defects during the entire three-year relationship, and a cost savings of more than $5 million for the charity.

Does Agile inherently encourage mediocrity?

The author’s most refutable point is that Agile Methodologies create uncertainty and mediocrity in development. While this may be true with the prototypical model, Bleum’s version of Agile has done nothing but encourage the most dynamic wins and acute successes for its clients. Bleum’s Agile Methodology helped to build an e-commerce site for a major global retailer. The site has handled, glitch free since 2009, an average of 1,000,000 orders per day. A major international software vendor has been able to accelerate new product releases by 600%, reduce rework by 46% and increase development productivity by 28% since collaborating with Bleum’s Agile team. One of America’s largest financial institutions worked with Bleum to develop core transaction system software that ran non-stop for 14 months. In addition, they were able to increase product delivery time, all of which have been delivered with a schedule variance of less than 2%.

Agile done right

It is clear by these examples that Bleum’s approach to Agile is working. Although Gualtieri is certainly no fan of the basic methodology, he should understand that with a few simple tweaks Agile can work remarkably well. Bleum’s method encourages collaboration and idea generation, going directly against Gualtieri’s version of the lazy Agile model. Instead of simply relying on an initial idea, forced and consistent collaboration results in a higher-quality product. In the famed words of Henry Ford:

“…if I had asked people what they wanted, they would have said faster horses.”

Bleum’s model takes these faster horses and makes them into automobiles.

Free Quality Consultation

Let our dedicated Quality Assurance team review your current processes and identify key improvement areas.


Resolve Issues Faster with Bleum’s JDA WMS Trace Tool

One of the advantages of Bleum’s long-term relationship with JDA (and before that RedPrairie) is the frameworks and tools we have developed to speed up implementations, support and customization work.

One of the proprietary tools we use the most across Bleum is the JDA WMS Trace Digger – a tool developed by one of Bleum’s JDA Solution Architects, Sam Ni, to analyze Moca and MTF traces.

I sat down with Sam and asked him to explain more about the tool.

Why did you develop this tool, Sam? And what does it do?

Sam: I developed this tool the first time I traveled to the US to provide onsite support for a client, around 2010. At that time I had to read and analyze a lot of WMS traces every day in order to identify the root cause of problems – it was so painful to analyze these traces without a tool with good features.

For example, for performance issues, how could I easily locate which command used the most time in a big Moca trace? I thought to myself ‘I just want to click a button to sort all commands by their performance, or search for a specific piece of information quickly’. These type of questions lead me to develop Trace Digger.


Fig. 1 – A Moca trace loaded into the tool.

Are there not existing trace tools you could have used? What are the benefits of the tool you produced?

Sam: Yes, there’s a commercial tool that’s very popular – LextEdit. I used to use this tool for traces myself, but it lacks a number of critical features. Some of the gaps with LextEdit are:

  1. Search is not very easy, with Trace Digger simply pressing the space bar loads a search box, and you can search only within the focus of the highlighted command if you want
  2. You can’t open multiple Moca traces simultaneously (for each Moca version, there is a corresponding version for LextEdit)
  3. Can’t open MTF trace, which means it’s hard to understand what’s happening on an RF device – with Trace Digger you can easily see the flow of RF device forms and the performance of each form
  4. Can’t handle tree nodes flexibly, e.g. to sort by performance
  5. Can’t handle big trace files (>500MB)
  6. Can’t split Moca trace by thread, which makes it impossible to fully analyze execution flow when a file is produced from multiple threads in a random order
  7. Can’t split Moca trace by size, which makes it difficult to work with large files, for example gigabytes in size
  8. Can’t bookmark an interesting node – with Trace Digger you can bookmark nodes and navigate them with simple keyboard shortcuts


Fig. 2 – A Moca trace sorted by performance. One command is taking nearly ten seconds to run and may need to be investigated.

How often do you use this tool? And in what contexts?

Sam: I use this tool pretty much every day in my work. It can be used by developers, support engineers, consultants – really anybody who needs to read and investigate Moca/MTF traces.

We’ve rolled this tool out across Bleum now – it’s used all the time across our teams.


Fig. 3 – A filter to show only SQL statements (select, update, insert, delete)

Are there any customization options?

Sam: Yes, there are. Mainly around setting Moca and MTF options, but also there’s customized highlighting options. This can make it so much easier and quicker to read through the files.


Fig. 4 – Color highlighting customization options

And what about the future for the Trace Digger?

Sam: Well, there’s still some opportunities to improve the GUI and add more useful features, so that’s something I’ll be working on soon. There’s always room for improvement!


Fig. 5 – An MTF trace loaded into the tool.

At Bleum we have worked closely with JDA and RedPrairie since 2003, working to support hundreds of customers with their implementation and support needs. Our standardized approach and toolkit, combined with our experienced consultants and developers that helped write the core JDA and RedPrairie code, makes us the perfect partner for your JDA projects.


For more information, reach out to us here.


What is DevOps? An Outsider’s Perspective

It seems like everybody’s talking about DevOps these days.

For a while now, it’s been one of those “next great thing” things. But in my role working in marketing, it’s not something I’ve really had to deal with, so I just mentally filed it under “some technical fad I don’t have to worry about” and ignored it.

That was until this week when we were reviewing our marketing collateral and realized that we don’t actually have anything that talks about the DevOps work we’ve been doing for clients here at Bleum. I decided it was time to shuffle the mental filing cabinet and move DevOps into the “you should really understand this” section.

Although I work in marketing now, I studied computer science at university, so I had a frame of reference to start from. I remember working on projects throughout my course and having to deal with what I assume is every developer’s least favorite thing in the whole world: code management.

What You Actually Do When You Write Software

To the non-technical folks, this is basically how writing software works:

  1. You write some code, let’s say, to add a new feature to an application.
  2. You test that it works as you expected it to. This is called unit testing.
  3. You test that it works with other parts of the code that it directly interacts with. This is called integration testing.
  4. You test that you haven’t accidentally broken something somewhere else in the system with your changes. So you test everything else, or at least the critical functions. This is called regression testing.
  5. You are now happy your code works happily with the system, so you release your code into the live (production) environment. Maybe these releases happen once a week, or once a month, or once a quarter, or “whenever everything is done”.
  6. If you didn’t manage to test completely (because you missed something or because your testing environment was a bit different from your production environment), there may be a defect. This means you might need to roll back your release to the previous version and go back to step 1 to fix it.

So, actually, a lot of the time was spent testing and building and deploying and not actually writing code.

If I’m honest, it’s one of the things that turned me off working as a software developer—the actual amount of time you spend doing the fun and mentally stimulating stuff can be surprisingly small, particularly at the start of your career.

Where Things Can Get Tricky

Now, obviously as you scale up the size of your development, things get more complicated. There are more interconnected pieces of the system, there are more surprising ways to break something that seems very unrelated to what you have been working on, and there are just more people all going through this process time after time trying to organize, collaborate, and not screw everything up for each other. You may have a team of developers, a team of testers, a team of network infrastructure guys, a team of people managing the databases, someone managing the builds and releases, and so on.

If this sounds like a recipe for problems, it’s because it is. And it’s not particularly surprising that a number of large and very expensive software projects have been a total failure. If you don’t manage this process well, you end up with a mess. Building complex software is hard.

A New Approach

DevOps seeks to create a new way of doing things by creating a collaborative process between developers, testers, system admins, DBAs, and anybody else who might be involved, and then streamlining that process. Implementing DevOps is about implementing both a culture and a toolchain.

One thing that DevOps loves is automation.

Look back at the steps above. What if you could automate steps 2-6 (and a number of other intermediate steps along the way, like creating a new build)? All that time spent testing and building and deploying could happen automatically. Sounds good, right? The diagram below shows an example:


As a developer, I’m pretty happy with how that sounds—less work for me.

As a systems engineer, I can spend more of my time working on optimizations and adding value, and less time on the monotonous release work.

As a tester, I can focus my efforts where I add value, not on doing the same tests over and over again.

With the automation comes another advantage: a dramatic reduction in the time taken to complete steps 2-5. And the reduction we’re talking about really can be dramatic.

Earlier I mentioned deploying weekly, monthly, or even quarterly, but DevOps lets you go faster. Much faster.

Amazon release code to their production environment every 11.6 seconds. This means that they perform more than 7,000 releases every day. Even Facebook, with the staggering breadth and scale of their global systems, release twice per day. That monthly release cycle feels pretty long now, right?

Making an Impact

But how does this change affect the activity going on earlier—the actual writing of code?

I asked our VP of Engineering, David Buck, to help me out by explaining his take on DevOps.

“The DevOps movement has afforded many positive changes for developers: fewer hours spent firefighting messy deployments to production, faster feedback on changes from the business, manageable check-in/build, less time wasted waiting for a downstream process, and far lower chance that a code change will become dependent on others’ code changes that may cause problems down the line. It’s no wonder that surveys show again and again that staff satisfaction and engagement levels are far higher when a company (truly) implements a DevOps program.”

David pointed me towards some research on this, so I went away and read the 2016 State of DevOps. You can get that here. It’s well worth a read at some point, so pop it on your Kindle or smartphone for your commute.

One of the statistics that jumped out at me from this report was not a technical statistic, but this one:

Employees in high-performing DevOps organizations are 2.2x more likely to recommend their organization as a great place to work.

From the 2016 State of DevOps report

So when DevOps is implemented correctly, everybody involved in the process seems to be much happier. This makes sense to me; people spend more time doing interesting, stimulating work, and less time on the mundane.

DevOps in Practice

I wanted to know a little more about the practical impacts of a DevOps team, so I spoke to our Engineering Manager who manages a DevOps team on behalf of one of the biggest online retailers in the world. I was really keen to hear his take on DevOps in the wild.

“The most important thing to realize about DevOps is that it is a cultural shift; it is primarily a change in mind-set. It’s about optimizing and streamlining the release process from every perspective, and it can be a tricky thing to get started. You need to work across multiple streams in the organization and be prepared to challenge existing mindsets and approaches. A small improvement in one process can have a massive knock-on improvement further down the line, so it’s important to take a holistic view.”

And what benefits has DevOps had for this client?

“The most obvious benefits are in terms of release cycles, productivity and defect density.

Firstly, right now our development teams are releasing every 2 hours. Before DevOps, we were following a monthly release cycle.

Secondly, focusing on resourcing, our original WebOps teams (including System Admins, Network Engineers, Database Admins, Helpdesk, Monitoring, Release, Storage and InfoSec) was comprised of 250 engineers; now around 100 engineers are supporting an even wider scope than before.

And finally, as the releases have become smaller and more frequent, we see far fewer defects and the turnover impact is smaller for bad fixes.”

Take Away

So, in summary, here are some things that DevOps can help bring you:

  1. More frequent deployments
  2. Significantly shorter lead-times
  3. Fewer defects
  4. Higher productivity
  5. Better quality assurance
  6. Happier employees
  7. Fewer sleepless nights

Sounds like magic, right? Obviously, with any paradigm shift, there are pitfalls, traps and implementation pain points, but it seems to me that by taking the time to do it right and truly embracing the changes, there are a lot of benefits to be unlocked from DevOps.

I’ve moved DevOps again in my mental filing cabinet after researching this article and talking to people across Bleum. It’s now in the “wow, this is pretty cool” section.

Mike has worked in various roles including data analyst, SAP specialist and training consultant over the last ten years. He has worked at Bleum since 2014 and currently works in marketing.

Connect with Mike on LinkedIn li_logo_128

Do you have an IT project planned in China? Click here to get a free project estimate from Bleum.

Watering the Plants: Is China Finally Embracing Software Outsourcing?

Outsourcing companies serving Western clients have been operating in China now for decades, leveraging China’s large talent pool to provide high-value and high-quality service.

But within China, there has historically been a reluctance to fully embrace the outsourcing model for local projects, says Bleum Senior Engineering Director, Dennis Wang.

“In China, when a customer asks a vendor to build a new application, they usually want to take on the maintenance work themselves. However, they often find out later that their IT departments don’t really have the skills or bandwidth to complete this work internally. They seem reluctant to outsource the maintenance to other companies, so many then look to ‘borrow’ resource from the original vendor in a staff augmentation approach”.

Things seem to be changing in the last 18 months or so, according to Dennis:

“More and more China-based customers are approaching us to provide maintenance and support, either as part of the original development engagement, or to ‘pick up the pieces’ from a lack of delivery from an internal team or previous vendor.”

“Chinese companies are becoming more accepting of the fact that their core business is not IT and that they lack the expertise to build, manage and monitor internal IT teams to provide a high-quality result. Maintaining a professional team takes time and money and China customers are beginning to realize that outsourcing this kind of work saves on both.”

So what are the main challenges faced when trying to support and maintain an application internally?

“Something we see time and again is an over-reliance on one or two key individuals internally. Combined with a lack of documentation and proper process management, the company is vulnerable when these people leave – leaving them with an expensive system that quickly becomes impossible to support and maintain. As a professional IT services company, this is a problem we can easily mitigate for, given our large pool of experienced people to draw from in Shanghai and Chengdu. It’s this assurance that’s starting to bring round China customers to fully embrace the outsourcing business model.”

Is some of this down to cultural differences?

“Yes, I think so. Chinese companies traditionally want to maintain more direct control than their Western counterparts. There’s historically been this mentality of ‘If I save my photos on my computer, I know they’re safe. If I save them in the cloud, I’m not so sure’. But we’re seeing this change now – people are embracing concepts like cloud storage as they’re starting to realize the benefits massively outweigh the risks.”

Chinese Technology

Cultural differences affect the outsourcing approach

What’s the biggest problem you see when approached by Chinese companies looking for help?

“There are three main things China CIOs are looking for:

Firstly, they want improved working efficiency. China CIOs are spending a growing portion of their budgets on support and maintenance and they grow frustrated with a lack of transparency and poorly designed processes.

Secondly, they want more flexibility around their staffing. If you need to scale your application twenty- or thirty-fold for a China shopping festival like Double Eleven (11/11) or 6/18 [China’s versions of Cyber Monday] how can your internal IT team manage this? They can’t! And what if you need support from a highly experienced software architect for just a few weeks per year? It’s clearly a waste of money to employ someone full time, and a one-off contracting engagement is often a slow and incredibly expensive process.

Finally, they seek guarantees around SLAs and technical capability. As a professional services company, we offer contractual guarantees around our performance. This helps CIOs sleep much easier at night.”

Is this historical reluctance to outsource just related to IT, or is it a broader thing?

“I often use this analogy: looking around our offices, I see many plants. But who will water the plants so they don’t die? Who will treat them if they become sick? What do I, an IT professional, know about plants? Nothing! That’s why we outsource it to another company. They can take care of the regular maintenance, and they have an expert who can come when a plant gets sick. It’s simple economies of scale and it makes perfect sense. I tell people, ‘if you can use outsourcing for your plants, you can use it for your IT applications.'”

Dennis has more than 15 years’ experience in the IT outsourcing industry in China. He holds a patent in DHCP network switching and in 2012 completed his MBA from Webster University.

Connect with Dennis on LinkedIn li_logo_128

Do you have an IT project planned in China? Click here to get a free project estimate from Bleum.

Simple Distributed Monitoring for your Trading Adapters

All leading Wall-Street funds run a number of trading adapters that connect various brokers and dealers’ trading systems to exchanges around the world in order to support their algorithmic or manual trading. Different adapters will be designed and customized in different ways, for example, many will utilize the FIX protocol, others will employ native protocols to an individual exchange.

So what is the best way to monitor the status of these highly-distributed adapters? How can you know if an adapter is down or is producing unusual data? And how do you control the performance impact of monitoring your performance-critical systems?

Trading adapters are deployed on different hosts which connect to each other through LAN connections. The monitoring system watches both the adapter application status as well as the status of connections to multiple internal and external systems. Your adapters probably connect to these systems through various types of middleware such as Tibco, ZeroMQ, RabbitMQ, etc. This can cause you monitoring headaches.

Bleum’s Solution

At Bleum, when we encounter this situation we develop an independent library as a common interface for the different types of middleware. All adapters contain several transports which are callback threads from the independent library. Our upstream systems cannot know what type of middleware they are dealing with so in order to monitor the connections with internal systems, the monitor needs to communicate with the independent library to gather and consolidate information from each middleware system. A major consideration of any monitoring system related to trading systems is that the performance impact on the adapters themselves should be minimal.

A major consideration of any monitoring system related to trading systems is that the performance impact on the adapters themselves should be minimal.

In order to reduce the project lifecycle and control any potential problems, we reuse the current system architecture as much as possible. Then, we build a monitoring agent that has a specialized transport between the adapters and the monitoring system. A customized distributed key-value store is used to manage all monitored data. The agent reads and keeps all LAN information for each adapter instance during its lifecycle. The agent can immediately identify if a transport fails to initialize or is disconnected for an unknown reason. The agent collects and summarizes all other transport information and health data, and sends it to the monitoring cluster key-value store. The message is JSON formatted which is simple and readable.

Distributed Monitoring Architecture

Each adapter sits on its own server between the order routing system and the exchange/broker system. The monitoring agent for each server reports back to the cluster, which aggregates data to be viewed by users.

It is important that the monitoring system has high flexibility in case it needs to support multiple platforms. For this reason, a common transfer protocol like HTTP is a good choice.

  • All messages come to the store through an HTTP service and, later, they can be easily referenced by the browser, shell script or a GUI.
  • If a port in any adapter is down or missing from the local network, the monitor will know this no later than a configurable timeout duration.
  • It is possible for an adapter to be administratively closed, even though the physical adapter is up. This is necessary for adapters from a business perspective as sometimes the remote side is not available (for example the exchange market is not open) or users want to set the adapter mode to allow only cancel requests (so that no new position will be opened).

All of the abovementioned events/statuses can now be monitored on the server side.

Security is also very important because the adapter information may be confidential. The server has authorization and authority components which help to divide rights and liabilities, increasing the usability of the monitor.

The Benefits

There are several benefits to the Bleum solution:

  • Great Performance

    The monitoring system works on a separate host and threads independently of trading flow. This results in extremely minimal performance impact.

  • High Security

    The store has a permission system, so only authenticated transports can be accepted. This prevents a denial-of-service (DoS) attack. Moreover, the store is capable of authorizing different access levels for each user and restricts which transport can be viewed and whether the user has the right to amend the information.

  • Fully Customizable

    The solution is highly customizable and has abundant configurable features such as support for different environments; regardless of whether users work on an interfaced system or only have a command line, users can still check the monitoring system through different tools.

  • Scalable and Flexible

    The JSON message is customizable for both the adapter and server side monitor. If any new feature or new transport type needs to be added to the system, it is easy to extend the system to support this.


Monitoring real time trading systems is vital.
You need visibility of existing performance to provide assurance, as well as being able to identify bottlenecks to target your development efforts.

With a scalable, flexible system, that has a minimal performance impact on adapter operations, you can collect the valuable data that you need to drive improvements in performance and reliability.


How to Turn your Manual Testers into Automation Testers

As software projects become larger and more complex, how can you ensure that you maintain a high-quality delivery every time? How can you limit the number of defects released into your production systems?

That’s why it is important to have dedicated testing teams, to ensure that release code is comprehensively and thoroughly checked against a large number of possible scenarios. The job of the tester is often not glamorous, but it is vital to the success of any project. When you have a team of strong, experienced testing professionals, you are already well on your way to shipping defect-free code.

However, when it comes to large, complex projects, the testing load can often grow quickly. If the development methodology is agile or iterative with frequent releases, the amount of regression testing can soon swamp the testing team.

So what’s the solution? The best idea is to automate as much testing as possible – freeing up the time of your testing team to focus on key areas such as critical system functionality, usability testing and testing new features.

However, while fine on paper, there are a number of practical challenges when you start to move towards automation testing.

“I don’t have time to develop automation testing”

Automation testing is definitely not the right fit for every scenario. It is best utilized for repetitive, core testing tasks – the things that need to be regression tested for every release, for example.

The initial work to develop the testing scripts and framework needs to be carefully assessed and compared against the rewards. You’re looking for an effort curve like the chart below, where we can clearly see the initial effort required to create the automation test is paid back in future releases. If the initial ‘hump’ to develop the automation testing is too large, the number of scenarios to which you can apply it is reduced.

graph automation testing vs manual testing effort

“I want to use automation testing, but my testers don’t have the coding experience”

This is a common problem in many development projects. The mindset and skill set of the tester and developer are very different – a great tester is not necessarily a great developer and vice versa. Your manual testers may simply lack the experience (or confidence) to take on writing automation scripts.

The Solution

A solution that can break down both of these barriers is an automation framework that allows your testers to create automated test scripts through a simple Excel spreadsheet without having to write any code. A tool that allows you to deploy automated testing scripts quickly to reduce the development ‘hump’ we saw in the chart above.

At Bleum, we have developed such a tool, and find it valuable on a number of projects.

A simple interface allows the tester to quickly and easily generate automation scripts.
(Chinese language version shown)


  • Easy to use

    No additional coding or scripting is needed once the framework is set up in the testing environment. For those manual testers who don’t have much experience in automation testing, they only need to enter data into an Excel spreadsheet and then click a button for the framework to generate the test scripts. The data captured in the Excel sheet includes all testing steps, the inputs, parameters and the expected result for each step.

  • Saves time

    Once the scripts have been generated and executed, the tester can be released to work on other tasks and come back later to find the testing results. One Excel sheet can create thousands of test cases, all of which can then be run automatically.

  • Reusable

    Once the testing data is saved in Excel, it can be applied to multiple automation testing tools such as QTP and Selenium. Testers don’t have to prepare the testing data again and again, which minimizes the possibility of manual error.

  • Saves money

    Automation testing requires testers to have very strong skills in coding and debugging, meaning experienced automation testers can be a rare commodity. However, with an automated scripting framework, there is no requirement for any extra coding or scripting once the framework is set up and running.


If you want to empower your testing teams and embrace the benefits of automation testing, deploying a “no scripting” test automation framework is an excellent choice.

Contact us today to organize a demonstration of our “no scripting” test automation tool.


Combining the Best of Agile and CMMI

Like politics, software development seems to advance according to Hegel’s dialectic.

Many see Agile as the culmination of the software engineering experience, making it the perfect process for all human endeavors even beyond the software development field for which it was created. We are probably at the second stage of the dialectic for Agile and will move on to another state, one that takes the best ideas from Agile and mixes them with other good ideas to arrive at a new synthesis.

Hegel’s dialectic consists of three stages:

a thesis, giving rise to its reaction; an antithesis, which contradicts or negates the thesis; the tension between the two being resolved by means of a synthesis.[1]

The Agile Antithesis

Agile may be seen as a reaction to the weaknesses of Waterfall, the previously dominant management process, which is most often, yet incorrectly, associated with CMMI. It is argued that while Waterfall may work well for building bridges, where requirements are known and surprises are few, software development is, by its nature, more an act of discovery. Previous practices like CMMI are seen as heavyweight, requiring too much documentation and too many measurements.

As more people apply Agile and Scrum to more situations, its limitations become clear. Organizations often find that when they switch to Agile, their projects tend to go on forever and they frequently end up with technical “surprises.” Even when teams are able to build functionality fast, the lack of documentation can make a company beholden to the developers who built the system as only they know how it works.

CEOs of companies who have bought into the pie-in-the-sky dreams of internal Agile proponents increasingly feel bamboozled as the latest fad continues to leave their companies in the same position: suffering with unpredictable schedules and technical surprises that result from difficult and risky issues being ”put off” sprint after sprint so that teams can report their continuing progress.

Proponents of Agile built their case by pointing out high profile failures of past methodologies. However, the almost universal reaction to high profile Agile failings, like the website for the Affordable Care Act, healthcare.gov, is to say that the process must not have been implemented correctly. In a famous YouTube video, Ken Schwaber, one of the pioneers of Agile, says that if you have a poor team with bad engineering practices, Scrum will generate crap for you time after time.

The ‘Silver Bullet’

silver_bullet_1At Bleum, we see many companies that try to implement Scrum in many different ways; some successful, most not. Agile was supposed to be the answer to previous difficult-to-implement processes, but that did not seem to work out in real life. I would be surprised if five percent of our customers implement Agile the way it is “supposed” to be implemented.

If you poorly implement Agile, Waterfall, CMMI or any other process, you are bound to get poor results. In my opinion, it would be best for organizations to start there rather than looking for the next silver bullet that will magically solve all of their implementation problems.

That is not to say that they shouldn’t use Agile. While plenty of successful projects were implemented before Agile came along, including landing a man on the moon, Agile does have value when used in the right place and implemented correctly. The idea of small, productive teams breaking work up into small iterations and delivering frequently is a helpful one. The continuous build concept wasn’t invented by Agile but is often part of it and helps to dramatically reduce rework downstream.

Likewise, the control and precision that comes from a data-driven paradigm like CMMI has enormous value to help organizations improve their performance over time. Expending resources on things like documenting designs and test cases may not help a current project finish faster or better, but it is crucial where a production system is going to need to be supported and enhanced over a long time.

How to Improve Agile with CMMI

Hydra - Bleum's project management and tracking tool gives clients full visibility of the status of their projectOne good way to marry Agile and CMMI is to use tools to automate the collection of performance and technical metrics. Tools like Bleum’s Hydra Code Quality, Sonar, and CAST can provide a snapshot of the quality of the source code and enable some sort of apples-to-apples comparison of progress being made on quality.

Another important process step that many lose but should consider returning to is formal reviews. Reviews are quality gates that take advantage of a second set of eyes to make sure that as we build, we build on a solid foundation. Review activities can be measured in terms of whether or not they were planned, whether or not they were conducted , how much time was expended, how many issues were found, and how many defects escaped. This gives a holistic view of the quality of the reviews. Besides being a quality screen, reviews also serve as mentoring and coaching opportunities for inexperienced developers.


Agile methods are strong when the teams take ownership but tend to be better at completing functionality while being prone to inefficient architectures and a short-term mentality.

By bringing in organization level measurements around the quality and productivity of the work being done and by ensuring that reviews become formal, (i.e. documented and utilizing evolving checklists), the technical capability of all team members can be raised to a predictable level.

What are your experiences with Agile and CMMI? Have you had success combining them for your projects? Share your thoughts in the comments section below.


Top 5 Customer Benefits of CMMI Level 5

Last week Bleum was re-appraised for the Capability Maturity Model Integration (CMMI) at Maturity Level 5.

This was the fourth consecutive time we’ve achieved CMMI Maturity Level 5, since our very first CMM assessment in 2005.

We’re really proud of that achievement.

Bleum Celebrating CMMI Level 5 Award for Fourth Time

Some Bleumies celebrate!

But what does it actually mean?

How does a CMMI Maturity Level 5 appraisal actually translate into real value for our customers?

Let us explain, but first…

What is CMMI? What’s the benefit of Level 5?

The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization’s software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes.

The focus for Maturity Level 5 is on continuous process improvement, so that the impact of new processes and technologies can be predicted and effectively implemented when required.

The CMM Integration (CMMI) project was formed to sort out the problem of using multiple CMMs. The combination of selected models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement.

So that is CMMI. Long name; great model!

Why is CMMI important?

In short, it means you get a high quality, timely, predictable delivery that enables the best possible ROI.

But more specifically, let us explain how our CMMI Level 5 approach has helped our clients in five different ways.

1.  CMMI Ensures Better Quality

One of the key concepts of CMMI is repeatability.

By designing processes that are easily repeatable, and harnessing technology to do so easily, quality can be maintained at a consistently high level throughout the project.

This means a high quality delivery for our customer, with a low number of defects.

Zero Defect Development graph - Bleum achieves more than half of all projects at zero defect

Bleum’s zero default project percentage over the last nine years

2.  CMMI Provides Better ROI

Because fewer defects make it into the production release, they cost less to fix.

And because defects are resolved earlier in the development lifecycle, they have less of an impact overall.

Defects found earlier in the development cycle are much cheaper to fix - using CMMI means defects around found earlier, and therefore fixed cheaper

The secret to fault-free releases: find defects earlier in the development cycle

At Bleum we’ve calculated that defect removal is 72% more expensive in the rest of the industry than it is for us. That means that for every $100 spent on defect removal at the industry average, due to our CMMI approach it only costs our customers $58.

Productivity is a key performance indicator (KPI) both for us and for our customers. Because a focus on improving productivity leads to direct increases to your ROI.

3.  CMMI Enables On Time Delivery

Our customers are always striving to reduce their time to market. By using CMMI, we can ensure that we can quickly and accurately respond to their business requirements, and guarantee an on-time delivery.

Our schedule variance for the last two years (after re-baselining for change requests) is zero percent

And for agile projects, our completion rate (percentage of story points finished per sprint) is 90 percent.

4. CMMI is Flexible to Fit Your Needs

It can be difficult to combine agile principles with the more formal, ‘heavy’ requirements of CMMI.

How do you maintain your quality and delivery through an agile development process?

How do you ensure the iterative and quick-reacting benefits of agile are not lost through the detailed documentation requirements of CMMI?

At Bleum, we researched how we could reconcile agile with CMMI and as a result we created the Agile Maturity Model (AMM). The AMM allows us to monitor and guide projects towards a high level of agile maturity, as well as a high level of CMMI maturity, ensuring both a quick and a high quality delivery.


Automation Tools

As well as the Agile Maturity Model, we have also worked hard to automate CMMI.

By using internally developed tools such as Hydra and Omnipresent, it is easier for our teams to quickly respond to requirements changes, which means we can continue to support our clients’ needs, even in very fast-paced markets.

Bleum is on the leading edge of providing full transparency into outsourced operations. Hydra/Omnipresent provides our partner-clients with a real-time, 360° dashboard view of activities, KPIs and resource data. Regular joint-review of KPIs enables better decision making for IT executives, project managers and developers alike.

Hydra - Bleum's project management and tracking tool gives clients full visibility of the status of their project

Hydra – Bleum’s project planning & tracking tool

5. CMMI Encourages Continuous Improvement

For a mature software company, optimization is never complete. And this is one of the most important aspects of a CMMI Level 5 certification – the ability to continuously drive improvement.

At Bleum we drive process improvement throughout each of our projects, but also, we drive improvement into the organization itself. Best practice is shared across the whole organization and drives future improvements for all of our customers.


It is not easy to be appraised at CMMI Level 5, but it enables us to deliver great benefits to our customers.

That’s why CMMI is so important to us.

So the next time you’re in the market for a new IT partner, make sure they have CMMI Maturity Level 5.