Posts Tagged ‘iterative’

Can Agile cause damage?

Yes.

Is Agile a good method?

Yes.

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.”

—

Tagged as: active garage, agile, center for change management, Change Management, gary monti, iterative, Network Diagram, planning, Project Management, Project Management Methodoligies, Waterfall, WBS

Last year, in November, I posted 12 posts on QUALITY in the form of QUALITYtweets, on Active Garage. It didn’t quite seem right to stop just there… when there is so much still left to say about QUALITY!

Here are the first twelve posts, in case you would like to go back and take a look:

1. Quality #1: Quality is a long term differentiator
2. Quality #2: Cure Precedes Prevention
3. Quality #3: Great People + Good Processes = Great Quality
4. Quality #4: Simplifying Processes
5. Quality #5: Customers are your “Quality Partners”
6. Quality #6: Knowing what needs improvement
7. Quality #7: Productivity and Quality
8. Quality #8: Best Practices are Contextual
9. Quality #9: Quality of Relationship and Communication
10. Quality #10: Inspection can be a waste if…
11. Quality #11: Driving Change Through Leadership
12. Quality #12: Middle Management and Quality Culture

#QUALITYtweet Make every review meeting a learning

experience by reviewing the product

and process, not people.

We create, we review and we make it better. Reviews are an integral part of product/service quality improvement. The core purpose of any review process is to “make things better” by re-examining the work product and find out anomalies or areas of improvements that the creator of the work product was not able to find.

Establishing a good review process in an organization requires management commitment and investment, but for returns that it generates, the effort is totally worth it. In software world, a lot of emphasis is given to formal inspections, but they work best when a formal process marries with a set of common sense rules. Here they go:

1) Reviewing early

Reviews in early phase of product development means that findings are less costly to resolve. The later defects are found, more expensive it gets to resolve those defects.

2) Staying positive

The art of review is to report negative findings (problems) without losing the positive undertone of communication. Negative or destructive criticism will only make the process more burdensome. Stay positive and keep the process lightweight.

3) Keeping review records

When a lot of time is spent on reviewing, it makes sense to track the findings to closure. Recording the finding helps you to effectively track the closure and trends.

4) Reviewing process, not the person

Always question the process and not the person. Human beings are bound to make mistakes, which is why reviews are required. So accept that mistakes will happen. How can we have a more effective process so that these mistakes are not repeated? That is the critical question.

Imagine that Bob is the reviewer of John’s work product and consider the following conversations:

Bob: “John, I reviewed the code of invoices module developed by you. Again this time, you have not implemented the architecture correctly. You committed the same mistakes that were also found in the registration module earlier.”

OR

Bob: “John, I reviewed the code of invoices module developed by you and your team. We have found some anomalies in the architecture implementation. I just wanted to know if the team had undergone the workshop on our standard architecture. If not, we should invite our systems architect to take a small workshop on system architecture so that the team has better clarity on how it can be best implemented.”

Two conversations with a totally different outlook. The first conversation tries to blame the producer where as the second conversation tries to assess the process and take corrective actions.

5) Training and more training

Reviewers can make huge mistakes if they are not trained. If you don’t invest in training your review teams, you cannot expect them to do it right, the first time.

6) Reviewing iteratively

Review often. During the course of product building, product needs may change. New ideas may be implemented. Keep review process constant amidst all these changes. Discipline is the key.

7) Reviewing the process of reviewing

Are we reviewing it right? Are we reviewing the right things? Periodically, assess the results and the benefits of having a review process. Assess how reviews helped improve product quality. In process assessment, also identify if people are heavily relying on reviews. It that is the case, it is a bad sign.

Success of any process depends on 2 E’s – Efficient and Enjoyable. Same holds true for your review processes. Review is a control mechanism, and hence the focus on getting it right the first time is still very important. A good review is just an internal quality gate that ensures that internal customers (reviewers) are happy with the final product. If your internal customers are happy, your external customers will be happy too!

—

Tagged as: active garage, customers, efficient, enjoyable, investment, iterative, learning, management, meetings, people, process, product, qaspire, Quality Tweets, records, reviews, service, software, tanmay vora, training