I have had many discussions in various organizations about what processes need to be in place to support various types of projects. Very often, I have seen how teams get wrapped around the axle in what can become a very academic discussion. In the real world, it is not something that is academic, there are real people, real challenges, and real dollars involved. I am a big supporter of process, but it needs to be applied with common sense.
Common sense starts with people. Addressing business challenges starts with people focused on solutions. The technology…well, that is not as much my focus, but very often the core technology has somewhat been determined by existing realities. When its not, or if it becomes apparent that there is not the right mix to support the business requirements, then let the actual requirements drive the technical solution by following a process to discover the need and then map the solution to those needs.
So assuming that you can bring the right people to the table and assuming that they are applying common sense (big assumption sometimes), what is the right process?
Lately, I have been involved in a lot more projects that are “Agile-like” approaches. I know that there are purists out there, but for me, it’s about nailing the initial planning to prepare for the actual cycles or stages that will follow. In many cases with our customers, the business driver is that customer wants to see more sooner. This may be accomplished in a variety of ways that are not really Agile, but can be more waterfall if there are ways to address that need to see some of the solution before development resources go off for extended periods to do the heavy lifting.
If there are big questions on the table early on, we use approaches like quick prototypes or proof of concepts to answer those. We like to use Axure prototypes or even do some actual visual representations of key components to make sure that everyone is on board. It is a lot more efficient and cost effective to make revisions to prototypes than it is to do it during the development cycles.
We have worked with customers to adopt almost a maturity model to move from pure waterfall approaches to more Agile-like approaches. Often, this begins where we do much of the requirements and solution design in a more linear way, but then move the development to a more sprint approach. This can be the easiest way to begin the shift because it minimizes change to the customer. As we progress, it becomes easier to pull forward and include the solution design next into the cyclical process and then lastly move to a place where all is approached in a much more pure Agile approach.
These are just some thoughts from real world situations. Again, I apologize to the purists out there, but as I mentioned in the beginning…it’s about applying common sense to a situation which in the end has to do with involving the right people at the right time to come up with the right solution.