For a product development organization, being driven by man-hours as measure for managing its operations, lends itself to the command and control zone of management. Instead of measuring and tracking how we meet client demand, the focus is shifted on controlling this measure.
This measure leads the organization to judge its performance based on the cost of its people instead of Throughput. Instead of being considered opportunity, people are perceived as liability. Therefore, Man-hours emphasize on maximizing people utilization. Read more…
Why we can’t accept work from our clients?
Answer: because all people are busy.
Why all people are busy?
Answer: There are so many projects and deadlines.
Why didn’t we plan this current work?
Answer: We planned, but it didn’t work, in addition our work has lot of defects (we call this maintenance to be nice).
Is this maintenance sort of new feature?
Answer: NO, it’s failure from our side and considerable percentage of our people effort is spent addressing them.
Why you didn’t tell me about that before
Answer: none… ** Fear **
Symptoms of Fear behavior:
- We are always busy
- People are forced to do work on expense of quality. We create our own technical debt.
- We always change priority
- We don’t dare to ask our manager to give us work because of available capacity
- Distrust
- Presence of heroes
- We create defects
Please add other symptoms.
Each team operates under a different context. The purpose of this post is to characterize team context using objective factors. This characterization should improve our understanding about what can matter most when developing a team Agile process. Read more…
Going to the plain basics, maturity is to deliver what we promise. I heard this definition from a successful sales executive of product development company. For me this summarizes everything!
Meeting commitment is arguably the most important criteria for success. I use the measure of requests percentage which have deviation from target date exceed “x” days. This measure helps to quantify our maturity as organization. It represents the Voice of the Customer (VoC)
This measure can be organizational wide and it can be used to drive the whole improvement initiative.
The following chart gives high level analysis of causes of immaturity as suggested by this measure.
The foundational cause is the inability of people to timely communicate their issues. I worked with developers who had one month-long tasks and kept reporting that things are according to plan till they report failure at the very last day! I carry the responsibility by not allowing trust environment which encourages them to talk and share their concerns.
Sales people making commitment without consulting engineers is well-known issue which can be solved if they are educated about the capacity measures. These capacity measures can directly improve the above VoC measure. The capacity measures include Average Lead Time for each Class of Service. This measure allows sales people to provide informed estimates in the very narrow window that they might have to secure a deal. They can add percentage of uncertainty based on the inherent risks. I suggest this should be maximum of 20% with promise of being reduced as we proceed into the project.
Finally, a key assumption for failing to meet our commitment is the poor definition of customer valued request. Delivery on time requests which are not meaningful actually invalidates our improvement effort.
Listening to http://en.wikipedia.org/wiki/Goldratt about how a product company can be successful, the answer was that the product should be able to remove a business limitation for the customer. For example, a Telco company may use a portal to provide premium services to its client which otherwise it can not.
The challenge is that the existing mode of operation of the client is designed so that the company can survive in the presence of this business limitation. Hence, if we created a product to remove this business limitation, the employees of the company are incapable to achieve the desired benefit. Because, those employees are accustomed to operate under the barrier of this business limitation. This mode of operation becomes a habit ingrained in the business practices of the company. Moreover, these habits could have been developed as company wide policies. The new product, though it does the job, has low return because employees cannot transcend their mode of operation to cope with what is required to achieve the benefits from the product.
The problem really is not with the customer’s employees, it is with the product features.
The product features should include those features which enable the employees to transcend their regular mode of operation. Limiting product features to the aspects of functionality, technology and performance might lead to a product which removes the business barrier. However, this product will fail in the implementation because it neglected those features that allow the employees to transcend to the new required mode of operation.
As we develop product vision or idea, we should follow the next steps:
- Identify and communicate the business limitation that this product will remove.
- Develop the product features related to functionality, technology and performance which will remove this business limitation.
- Understand the habits which are associated with the existence of this business limitation.
- Based on the previous step, identify those critical features which allow the customer’s employees to operate in a mode conducive to get the benefits of the features in step-2.
- Develop mock-ups and prototypes that ensure the combined features of steps 2 and 4are aligned well. Refine the features from steps 2 and 4 accordingly.
- Build the product iteratively with direct involvement of customer employees to evolve the features from steps 2 and 4.
This blog is based on my reflections after reading of Alistair Cockburn work. I am addressing the case of Pair-Programming to improve quality and therefore reduce cost.
In software quality can be improved through increased collaboration among talented developers. In traditional models of development this collaboration was optional with high degree of formality sometimes and with irregularities in other times. By now, we are more having understanding of software as creative and highly demanding endeavour with little influence of formal processes.
The XP practices provide a collaboration forum that help guiding developers to produce higher quality software. Read more…
Thinking is something we always do without we feel, it is like breathing, we take it for granted. We can’t be alive without breathing, but can we become better if we stop thinking?
In his book “Stop Thinking Start Living“, the late Richard Carlson described that thoughts are the origin of negative feelings which can lead to wrong actions. In his classic “The Power of Positive Thinking“, Norman Peale emphasized on positive thinking as the key driver for man’s flourish and growth. Read more…
For a product development organization, being driven by man-hours as measure for managing its operations, lends itself to the command and control zone of management. Instead of measuring and tracking how we meet client demand, the focus is shifted on controlling this measure.
