In PM Power’s Enterprise Agile Transformation practice, customers – either starting on Agile adoption or reviewing their current state – often ask us questions like the ones below. What would be your answers for them? You can answer as many as you like – at least one if not all 3! Ask shiv@pm-powerconsulting.com for what he thinks are answers…
Q1: If I go Agile, it appears that the testing effort would go up considerably. So, should test automation be a pre-requisite for even starting to adopt Agile?
Q2: In my organization, the culture is for one person to be held accountable to the customer for delivery. Is that bad culture? If so, what is a better alternative?
Q3: Does specialization go against self-organization? If testers continue to remain only testers, Ux people remain only Ux people etc, does it limit the extent of self-organization? How feasible is it to overcome this limitation?
Solution:
Q1: If I go Agile, it appears that the testing effort would go up considerably. So, should test automation be a pre-requisite for even starting to adopt Agile?
Answer: Somehow, the question creates an impression that test automation is a huge beast needing considerable effort up front to conquer it. May be this can be attributed to the days where test automation meant mostly automating the tail end of development – integration, regression etc. Such large upfront investments are not the need of the hour to get started with Agile Scrum. However, the shift needed is to view automation as integral to development right from day 1. If anything is being done that is repeated 3-4 times in the development process, that should be a target for immediate automation. If that is adopted and a practice of “test soon after development” (even if not “test-driven development”) should actually bring down the quantum of big-bang tail-end testing. So, I would say, the overall impact of Agile is to bring forward as much of the testing as possible. Over time, the overall testing effort would be about the same and more evenly distributed through the development timeline; it may even reduce over time due to frequent delivery and feedback inherent in Scrum. But do bear in mind that it takes time for managers to be convinced (that the team is not “slowing down on cutting code” due to testing soon or TDD and developers to change their set ways of writing code in bulk first and then only test.
Q2: In my organization, the culture is for one person to be held accountable to the customer for delivery. Is that bad culture? If so, what is a better alternative?
Answer: Most of us have grown up in the culture of “one wringable neck” should things go wrong; somehow, in Scrum, it may be comforting to say that ultimately it is the Product Owner’s neck! So, in the event of a failure, how does having the PO’s neck help retrieve the situation? Also, the implication is also that other than the PO everyone else goes scot-free! Is that fair? I think, the culture and mindset change needed is to view everyone in the team being accountable for their role and results. Like in an orchestra or the kitchen in a fine restaurant or a cricket team etc. If the team fails in each of the above examples, it is pointless to ask only for the neck of the conductor, the master chef or the team manager respectively. Do you have the capacity to wring many necks at the same time?!
Q3: Does specialization go against self-organization? If testers continue to remain only testers, Ux people remain only Ux people etc, does it limit the extent of self-organization? How feasible is it to overcome this limitation?
Answer: This is partly an enduing myth about Agile. Specialists are needed, no doubt. While It is not that difficult for a developer to be a tester and vice versa may be; but it is not that easy for a developer or tester to be a Ux specialist. In fact, if everyone is the same as everyone else in terms of skills, why would there be a need for collaboration which is so much needed and emphasized in Scrum? If self-organizing is about helping each other, “swarming” for solving a problem etc., there is a great deal of scope for it before you hit the wall of “I cannot do that”! See Mike Cohn’s enduring myths about Agile and my colleague JV’s blog on self-organizing teams.
