Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Are you really agile? Probably not. Here's why.

Martin Heller Owner, Martin Heller & Co.
Is your organization really agile?

The Agile Manifesto (2001) proclaims 12 principles for developing better software. Not surprisingly, most software development organizations, having been thoroughly burned by failures of waterfall model projects, say they've adopted these principles. But have they? In my experience, lip service is the rule, while true agile software development is the exception.

How can you tell if your organization is really walking the walk and not just talking the talk? It all comes back to the Agile Manifesto. Using eight of the 12 principles, let's look at how well other organizations measure up, and you can compare it to what's happening in your own organization to see where you stand.

Continuous and frequent delivery

Two key principles are "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software," and "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale."

Easy, right? What could go wrong?

How about this scenario: Your development is organized into two-week sprints. At the end of the two weeks your product won't build. On investigation, you discover that some of the developers didn't understand the difference between git commit and git push, so they didn't update the common repository, even after their code passed all tests. To make matters worse, some developers never bothered to git checkout the project after the beginning of the sprint because they didn't want to merge other people's changes while they were "in the flow."

So now tell me, are you really agile?

Be ready for change

You think you have this principle down: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

But what if, two weeks before your Windows desktop product is due to ship, Microsoft issues a security patch that keeps a key function from working. You've already slipped your schedule twice, and management not only insists that you meet the current deadline but won't authorize overtime for your team. You ship without modifying the feature and tell operations to roll back the Microsoft patch.


Take a team approach

The Manifesto goes on to state that "Business people and developers must work together daily throughout the project," and that "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It's all about communication.

Then there's the case of the business sponsor (customer) of a project who is in New York City and has marketing meetings for roughly six hours a day, including a mandatory end-of-day meeting each day with the CEO. Meanwhile, the developers are in Hawaii. The customer emails the development lead every two weeks, complaining that the software is buggy and late, but the customer is almost never available for live feedback over WebEx and has never come to Hawaii.

That's no way to troubleshoot your problems.

Go steady

Another principle says that "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Constant, that is, unless the project has slipped an entire month, and management has declared a "death march." If the new shipping deadline isn't met, the company risks losing its customers, so the development team is expected to work 12 hours a day, six days a week, to get the product out the door.

That's agile?

Recognize Real Success

You might take to heart the idea that "Working software is the primary measure of progress," or that "Simplicity—the art of maximizing the amount of work not done—is essential."

But what if your manager uses a different measure? Suppose he does your quarterly performance reviews based on the number of lines of code you have written?

Are you really agile?

If your organization fails on all eight of these principles but claims to be agile, it's time to post the Agile Manifesto in your cubicle and get your resume up to date. If it fails on only one or two principles, perhaps there's a way to improve the organization. The final principle in the Agile Manifesto is worth observing: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Keep learning

Read more articles about: App Dev & TestingAgile