Posts Tagged ‘agile’

Can Agile cause damage?


Is Agile a good method?


How can both statements be true?

Let’s look.

First, let me say I have a great respect for RAD, Extreme Programming, Agile, etc., because the methods reflect acceptance of and dealing with a common reality.  That reality is the gap between initiatives or high-level project statements (40,000 foot view) and what it takes to get the job done (working in the trenches). Life moves at such a fast pace there is little time or tolerance to do definitive estimating, i.e., laying out ALL work in work packages of 80 effort hours or less and stringing them together logically to create a network diagram. The pressure that is usually put on the team comes from the desire to see action and deliverables being generated as quickly as possible. The belief is time might be wasted planning due to analysis paralysis. There’s something more to it, though.. the senior management has the desire to move ahead with more initiatives and wants to delegate its responsibility to think things through at a detailed level. In other words a greediness can be present to get as much from the team with as little input as possible.

The Agile method creates a realistic solution to such a situation by getting the team to work quickly with the caveat that the recipient of the deliverable will be available to sign off on progress made and give clear indication of what they desire next.

Baby Steps

The problem that can arise is reflected humorously in the movie, What About Bob, where a successful psychiatrist (for this blog representing the team) loses his mind while attempting to deal with a highly dependent, manipulative, obsessive-compulsive patient (representing the customer, end-user, or sponsor).

In the movie, the psychiatrist is famous for his book, “Baby Steps,” which defines how patients can be moved back to health by making small, corrective changes in their behavior. The problem is the patient takes advantage of the psychiatrist’s dedication to get more of what he wants without taking responsibility and making any changes in his own behavior.

No, this does this mean that customers, senior managers, and end users are mentally deranged. The situation is more in line with having to deal with a demanding, ever-changing business environment and expecting IT to keep up with the demands. If these demands are legitimate then what is the problem?

Flexible or Fragmented?

The issue has to do with the potential of taking a good thing too far and having it turn into a weakness. This is the basis of an interesting psychological tool, the Strength Deployment Inventory (SDI). Flexibility IS important as is acceptance of the difficulties associated with doing long-range detailed planning. So, again, Agile provides a definite “plus.” The problem arises when there is an over-reliance on the intense, tactical approach. What can happen is reinforcement of a nearsightedness regarding requirements along with the belief the team can work without getting immediate feedback on their work. If the team reacts to this and pumps up to get more intense about making the method work a negative feedback loop can build which is of no help to the project.

The Solution: Balance

In the end stability is needed. Why? When the success of a method exists solely in the dynamic of extreme, short-term actions there is the risk of no end-to-end stability. Documentation becomes increasingly difficult to perform because many targets are moving simultaneously. The organization can behave as if it has ADHD.  On the flip side, strategizing without getting into the details risks going nowhere.

The solution lies in getting back to some classic project management approaches to insure a coherent strategic overview is maintained and system performance is truly auditable. It is similar to laying roof shingles. A line needs to be drawn as a reference point across the entire roof. If not, roofers can lay shingle by shingle and swear they are following a straight line. However, after going 15 or 20 feet in this manner they can drift from the straight line with absolutely no awareness they are doing so. This drift eats time and money.

A 5,000-year-old quote from the Upanishads sums it well:

“By standing still we overtake those who are running.”

Producing Good Decisions… consistently!

by Thomas Frasher on August 11, 2009

decision making cartoonDecision making for entrepreneurs/business owners can be difficult, time consuming, arduous, fractious and distracting.  This article discusses a method for clarifying decisions and streamlining decision making.

There are four parties to every business decision:

– The facilitator

– The approver

– The contributors

– The informed parties

1. The facilitator – this person pushes everything, keeps the schedule, facilitates meetings, and makes sure the lines of communication stay open. There can only be one of these at a time.

2. The approver – There is only one of these for any decision. This is the final authority for the decision, they have the responsibility for the delivery of the business outcome of the decision. In some very rare cases you can have more than one approver, this requires a high degree of trust between the approvers and they need to have a single vision of the desired outcome. The approver needs to be designated pre-decision.

3. The Contributors – These are the individuals that execute the decision. The contributors have the technical expertise to provide input to the decision. It is very important to understand that the contributors do not need to agree with the decision, however, after the decision is made the facilitator and the contributors must support the decision. There should be 5 or less contributors.

4. The informed parties – The fourth group are those that are informed of the decision. They have no vote and no say. The facilitator is responsible for communicating the decision and the business outcome of the decision to those affected by the decision.

It is also important to understand that this process can also be used to drive efforts to produce business outcomes, not just decisions. with the contributors being the architects of the design, the facilitator keeping the schedule and coordinating actions among the contributors and informed (often implementers), the approver having the final say over the outcome quality.

Paying careful attention to the make-up of the decision team will greatly influence the quality and speed of the decision. Good teams produce good decisions… consistently!