I find that one of the most difficult aspects of change a team may have to undergo is one of culture.
Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus. But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.
Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile. For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also. While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience. But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.
To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy. This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.
One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.
One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers. When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing. Most of the developers were ready to do this, but when pushed, the testers - and test manager - somehow managed to find enough time to do the testing after all (by working weekends!).
Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"
A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours. But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.
To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular! Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous. This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too). Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.
Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus. But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.
Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile. For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also. While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience. But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.
To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy. This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.
One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.
One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers. When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing. Most of the developers were ready to do this, but when pushed, the testers - and test manager - somehow managed to find enough time to do the testing after all (by working weekends!).
Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"
A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours. But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.
To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular! Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous. This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too). Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.