“The journey to full agile development often begins with a hybrid approach” - Steve Pieczko
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 to become agile?
For the last three years, I have been working for a Chicago-based IT consulting firm that specializes in custom software development. As a consultant, I’ve found that we often end up using the methodology that is in place at the client site but, when given the choice, I usually chose agile over waterfall methods. However, the reality is that 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 is usually introduced by the development community in a bottom-up style that isn’t understood or appreciated from the top-down. Regardless, many teams end up implementing a hybrid methodology.
Hybrid approaches to solving problems are not all bad. Case in point: The auto industry needs to find alternatives to high gas prices and knows that the market is ready for an electric car. However, they started with a hybrid car, known as the Toyota Prius, before introducing a full electric version like the Chevy Volt. So perhaps the reality on how we make that quantum leap to full agile development starts with a journey that begins with a hybrid approach.
I created a new term to describe waterfall shops that either aspire to be agile or are in the transition process. I call these shops “ WetAgile”. Individual people can also be described as WetAgile. For example, perhaps you’re an aspiring agile guru doing so many waterfall projects that you find yourself implementing the pieces of agile that you most understand or 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 aspects of agile.
Paired Programming Works Great for Both Newbies and New Technologies
For example, we recently completed a large electronic content management (ECM) 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 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 fragment. 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 in 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 reading.
Bite Size Chunks Go a Long Way
Short development sprints can also be very productive. Too often we start a project by trying to estimate when it