Role of test manager in a scrum team
In a company, they are transitioning from agile to scrum. They have hired a very skilled scrum master to facilitate change, they have an up to speed product owner, a development manager who is up to speed with scrum, and the business supports the change. Also in this company, there is a test manager who has his own test team of four testers.
The scrum master disagrees with this tactic, saying that the testers are developers, and they are members of the scrum team, wanting to scrap the "test team". He believes that each member of the team should be able to test as well as develop, but the test manager disagrees, believing that *his* testers are specialized in what they do, and that testing before production is a vital job that he cannot leave it to chance, or to people who don't know the testing process.
The test manager gathers his testers for a mini meeting after the morning standup, in a separate room, without informing the others or updating them on their talks. The test manager has no previous scrum experience either. He believes that if any of his testers forgets or doesn't do something, he should go around and chase them.
What would your suggestions be for this business, and the development manager and scrum master for the test manager, who seems resistant to this business change and wants to retain his team?
I think it is important to distinguish that the need for the skills and expertise possessed by the test team do not disappear in an agile environment. In fact, if a team is producing more frequent potentially shippable increments, then this arguably increases the need for strong test expertise. But it probably won't take the exact form that it did previously.
The Scrum Master is correct in saying that Scrum does not recognise roles outside of Developer (excluding the Scrum Master & Product Owner), but that is not to say that everybody on the team [only] writes code. I get the impression that the Scrum Master is handling this situation poorly and is making the situation worse. This is a phenomenally sensitive area; people's identity (and potentially their livelihoods) are at stake and it is vitally important that an environment of trust is built and matters such as this handled well. It sounds a bit dictatorial at the moment which is possibly why the Test Manager has gone defensive.
One of the three pillars of empirical process is transparency, and it appears that this is not being recognised or accepted in the business at the moment. This is presumably because there is distrust amongst team members. What efforts are being made to build trust within the organisation?
"Agile Testing" by Janet Gregory and Lisa Crispin is a good book which would help the business as a whole -- as well as the Test Manager and Test team specifically -- understand the changes that the agile transition may have on their day to day responsibilities.
Regarding the 'private meeting' - has anybody shown genuine interest this and asked if they can attend?
Posted By Ramsay Ashby on 11 Apr 2016 11:12 AM
I get the impression that the Scrum Master is handling this situation poorly and is making the situation worse.
+1 100%
I would even go so far as to say it isn't an impression. From what has been explained, the SM is making the situation worse, and my personal "impression" is that the SM is not "very skilled" and does not have much experience with organizational change.
This is sometimes evident with newer Scrum Masters who view Scrum as very prescriptive. There needs to be empathy and a conciliatory approach with all vested parties to not only promote the benefits of Agile/Scrum, but also to point out the negative effects of existing poor practices.
There is not a magic switch that can be flipped that will make testers and developers conform to a Scrum "ideal". It is foolish to think otherwise, or for anyone involved to believe they have the formula for success if only everyone else would just fall in line.
Agile/Scrum is a journey, to learn and improve through an empirical approach. You don't start with an "end-state" vision and then remain steadfast that others must adjust. Where is the collaboration there?
So now you have a testing "silo" within the organization that has now entrenched with the belief (perhaps rightly so!) that Scrum is being used by the organization to eliminate the testing silo and even the need for a testing manager. I'm not even getting into a discussion on whether this might be preferable outcome or not, but I'm just recapping a very ugly situation that was unnecessarily made.
I have a few "observations" regarding the existing environment:
1) Why is the Test Manager unfamiliar with Scrum, when it seems so much of the organization is on board? Was this a simple miss?
2) Why does the Test Manager believe that a separate tester-only meeting is required after the Daily Scrum? What does he view as the benefits to that meeting, or why the rest of the team does not need to be involved in those discussions?
3) What efforts are being undertaken to build a relationship with this Testing Manager? He is not the enemy. He is not an adversary. He is a partner.
4) Why does the Test Manager believe that such a critical area of expertise (testing specialization) suits the organization best by restricting it to a select few?
> What would your suggestions be for this business
Right now the Development Team are running with a deficit for release. In other words each Sprint does not result in a potentially releasable increment...the team do not have all of the capabilities required to create one. This is what the Scrum Master is alluding to. The team is insufficiently cross-functional and lacks the requisite testing capability to create a genuinely Done increment.
The first thing to do is to acknowledge the existence and nature of this deficit. My recommendation is to make it transparent through the Definition of Done - you can include a section which is titled "Deficit for Release" and enumerate the areas, such as testing, in which the DoD falls short. It will then be clear through the DoD that the Development Team will not be creating a truly Done increment.
What happens next will depend upon who cares about it. Does the Product Owner expect and value increments, each and every sprint, that are genuinely of release quality? If so, how would the Development Team wish to be structured in order to provide that capability, and reduce or eliminate the deficit? That would be a topic for the team to address no later than the next Sprint Retrospective.
What would your suggestions be for this business, and the development manager and scrum master for the test manager, who seems resistant to this business change and wants to retain his team?
As there are things that cannot be solved from within the team my proposal would be to Inspect and adapt on management/department level. You have to address/find the right person to "convince" the test manager that this is not the way forward.
Agree with Timothy and Ramsay. If the company has initiated the transformation to agile, they need to look at breaking down or changing the traditional org. structures that organize teams functionally with their own set of processes, objectives, and rewards. In this case, the test manager's action could mean either the QA organization is not on board with the transformation or the test manager's role and responsibilities, reporting structures and incentives, have remained the same so he/she may still feel responsible and accountable for the quality of the increments. This, in my opinion, would require a discussion with the individual leading the agile transformation to bring everyone onboard.
Possible suggestions are:
1. Train the Test Manager to have an understanding of SCRUM.
2. Include the Testing team as part of the development team. while they do not have something to test yet, they can start creating Test Cases based on the Sprint Backlog items. Then whatever can be tested, start testing them.
3. Offer a transition role to the Test Manager as either a Product Owner or as an additional Scrum Master to the team. Work with him, partner with him.
In addition to what Ian Mitchell has posted above, I suggest the team and test manager read this Scrum Alliance blog article from Pete Deemer, Manager 2.0.[a href="https://www.scrumalliance.org/community/articles/2009/december/manager-…"]Manager 2.0: The Role of the Manager in Scrum [/a]
While this is from 2009, I feel that it still rings true with the current Scrum Guide.