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.


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.