Limitation of existing Kanban Metrics.

Throughput, Story Lead and Cycle Time are the frequently used Kanban metrics. These were defined for deliverable of same size and equal priority. But a software support team deals with incidents of different size and variable priorities. Hence, Kanban metrics collected without considering these factors (Size and priority) don’t deliver the purpose.
Illustration for cycle time and size of delivery: "Cycle time" is the time it takes to complete the production of one unit from start to finish. However, software support teams don’t have the luxury of working on issues of same size, unlike the mechanical production lines.
For example,
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents then the average cycle time is 2.
Day 2:
Again, the Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 medium incidents; even then the average cycle time is 2.
Now, the production line has spent equal amount of effort on both the days and has delivered equal value; and the metrics shows it correctly. On the other hand, the support team has spent more effort and has delivered higher value on the second day. But the metrics shows the same number, and hence it is not adequate to reflect the value delivered.
Solution: Normalizing the size of the incident could be a solution which is practically impossible. So, we can provide weightage to the incidents.
To illustrate:
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents. Weightage for small incidents are 1. Hence 8/(4*1) = 2 is the average cycle time.
Day 2 :
The second days, Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time, a support team takes 8 hours to deliver 4 medium incidents. Weightage for medium sized incidents are 2. Hence 8/(4*2) = 1 is the average cycle time.
This reduction in the cycle time shows the higher productivity. This is a dependable metrics.
Illustration for lead time and priority: "Lead time" is the time it takes for one unit to make its way through operation from taking the order to delivery. This definition assumes that all deliverable are of same priority. However, the software support works on priority. And we ‘park’ the low priority incidents when relatively higher priority come into the queue.
So, to illustrate,
Consider three incidents A, B and C and all are of same size and came to the backlog at same time.
A came to the queue first and was delivered in 3 hours. Lead time for A is 3 hours.
B is of low priority where C comes with high priority. Hence, we park B and take C next to deliver in 3 hours. Now the lead time for C is 6 Hours. Now, B is brought from parking to delivery queue. Which has a waiting time of 6 hours. Now B is delivered in 3 hours. Hence the Lead time for B is 9 Hours.
Now, we should be able to distinguish the time spent in backlog and the time spent in parking. Because the lead time is going to be used in discussing the backlog health.
So, the time spent in parking should be offset, so that we would be able to see the correct scenario. In the example above,
Lead time for A – 3 hours.
Lead time for B is 9 – 3 (parking hours) = 6 hours
Lead time for C is 6 Hours.
Conclusion:
Hence, for both cycle time and Lead time, the time spent in parking should be deducted before calculation.
And for cycle time the incidents should be given weightage before calculating the cycle time.

Tracer bullets and SIT.

Agile teams deliver smaller slices of deliverable to avert the big bang releases and failure. Also, by delivering iterative, we are getting frequent feedback. Here are the important questions related to this.

• ·        How to perform system integration testing? Whether we need to keep the integration testing as a part of scrum team or as a separate team?
• ·         As we plan to deliver frequently, are we going to perform SIT for each small slice of functionality?

Since the agile teams deliver only a slice of the feature, sometime the suitability of this code in the overall architecture is not validated; until a complete regression on system integration is done and certified.

To avoid such delay, we shall implement tracer bullets. Here is my blog talking about the difference between tracer bullet, POC and prototypes.

http://myagiledays.blogspot.com/2014/12/tracer-bullet-and-more.html

Tracer bullet is a skeleton implementation of a feature which spans across the architecture. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and rest of the iterations can build on this code.

Tracer bullet ideally should cover all the major data flow paths in the technical architecture to perform the basic ask in the user story. The design thinking should ensure (Ideally) that SIT should done once for tracer bullet and once again after implementing other functional asks.

This way, we would be performing system integration when we test tracer bullet and we will validate functional integration when we perform remaining sprints deliveries.

Passive Resistance – An Agile coach’s nightmare.

People resist changes. There are different types of resistance caused by different reasons. I wouldn’t generalize that the resistance is evil. There could be valid reasons and some of the reasons can be very healthy too.

However, passive resistance, irrespective of its validity or reason, could be extremely difficult to be dealt with; for any leadership, particularly for an Agile Transformation leader. Here are the few important reasons for passive resistance and possible mitigation.

Awareness: I would like to believe, at least initially, that people resist because of the lack of awareness. But, most of the resistance caused by awareness issues would be expressed explicitly. That’s a blessing in disguise. Still the coach should bring details and hence awareness to the environment, if a transformation would not deliver expected values. It is not uncommon that people stepping forward and asking more questions after such a second wave of awareness sessions.

Hence, lack of awareness may trigger immediate, explicit response as resistance which can addressed by discussion and negotiation. When silently resisted, it would be observed from the outcomes of transformation. When the coach finds the transformation endeavors are not effective in result, he/she should try bringing more awareness to the team.

Acceptance without agreement: Since, agile transformation is a culture change, it normally comes with a lots of support from executive Leadership. So, it generally gets accepted by the team but there could be team members who don’t agree on the principles and values of Agile transformation. The risk is, such acceptance would prevent the free flow of opinion and would prevent the feedback from surfacing. It is extremely crucial that the team and leader get seamless feedback; after all, visibility is a core value of Agility.

The mitigation is:  the transformation leader should be capable of influencing team without authority. By being a servant leader, the Coach should ensure that the team is aware of the reason, execution and the results of agile transformation. He also ensure that the ceremonies and tools would ensure that the transformation is a matter of moving from hierarchy to a flat organization, to enable visibility across the organization. Such visibility will encourage people to get clarified by raising their concerns.

Certainty by Adaptive methods in Agile projects.

Bringing certainty to a project is one of the prime goals of project management. Conventionally, teams were relying on experts to predict the delivery. Experts provide estimates to plan and schedule and thus to bring certainty. It is very crucial particularly in a very dynamically changing market conditions. However, these predicted estimations by experts are merely as good as the expert himself. The predicted estimates from an expert comes with all the limitation of this expert himself. It is also true that the no expert could be smart enough to predict the outcome of a project in which is impacted by both internal and external factors like, changing requirements, changing team dynamics (particularly addition and removal of team members) and changing technical frameworks etc.

On the other hand, there is one more endeavor pursuing to bring certainty. Adaption in the place of prediction. Adaption is the process of learning from past and taking a suitable stance to avoid repeating the same mistake. Humanity evolved by Adaption. Every food in our table came to our table after trying many wrong things and inferring the right food.

Instead of relying on experts' predictions, the Agile teams follow Adaption by trying unknown things at the earliest and failing quickly to get feedback to learn. This Adaption needs iterative model to apply the learning before trying next requirement. It is crucial that teams take small steps at a time, to avoid lot of time in something they don't know. So they these iterations should be small. Hence Adaption process should be early, small and frequent to learn fast and evolve.

Conventional expert estimates and plans are done only once, during the initial phase of projects. But the Adaption enables the team to revisit the estimates and hence the plan, during each iteration, which is extremely suitable for a dynamically changing environment. More than that, when we enable teams to estimate their requirements, we can get more realistic, time sensitive, team specific estimates. Also, these adaptive estimations are valid only for that specific team, in that specific organization, during that specific phase of project,for that particular client only. Please note the expert's estimations are valid are considered universal.

Estimations by experts are done in person days, and the adaptive estimations are done in story points.

Project Management - Know your cocktail

There could be two prominent ways to deliver something. It could be 'delivering a piece of art'; like delivering Mona Lisa. Or it could be something like a successful war campaign; like Alexander the Great's conquest of the Known World.

There are two major subjects of discussion on knowledge. Empiricism and Rationalism. Empirical process control and analytic process control. The empirical knowledge comes from experience. Rationale comes from reason. Empirical knowledge evolves based on experience. Reason is derived from evidences.

Software development can be categorized into two major types in its simplest form. Delivering something new and delivering something out of experience. For example, a R&D module used to control a rocket module in space is something new. On the other hand, an Employee Management system can be developed utilizing the experience earned from similar projects executed earlier.

No software development project falls in either of these categories completely. The success of a project manager is in identifying the perfect combination of these process control methods to ensure delivering dynamics.
But, understanding the dynamics between these two schools of thoughts is crucial to make a perfect blend of process control which would deliver success.

Bugs – An agilist’s dilemma

The question is - ‘Is it ok to size bugs and consider it like any other story while calculating capacity, When bugs would be planned for successive sprints?’

When I entered in to a team recently I found them not sizing their bugs. But I personally thought that bugs should be sized. 
Why because,

• ·Those bugs are of huge effort
• Then only we can identify the actual effort
• ·Then only we can identify the capacity
• ·Then only we can ensure if all our metrics related to effort, capacity and normalized capacity are correct.

However I am not a purist. An purist- Agilist working on offshore model? Laughingstock.

Still, there is a limit and degree for compromises. So, I investigated and understood the reason why they are not sizing bugs.

• ·They claim credit for stories which are having MINOR defects with the approval of PO.
• ·Any defects reported at last few days of sprint are moved to next sprint without sizing.
• ·Both PO and SM are in agreement with Team to fix the issues without credit.

But, what I noticed was, somehow the team had forgotten that such a conditional compromise is accepted only for MINOR, last minutes bugs.

I am still working with this team to ensure that efforts beyond a degree should be sized.

But, beyond which degree? That’s something the team to decide and the PO to be in agreement.

What if they won’t do this? Then they will never know their capacity and normalization

      Ideally, the team should strive to deliver without defects.

An elevator pitch..

I got another opportunity for an elevator pitch. I could see this senior executive was a man of illustrations. So I chose to give an illustration on the classic questions. Agile Vs Waterfall.
I said -Waterfall projects are like making a table and agile projects are like growing a tree and got his attention immediately. I continued. 
When you decide to make a table you would prepare a design on paper before going to homedepot to get timber, nails and paint. Then you would follow the design to make the table. You have lot of experience in table making. It is under your control. There is no scope for this to grow beyond your design. There is no risk involved in this implementation as you have done this earlier.
On other hand, you don’t have an exact design to grow a tree. You can plan on which tree, which location etc. But the growth and yield of the tree is not in your hand. All you can do is to provide fertile land and selected seed and water and sun light. The tree will adapt to the environment by reaching for sunlight or by shedding leaves. Growing is a new activity every time. Your plans may not be fully implemented during the tree growing process.
Making a table is inorganic and growing a tree is organic.
Creating Software is not like making a table. You don’t create the same software repeatedly. Since the environment is dynamic the requirements may change at any point of time; like growing a tree.
We continued to discuss outside the elevator as well..