Making the World Round Again with Agile

scrum-cycle-peter-saddingtonOnce upon a time, the world of software development was flat. The customer had a product to be developed, which they handed off to a vendor, who handed it off to workers. In this linear process, odd schedules and isolated teams were the norm, and any true collaboration was limited to a few hours a day at best. The bible of instruction was a Requirements Document that stayed the same even as months passed and the software evolved in unforeseen ways. The unfortunate byproduct of this arrangement was a distance in time, geography and understanding – and the final product often suffered as a result.

Then agile came along, shook things up and gave outsourcing what it needed – a way to make the world round again. With agile, development is collaborative and flexible, rising from a foundation of frequent interaction and fast-paced response cycles. Instead of relying on an up-front set of instructions and working through testing and revision cycles at the end, teams work with customers throughout the cycle to optimize the design in real time. The result of this streamlined model: an accelerated road to market with a product that’s perfect the first time.

Consider this example:

Let’s say an online shopper needs to enter a credit card number to place an order. In our flat world model, that’s all we would know – we wouldn’t know what the screen should look like or what other data should be collected. The odds are high that we’d turn in a product very different from what the customer envisioned, and have to make expensive corrections. But in our round world model, we’d start with a well-rounded user story that would help us flesh out a more accurate, satisfying product. We’d also repeatedly meet with customer to collect their feedback and refine the product based on their ideas. The end result would be software that matched the customer’s vision.

So just how do you make this new world happen? Collaboration is key – that much is clear. However, it’s also important to know that this round world doesn’t just happen laterally, but longitudinally. Read on for the best practices that can turn your software development world round again.

Tactical Execution – Lateral Agile


Like we said above, in the flat world of waterfall development, customers hand the Requirements Document over the fence to the provider as a static directive that lays out a problem to be solved – and the two businesses don’t intersect again until the vendor hands back complete, working software. As you might guess, that leaves more than a little room for guesswork and assumptions. Agile, however, relies on frequent communication and multiple interactions per day to keep the project on course. The teams clarify what will be built, answer questions and request feedback. We synchronize the communication rhythm and ensure that all team members have tools like Skype to enable immediate conferencing.

The difference is colossal. Imagine building a house in the United States; normally the owner would provide regular feedback on the flooring, shower tiles or cabinet finish so the builder could rectify mistakes on the spot. But if the owner only saw the house once it was complete, correcting all of the wrong features would be a massive and costly endeavor. This is the exact fate good agile communication prevents.


Even when you’re working on a project within your own company, smooth collaboration can be a challenge. When a project involves a customer, a vendor and an outsourced team, the potential for communication breakdowns and lost opportunities are even greater. For this reason, smart customers and vendors recognize the wisdom of using workers who are close by. Using an Indian team might make the most sense for a company in that time zone, while using a Mexican team could be the best choice for an American business. The physical proximity can lead to more efficient supply chains, faster delivery times and easier meeting access, something not to be overlooked.


Agile is all about staying attuned to user stories and customer needs, so we can build the most relevant, useful product possible. And the way we do that is through meetings. Daily huddles help us identify potential problems, reduce email, eliminate roadblocks, and incorporate customer feedback. Instead of disconnecting from the customer during development, we invite them to experience the software features in progress and provide feedback for corrections and enhancements. Not only does this lead to greater customer satisfaction, it saves time and money correcting errors post-production.

Strategic Choices – Longitudinal Agile

Cultural compatibility.

While outsourcing models involving offshore teams may work for some projects, agile teams benefit far more from using teams in culturally relevant locations. Near-shoring has become a popular model for agile development for many reasons; it offers the considerable cost savings of outsourcing while eliminating time zone difficulties and language barriers. Instead the team works with developers that live in complementary time zones and share a similar culture. The result is deeper engagement, tighter collaboration and increased profitability.

Shared agile understanding.

To design the best possible software, all players on an agile project should ideally operate as one team – and this is best accomplished by utilizing a shared framework that defines roles, processes and systems. All teams should observe the same daily, weekly, monthly and quarterly operational rhythm, as well as a common vocabulary; when you consider the potential for different definitions between team members or with customers, the need for precision become clear.  Taking the time to clarify coding terms or testing stages can eliminate misunderstandings and enhances communication, ensuring that the teams grasp the customer’s expectations.

There’s no doubt that agile has simplified and accelerated the world of software development. By adopting agile methodologies, teams can reconnect with their customers and each other for cost savings, faster time-to-market and greater productivity. And by weaving communication and collaboration into every step of the project cycle, agile teams can offer their customers the most accurate and perfect product possible.

[Cliff Schertz is the founder and CEO of Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services know as Tiempo Quality System™ (TQS)that transforms the way their products are developed, deployed and supported. For more than 25 years, Mr. Schertz has been leading and growing successful technology service companies, enabling his customers to achieve superior performance, high customer satisfaction and profitability.]

3 Replies to “Making the World Round Again with Agile”

  1. Nice article. Its difficult to disagree with many of your points but I think you are painting a rather idealistic world.

    Your description of the waterfall scenario serves as a good contrast to the ideal world of agile. But is either that realistic?

    I’ve worked in many different roles, agile and waterfall projects. Understanding requirements and unambiguously specifying desired behaviour is always a challenge whether you are writing User Stories or long word documents.

    Good developers, good business analysts will always save the day. Even in the face of bad requirements they will do their best. They will try to really understand what the business needs. They will challenge the reason for the requirement.

    In my view software development will always be a craft. And good crafts man will always use the right tools. As longs as customers of the craft insist on looking at it as an assembly line we will get poor results.

    Your building analogy is powerful. If we tell an architect we want a 5 bedroom house and provide no more information, we cannot expect to get the house of our dreams. But collaborate with him in his ‘professional craft’ and you have some chance.

    1. Thanks for your reply! I agree with you totally…

      It’s funny (sad?) / (interesting?) how much work gets done because of “heroes” that need not be heroes to save the day.

      IMHO the best way regardless of medium is to ensure a shared understanding of what the heck they want.

Leave a Reply