Saturday, January 21, 2012

Agile oscillators

When I first got out of engineering school, one of my first projects was to build an oscillator. An oscillator is a device--should I call it an object?--with "just enough" reinforcing feedback of output back to input, with the feedback arrival timed just so, such that there is a constantly varying cyclic output, swinging first one way and then the other.

The nature of the varying cyclic output can be quite jarring, or it can be nuanced and smoothed out:


Now, along comes Agile, and my thoughts go back to the oscillator. And, I'm not the only one. Jim Highsmith has been thinking about the same thing. The architecture (stucture and behaviors) of all agile methods includes feedback, mostly from customers/users, but also from sponsors/stakeholders. The mandate for agile teams is to respond, and be responsive, to feedback. That is, a sample of output--in the form of user experience--becomes a part of the input to the deliberations of the agile team.

Now, if the feedback is phased (timed) one way, it will stablize the iteration. Change the timing a bit and it will destablize the iteration and cause oscillations. In effect, the team builds one thing, only to find out--in the wrong timing--that the customer has changed their mind; the team responds to the change. But, meanwhile, the customer is experiencing the wrong (earlier) thing and seeks correction. Ooops! the team is driven back, or a different way.

If the timing is never corrected, the iteration becomes oscillatory and really nothing gets done.

Time for the project manager to step in and call a halt and dampen the oscillations. Everyone needs to take an Iteration 0 break to do a little reflection and get the timing reset. Maybe a spike needs to be inserted to allow for some non-deliverable prototyping or modeling.

In any event, oscillations can not be allowed for more than a cycle, perhaps two. If not naturally damped out, the PM must take action!

2 comments:

  1. Pavel Barseghyan sent me this comment

    Every design process is always accompanied by verification of the results. Depending on the relevance of these results to the requirements of the specification, process re-engineering and testing may have a few cycles. The purpose of these cycles, a gradual decrease in the number of errors made in the design and pace of reducing the number of errors is an important indicator of the quality of the design process. But it must be taken into account that this process can be both convergent and divergent. The failure of the entire project, or part of it - this is a typical divergent iterative process of design and verification.
    From a quantitative point of view design and verification process can be represented as a kind of predator - prey oscillation, where the means of verification eat the population of errors. That is, under this approach verification methodologies and tools are the predators, and the preys are the errors of the project.
    We should also note that cyclic processes are crucial for the stability analysis of the design teams. From this perspective, the operation of any human group is a set of nonlinear cyclical processes. An example of such an analysis can be found here:
    http://www.pmforum.org/library/papers/2010/PDFs/Pavel Barseghyanjan/FP-Barseghyan-DynamicsofHumanSocialBehavior.pdf

    ReplyDelete
  2. just linked this article on my facebook account. it’s a very interesting article for all.

    Agile Project Management

    ReplyDelete