While I was incredibly impressed with True to Our Roots: Fermenting a Business Revolution, I’ll spare all readers with another review of the content that can be had somewhere else. Instead, it’s much more beneficial to comment on an aspect that the author just touches in a few places but doesn’t seem to emphasize. To give a bit of background, the story is written by the CEO of Fetzer Vineyards, Paul Dolan, who helped transform the vineyard and a large part of the California wine industry into a “environmentally and socially conscious” industry. While doing this, he grew the company at double digit earnings increases for ten or so years, and now, he is promoting this sort of change in corporate business policy to all companies and industries.
Dolan’s sale to the corporate world seems to be based more on the moral and socially responsible aspects of making these changes to business, but he doesn’t seem to accentuate the aspects that might have a bigger impact in converting the CEOs of the world, such as increased sales and higher profits margins. Here are some of the advantages I see from adopting the Fetzer philosophy, if the philosophy alone isn’t reason enough.
1) Employees that are motivated by more than money will work harder, work for less, and enjoy working much more.
2) Consumers will prefer an earth-friendly product over the contrary at the same price point, and in many cases, consumers will pay a premium for these products.
3) Consumers prefer purchasing products from companies with happy employees.
4) Companies that engage in these practices are often publicly awarded for making strides in environmental and social change.
5) In many cases, converting operations to an environmentally sound approach can lower operating costs over the long term.
CxO interpretation: lower costs, increased sales, higher productivity per employee, less employee turnover, free viral marketing, increased brand awareness
I’m often amused when someone says something is “Agile” in the software business. While I’m no expert, if there is such a person, it’s always interesting to see how almost any process can be classified as Agile regardless of how much water you can hear falling in the background. For instance, I recently heard of a new so-called-Agile approach that involved filling out a Word document to propose certain defects be fixed in the product as it neared the end of the release. It was justified the new approach (1) created a new process on the fly to allow change in the product and (2) was promoting change by allowing team members to submit change proposals. On the surface, it seems harmless enough, but for those that can’t read between the lines, this process ultimately creates a nonessential accountability hurdle which will make change much more difficult by requiring a form document.
So, begs the question, when is an appropriate time to throw out the “A” word as justification for a change in process? I would argue it should only be used when the proposed change meets the four tenets of the Agile Manifesto. Unfortunately, this seems like a cliché and/or and easy copout, so how about a few of simple guidelines that might trigger one to double-check the Manifesto. (I would argue these guidelines might be a good test prior to implementing any process in any business, but that off-the-cuff suggestion might be a tad haughty.)
Does the new process:
1) Increase the amount of time needed to make a decision by creating throwaway artifacts?
2) Primarily exist to make someone or some group accountable in the face of failure?
3) Attempt to minimize the amount of live interaction needed between one or more groups?
If you answered “yes” to any of these questions, it might be a good time to reflect on the change and reconsider the assumption of Agility.
As follow-up to a previous post, I wanted to share a recent experience related to having someone from outside the group come in and suggest new ideas. In this case, the outsider was myself, and I was representing the Agilist in a group that was just getting off the ground with Agile software practices. The first few things I noticed were: (1) how willing everyone was listen to my suggestions (as an unbiased outsider), (2) how much experience I had gained within my own group and (3) who the internal champion was and how he was working to transition the group.
This arrangement is an alternative to the more expensive approach of bringing consultants from outside the company; however, the obvious catch is the company has to be large enough to have experts from outside the group. The key to making this work is to ensure the experts from within the company remain neutral to any factions that may exist. This is easier said than done, as it quickly becomes obvious where the obstacles are. In addition, the experts should use in moderation specific examples of how they have succeeded with their own group as this may unintentionally arouse feelings of bias. In other words, the internal experts should not continually use “our product x is wildly successful doing blah process”. Instead, they should focus the advice towards helping the new group and showing the benefits the change will make. In general, the experience has made me much more attentive to looking for others who may have useful knowledge from within our organization.
The author of True to Our Roots provides a great story about the power of motivation in the workplace. The context of the story revolves around the power of creating the right environment where people feel they are obtaining much more than a paycheck. (I plan to write some more on this topic after I’m finished with True to Our Roots.) Here’s a paraphrased version of the story.
A management consultant has been brought into a hospital to look for ways to improve processes, productivity, etc. The consultant interviews all the doctors, nurses, HR staff, and etcetera for weeks. As he’s leaving one Friday, he notices a janitor mopping the floors near the elevator. Debating whether to even talk to the janitor, the consultant stops and asks him the opening question that he has used with all of the other staff. The question is simply to explain what role the person plays at the hospital. The janitor stops and thinks for a moment, and then says, “I help Doctor Johnson save lives.”
While a much more animated version of the story is described by the author, the point is incredibly clear, almost inspirational. It also provides a sharp reminder that we should look for things like this in our own work routines or find other means to accomplish what’s important to us as individuals.
If progressive process change is getting bogged down in an organization, one of the remedies to consider is bringing in outsiders. Most likely, these people from outside the company are either contractors or some other sort of consultants in a particular area. Another approach could be bringing in a new manager or other expert into the company as a full time employee. It’s amazing to see how people within the organization will accept the advice of a new voice, even if the message is exactly the same as a previous champion of the change from within the company. (I could write a novel about the reasoning for this, but I’m sure every dear reader has their own story to relate.)
Companies that create an environment of continually promoting change have less of a need for these outsiders; however, it’s sometimes difficult to determine that healthy new ideas are not being promoted when observing from the inside. The key to getting outsiders into the organization is to justify the ROI because of the expense that’s often required; however, in some cases, consultants will perform some free sampler training or consulting in order to get more business if the ideas are accepted.
For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.
These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.
You are currently browsing the Continual Improvement weblog archives for August, 2006.
| www.flickr.com |
Continual Improvement is proudly powered by
WordPress
Blog Entries Feed
and Comments Feed.