“How can waterfall and agile be combined while maintaining the core principals of each?”
When it comes to using different approaches to managing work, using a traditional and an agile approach in the same company is not difficult. Using a traditional approach and an agile approach within the same department, however, may be a different story. Much of this depends on how the organization is structured. We really should be having more discussions about how to structurally organize companies that have historically been structured for traditional development, but want to now work using more agile approaches.
Let’s try to be as clear as possible here. When I say ‘traditional approach to managing work’, I mean something like Waterfall, PRINCE2, V-Model, or a Spiral approach. These work management systems view the world of product development through a phase-based lens. Phase-based approaches of developing products allow for only a single linear flow of work, with very little overlap between phases, to exist. For example in waterfall, if we were trying to create a new product from scratch, we would first gather requirements, then design the product, then build the product, then test it, then deploy the product, and finally it would move into maintenance. Other traditional approaches are different, but not by much.
To further clear things up, there are many agile approaches. The most common today are the many flavors of Scrum, eXtreme Programming (XP), Kanban (which is actually Lean, not agile), and Open Space Technology (and there are dozens more). Agile approaches to work are used to bring more focus to satisfying the customers needs, without alienating or overworking our employees, while at the same time developing iteratively and incrementally towards short and long-term goals. Agile approaches are well known for self-organizing teams that focus on continual improvement in all areas of the work environment, not just improving their process(es).
While traditional project management approaches start a new cycle of phase-based work according to a schedule (defined start date coupled with a deadline, with many milestones in-between), agile approaches to product development simultaneously engage in all phases of development throughout the life of the product. When an agile team engages in a new iteration (usually a short period of time, sometimes less than a week, sometimes up to a couple of months), they engage in a short planning event that may be a high level of planning, or may be very technical in nature (the differences are in the actual agile approach being used), but it is understood more planning needs to be done each day of the iteration to stay on track with the goal of the iteration. Also, the self-organizing and cross-functional agile team will engage in more design, development and testing of the work they are currently doing. There are no gates or phases that dictate the team stop one behavior and start another. All traditionally recognized ‘phase work’ is done simultaneously.
This is where most organizations stop listening to their experienced agile coaches. They cannot conceive of how any group of people might engage in many different types of work at the same time. It can be done, but the engineering practices need to change. If you are going to fundamentally change the processes of an organization, and organizationally restructure into true cross-functional teams, the practices need to change as well. Just because the engineers (or whatever you are calling the employees who build your product) have decades of experience and seniority in the company, that does not mean they are ready for an iterative and incremental development effort on a cross-functional team. Everyone needs more training for this.
It can be done, but the engineering practices need to change.
So, how can we combine agile approaches and traditional approaches under one roof? The short answer is “With an immense amount of effort around how to structure the organization, retraining everyone involved, and an incredible amount of communication and dedication to making sure the customers are satisfied, successful and involved in the decision-making processes.” The long answer is ‘book-length.’
If you thought that would end this, think again. We still haven’t addressed the original question. An agile approach is not the same as agile itself. Agile, or more grammatically correct – Agility, is an organization’s use of the Agile Principles to shore up their organizational values, which should encapsulate the Agile Values. The Agile Values and Principles can easily be read at http://agilemanifesto.org. An organization does not have to use a prescribed agile approach, like Scrum, in order to BE agile. They just need to use the principles to work toward the values. They can do this while still using the traditional Waterfall approach. But, again, the practices need to change. A greater focus on customer satisfaction is needed. True continual improvement practices need to be adopted. No more burning people out. A clearer focus on true progress is needed. Turning the org chart upside down so the org is no longer command-and-control, but now one of support-and-trust (giving teams their autonomy). Focusing on reduction of waste and wasteful processes/procedures. You can still do waterfall and be agile – it’s just going to take a LOT of work to do it.
