Have you noticed how some organizations claim to be agile, but when you peel back the layers, they’re really a waterfall shop with aspirations of agility?

As a consultant, when given the choice, I usually chose agile over waterfall methods. However, we often end up using the methodology that is in place at the client site… and most development organizations are still waterfall shops.

So why do so many organizations aspire to become agile, yet are still only implementing a few aspects of it? Most likely, they’re not given enough time to plan the process of becoming agile. Or, it may be because agile processes are usually introduced by the development community in a bottom-up style that isn’t understood or appreciated by the top-down management. The result: Many teams end up implementing a hybrid methodology.

Hybrid approaches to solving problems are not all bad.

Let’s call waterfall shops that either aspire to be agile or are in the transition process “WetAgile.” Individuals can also be described as WetAgile, too. For example, perhaps you’re an aspiring agile guru doing so many waterfall projects that you find yourself implementing agile practices that you most believe your waterfall team can easily embrace.

When I look back at some of my own most productive teams, they all had one thing in common: Each project team was using one or more agile processes.

For example, we recently completed a large electronic content management implementation for a client. The team consisted of highly skilled Java developers who had just completed product training. Soon after their training class, the developers moved on to their programming tasks, but they had difficulties figuring out how to wire it all together. They quickly discovered that working together was faster than working independently.

Although I would like take credit for telling them to work together, it was something that they tried on their own. They started with one developer searching the product knowledge base while the other developer implemented code fragments. Within a few days, they were sitting side-by-side, coding and refactoring each other’s code.

In the end, paired programming techniques allowed them to complete all of their deliverables faster than if they had worked independently of each other. I quickly became a proponent of paired programming and have since encouraged subsequent project teams to give it a try.

The traditional approach to bringing a project newbie up to speed is to ask them to read technical documentation and ask them to check back a few hours later. Hands-on learning via paired programming and having someone available to answer questions is far more productive in the long run because most of us learn faster by doing than by reading.

Short development sprints can also be very productive. Too often we start a project by trying to estimate when it will all be done. Since I’ve seen so many projects slip two to three months beyond their original estimated completion date, I have become a fan of short sprints, or bite-sized chunks.

Short sprints include regular development builds and releases that continue until the business sponsor agrees that the cycle is complete. Depending on the size of the project, weekly development cycles (or in some cases bi-monthly releases) are preferable. These short sprint cycles are easy to implement and readily embraced because progress is transparent and large projects can be broken down into bite-sized chunks. And most importantly, if you’re fully engaging the business in the development cycle, the immediate feedback is invaluable.

Continuous feedback between the business and the project team provides visibility into the progress of the project, and it is also instrumental in course-correcting the team. We’ve all seen what happens when feedback doesn’t exist: “That’s what I asked for but not what I wanted.”

Once down the agile path, it doesn’t take long to start appreciating “done/done/done.” The first time I heard done/done/done, I thought a friend invented it. However, I later learned that it’s a common technique that really resonates with development teams.

“Development Done, QA Done and Business Done” is easy to explain and something that everyone understands. Too often the developer calls a task done and progress is reported to an oversight team. The oversight team interprets this to mean that the end result is near when, in fact, there are two more levels of “done” to achieve.

We all want to deliver the good news that we’re making progress on our tasks and the end is in sight. As a result, we often prematurely call something done when it is only partially done. So the next time a developer tells you their tasks are done, ask if QA or the business would agree. Once everyone understands done/done/done, and we’re all using the same terminology, communication is improved. This has a positive impact on team culture and business results.

Because the word “done” can have different meanings for different people, it’s important that IT and the business establish a shared common language to improve communication and foster better relationships.

Many agile processes use storyboard sessions with the business users, and these are extremely valuable and something that really resonates with the business. Storyboarding is a process by which the business and IT collaborate on system and screen designs. Utilizing Post-its, system interfaces are laid out in a manner that helps capture the intent of what the business wants. Regardless of complexity, every attempt should be made to storyboard all user interface screens in order to remove as much ambiguity as possible before the development cycle begins.

While engaging the business in face-to-face meetings to flush out design is productive, it can also get tricky. Typically, everyone embraces the idea of just-in-time design or just-in-time requirements. However, as the project progresses, the business frequently becomes less available to participate in design sessions, and the methodology begins to breakdown. The trick is to keep the business engaged during the storyboarding exercise and focus on capturing the intent of what they want built.

Don’t attempt to storyboard everything in one session. Rather, break the work into manageable pieces so that the team is positioned for more successful outcomes. Half-day sessions are much more effective than full-day sessions because otherwise the group will either lose focus or begin to worry that they are away from their regular jobs for too long. If you can manage to keep the business engaged during the whiteboarding exercise, you’ll find it easier to keep them engaged through the remainder of the project.

The most important agile concept to introduce to the non-agile team is tight integration with the business. This is achieved by leveraging the above techniques and close examination of your organization’s requirements definition and management practices.

One way to measure whether you’ve achieved the required level of integration is to evaluate the trust that exists between IT and the business. If the necessary level of trust is not there, take the necessary steps to improve the relationship. Characteristics of a highly trusted relationship include increased levels of business productivity and a feeling as though the project team has captured the intent of the business need. Once intent is captured, the relationship will begin growing in a positive direction.

Regardless of the techniques you use, the end goal should be to predictably deliver business results and avoid an IT-driven solution. Too often, the business asks IT to solve a problem by a particular date. Then they let IT design the solution, only to comment later, “That’s not what I wanted!”

If you’re going to implement pieces of agile processes, make sure the executives and stakeholders understand that you’re not claiming to be an agile shop. Rather, you are picking and choosing the pieces of agile that fit best in the organization. If you’re going to swap out a component of waterfall with an agile practice, make sure that it supports the overall goals of the project and that you fully understand the role of what you’re swapping out.

For example, if you decide to not implement paired programming, then you may need to increase the amount of testing hours. Or, if you decide to not implement code refactoring during a development cycle because the overall design is not extendable, then you may need to add additional time to the end of the project or an additional phase of the project after the production release.

All in all, the best agile practices include short development sprints, paired programming, done/done/done, story-boarding, and integration with the business. Before beginning your next project, consider how agile techniques can help you:

• Show and measure progress through short iterations
• Solved problems in groups
• Maintain a healthy relationship between IT and the business
• Make sure the business agrees that the project is done

Think of WetAgile as an al a carte method of picking the parts of agile that you either understand or think you can easily implement in a waterfall shop. Keep in mind that as you take on more projects, you’ll most likely be able to introduce more and more concepts of agile and eventually become the agile shop that you aspire to become.

Steve Pieczko is a consultant with Geneca, a Chicago-based custom software development company.