RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation
I don’t think that it automatically follows that you get an object oriented UI from an object oriented tool. However, if you carefully craft the business objects, then it should be possible to make an object oriented UI without too much difficulty. Then you can use a workflow engine to move those objects around as needed. The workflow itself becomes a set of wrappers around the objects that moves the objects from one state to another, tracks state, and tracks who and when.
The process at hand for our project is different in that there really are no optional steps. There are decision points which tell you which path to go down, but once a path is selected, there are no optional items. The complicated bit is that we have an item to move through the process (object x), in one path to move object x forward seven parallel processes all with their own objects have to move forward four of those parallel things come together to create yet another object which gets shoved down a process. The other three processes (with their own objects) just go to their own completions. Critical for us that we correctly create the data model to support this and the business object model as well. Then we have the presentation layer where we have widely varying requests from different parts of the user community.
Interestingly enough this set of processes is already highly optimized. People have been doing it for a while very successfully, the problem is that because it is so complicated it is very labor intensive to do correctly without losing things. The goal here is to actually reduce the number of people necessary to keep all of the different objects moving through the system and increase transparency into where things are at any given time.
Tara E. Santmire, CSM, PMP
On 01.06.10 20:30, Tara Santmire wrote:
Peter - Thanks for taking the time to reply. The dossier approach is interesting and I will discuss with the team. I wonder though how much it saves you given the object oriented nature of programming with today’s workflow engines.
Does it automatically follow from using object oriented tools that you get an object oriented UI? Hmm, I don't know the answer to that question. In our case it did not, but we were using Java, not an engine.
In the second project, where I did the visioning work, we looked at the flow of an order from the first input from the customer to the final billing. A classical value flow diagram did not work for exactly the reasons you described: too much variability in the route and times for each step. So we extended the value flow diagram in to a four track diagram. Each track represented a major actor -- "us" (in quotes, becase 'we' means my customer), suppliers, customers, customers' customers -- and the x axis represented the sequence of events.
This helped us identify where the process was complex, error prone and in need of optimization. We were also able to identify several points where 'we' had delivered value to the customer, but not yet earned revenue. When the final step came, it was clear why customers were saying no - they could do the last step themselves for less money than we could, because we were charging for the whole process in the last step. This led to some fundamental rethinking of the process, what's a service, what get's billed when, etc, so the business can be more effective.
The dossier approach meant that the customer could do simple things quickly. Almost from the point of creation onward, a 'make it so' command, could cause the final order, but also individual value added steps can be performed (and potentially charged), repeatedly if necessary, until the dossier is in the desired state.
Peter Stevens, CSM, CSPO, CSP
Independent Scrum Trainer and Coach
Sierra-Charlie Consulting | Zurich | Switzerland
Member of DasScrumTeam.de
tel: +41 44 586 6450
cell: +41 79 422 6722