Posts

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.

 

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.

Takeaway

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.

free_demo_automation_tool_1

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.

Takeaway

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.

CTA_Free_Project_Estimate_v1

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.

Takeaway

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.

CTA_Free_Project_Estimate_v1

Offshore Partners should have Distributed Agile in their DNA – We Do

 

Agile emphasizes that all team members should be in one location for daily meetings, requirement discussions, designing, coding, testing, etc. Along with the trend toward agile becoming the predominant development methodology for software development, it’s more and more common to find project members located in different cities or even different countries.

When team members are in different locations, the primary challenge is the lack of face-to-face communication. Time-zone issues can also arise when team members are in different countries, and cultural differences can also add to the challenge.

One example we can discuss is a team that has used agile methodology to work for a Fortune 500 e-commerce website for over four years. Located in Shanghai China, our team works with a US team (California) and an India team (Bangalore) on software new feature development, production issue fixing and production support. Team sizes are roughly similar in each location and this is the case for more than 10 module teams. We have frequent engagement and collaboration with the other module teams, and under this model, we face all three challenges of location, time zone and culture.

Overcoming the challenge

To manage these challenges, we adopted the following practices:

  • Over-communication

    You can never over-emphasize the importance of communication when your team is distributed across locations. We have daily standup meetings with the US and India teams. Everyone talks about what he or she has completed yesterday, what he/she is going to do next and the impediments blocking our progress in the daily meeting.

    We’d always rather over-communicate than have a lack of communication. [tweetthis]When it comes to distributed agile, it’s always better to OVER communicate than UNDER communicate[/tweetthis]

    At the end of each day, everyone sends a daily status summary to the Scrum Master. This enables the Scrum Master to understand the work progress status of employees in the same time zone or opposite time zones (and not available at that time). This allows him/her to lead working associates to adapt immediately to changing circumstances and requirements.

    Bleum teams use both audio conference calls and screen sharing meetings such as GoToMeeting™ or video conferencing to facilitate communication. We have found it’s very useful for us to smoothly perform sprint planning meetings and review meetings.

  • Flexible Timing

    As teams are located in different time zones, it’s critical to identify a suitable meeting time for every time zone. It’s impossible to find a time that everyone feels happy about, however, a time should be identified that everyone can accept.

    Team members must be flexible.

    California is 15 hours behind Shanghai and Bangalore 2.5 hours behind, we chose to hold meeting at 11:30am Shanghai (8:30pm California and 9am Bangalore). The US team has to sacrifice every evening and the Shanghai team sometimes has to postpone lunch, but this is the time everyone has accepted.

  • Hybrid Model

    From time-to-time, a few engineers from the Shanghai team travel to California where the Product Manager and Scrum Master are located. These engineers spend half-day on California working time and the second half on Shanghai time communicating with the team there.

    Occasional on-site visits, targeted at specific critical project phases, offer a ‘best-of-both-worlds’ solutions

    This is a hybrid model and it is very effective and useful to get correct and detailed requirements through and allows for product managers to either confirm or give comments on requirement completion.

  • Dedicated Person for Production Support

    Teams not only work on new feature development but also take responsibility for production support, especially during Black Friday and Cyber Monday.

    We have found it is most effective to assign 1-2 dedicated engineers to provide support service.

    They join new feature development when no support tickets are assigned, and are the only resources to work on support if support tickets come in. This approach enables their peers to focus on new feature development and support resources to accumulate support knowledge and practice.

  • Continuous Integration

    Continuous integration plays an important role in guarding code quality especially under a distributed team model.

    Bleum has a dedicated team whose main responsibility is to checkout code from SVN, compile code and run automated test cases every day.

    If an issue occurs, they will identify who caused the issue. Everyone, no matter their location, has the responsibility to fix their own code and get it to pass compile and auto test as soon as possible once they receive a phone call from the support team. As teams are located in three locations, this becomes a very important part of the process to guard code quality.

  • Knowledge Base

    Team knowledge placed into the knowledge base system includes: requirements, release plans, design documents, domain knowledge, test cases, testing accounts, API documentation and more.

    The best practice is for all teams to maintain all knowledge in one system. [tweetthis]The secret to KM with global teams? For ALL teams to maintain ALL knowledge in ONE system[/tweetthis]

    It’s accessible not only to the US teams, China teams and India teams but also to the peer function teams. It ensures that everyone has the same understanding about the system and it also shortens the learning curve for new team members.

Consistent over time

The team has adopted these approaches in agile projects for more than four years, and successfully managed the challenges of distributed teams. The US team, India team and China team have collaborated with each other well and delivered many important functions, during which time the site revenue doubled. The biggest impact has been on delivery speed.

Before the team adopted agile, it performed a release every two months. After adopting agile and the above practices, the team now performs a release at the end of each sprint. This means that delivery speed has improved by four times while keeping the same quality level.

Over to you

How do your teams navigate the sometimes complex issues of multiple teams in different time zones and cultures?  Do you have any additional thoughts on this topic?  If you are just scratching your head as to how to improve your team’s performance, reach out to us through the form to the right. We will help.