Agile? Waterfall? How About WetAgile?


will all be done. Since I’ve seen 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 size chunks.

Short sprints include regular development build 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) is 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 size 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 provide visibility into the progress of the project and 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”.

Getting it Done, Done, Done

Once down the agile path, it doesn’t take long to start appreciating the agile term “done / done / done”. The first time I heard done, done, done , I thought my friend invented it. However, I later learned that it’s an agile term 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 the 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.

The Business Value of Storyboards

The agile process of storyboard sessions with the business users is 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 paper 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.

For example, a recent client needed to design a marketing program that included a new user interface. The project team consisted of approximately eight business users and a handful of representatives from IT. We broke the team into two groups of four and paired them up with a business analyst. The teams were then asked to use blank sheets of paper and draw screens which included pick lists, drop down values, text boxes and links to other screens. Next, they placed the screens in the order of how they envisioned them flowing. When the teams completed the exercise, we taped the screens onto a white board in the specific order with one design above the other. The two teams then reviewed both designs along with

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.