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.