(Obligatory notice: I am an employee of Lombardi Software, but the opinions and advice presented here are my own.)
I've had a surprisingly difficult time conveying my own definition of "Iterative Development" in the past, so I thought I'd take a stab at explanation via analogy... Let's compare your Business Process to a trip from Austin Texas to El Paso Texas:
The most important aspect of my trip is arriving at my destination. No matter what interesting things may happen on the way: If I don't end up in El Paso my trip has failed. The same is true about your Business Process... No matter what else goes on, there is an objective to your process and you have to accomplish that objective.
The first iteration of your process... like the first iteration of my trip to El Paso... should implement just enough to get you through all the steps of the process. No extraneous details, but enough to get you from the beginning to the end. Start your iterations with the the Flow aspects of your Process. What are all the places that you need to go?
Austin is a long way from El Paso... lot's of lonely miles on the highway. Fortunately, we have family in San Angelo Texas, and it's not too far out of the way to make a detour when we are headed out west:
Based on how much time we have, the weather and road conditions, and how long it's been since we've seen our family in San Angelo, we make a decision whether or not to take a little side trip.
Your Business Process, like my trip from Austin to El Paso, probably has multiple paths that it can take. There are Activities that are always performed, and there are Activities that are occasionally performed based on "current conditions" and other factors. Implement a place holder for each activity and capture the decisions that are necessary to pick the proper path.
At this point I need to take a step back and be a bit more explicit about what I've defined thus far regarding my journey from Austin to El Paso. I have done just enough to get to all of the places that I need to visit. I haven't yet filled in any of the other details. I've got the directions on how to get there... I haven't worried about where to get gas, where to eat, etc.
You've defined the Flows through your Process, and you've implemented just enough stuff to get you through all the activities that make up the Process. You can now "run" the Process and step through each of the Activities... but the Activities don't really do much... They just prompt the Participant's for the minimal information necessary to get to the next step.
That's your First Iteration: All of the "Happy Paths" through your process work. There's not a huge amount of business value yet... but you do have a managed process in place. All of the steps of the process will get executed in the right order... and the decisions at each step will be captured to guide the process along the correct path.
Your Process logic is now correct, so it's time to start iterating through the Data aspects of your Process. You will need to know all of the information that is gathered during each Activity in the Process. You will need to know all of the information that is presented to the Participants during each Activity in the Process.
I hope that you see where I am going with all of this... Iterative Development of a Process must be done with respect to the Whole Process. Each Iteration delivers a more functional process. All of the Activities of the Process have to be functional, or you don't have a working Process. Each Iteration should improve functionality across the whole process (in general).
Contrast Iterative Development (as I've defined it) with Incremental Development.
Incremental development focuses on fully implementing each of the Activities that make up the Process in some order. I see folks following this approach a lot when a particular Activity involves integration with an external system... the IT guys will always want to tackle that part of the Process first. I also see it when one Activity dominates the Process... such as preparing a very involved application. It's our nature... We focus on the parts of the Process that we depend on. We focus on the parts of the Process that we are responsible for.
The Incremental approach is analogous to fully planning my trip from Austin to Junction... then fully planning my trip from Junction to Ozona... then fully planning my trip from Ozona to Fort Stockton... then fully planning my trip from Fort Stockton to El Paso (with maybe a little side trip to Fort Davis). Nobody denies that we'll (eventually) need to know all of those details... but by following that approach we won't be able to make any sort of journey from Austin to El Paso until the last step of the journey is fully defined.
Incremental development is how Process oriented projects get bogged down. This is how Process oriented projects just drag on, and on, and on. Your development team ends up focusing on Activities of the Process, rather than on the Process itself... and you often end up with Activities that don't make sense when the Process is finally finished.
Iterative development means building a process that works, then making it work better, then making it work better, then making it work better... It's an incredibly effective way to build your Managed Business Process, and there's no reason for the cycle to end after the initial deployment... You just start calling the cycle Continuous Process Improvement.
No comments:
Post a Comment