As CTO of Xebia and highly experienced in offshore testing in India, Guido articulates his methods in addressing common challenges faced by the in-house and offshore teams. He weighs heavily on strategic tactics as well as key cultural aspects to execute efficient and effective Agile methods.
1. I work at a US-based company and we have been offshoring for a few years. We have a good working relationship with the offshore team; the work and communication is good. We are now implementing Scrum and want to continue having these offshore folks on our team. We have been distributing mainly testing tasks to them. What would you suggest is the best work to distribute to them?
The goal of Scrum is to deliver the right fully tested production ready software at the end of each sprint. That means you can no longer hand off testing as a separate phase. Testing now needs to be incorporated as a continuous team activity into your sprints. This means that your offshore testers should become part of your Scrum teams and work with you on getting tasks from “to do” to “ready for testing” to “done.” Creating automated test cases should start in parallel with actual development of features.
2. We have people we used to call testers integrated into The Team, fully tasked during sprints. They can’t keep up with building and maintaining our automated regression suite during sprints. The regression contains longer business scenarios, workflow, and interoperability tests. We want to outsource the regression suite. What do you think?
In Scrum, there is only [one] role responsible for delivering a fully tested increment and that is The Team. That means that the division between testers, regression testers and developers is an artificial one, secondary to team goals. As a team member you will have specialties that you use, but at the end of the day you need to maintain your automated tests as a team. That means that you should never write more code than your team can test. Instead developers need to help with the test automation and testing where necessary.
Otherwise you increase technical debt and put the project at risk. And that is irresponsible, even if you mean well! Test automation is the single most important thing for a team to keep a high velocity. Never ever outsource anything this crucial outside your team because then you can not commit to delivering fully tested software anymore, when part of that is [out] of your hands.
3. The people who used to test in our old style development projects are now integrated into our Scrum teams. They have great user knowledge, are extremely helpful for details on user stories, run our continuous integration/build validation process and conduct user story validation tests. These members do not write code. What other things can former testers do on a Scrum team?
Building good software is a matter of providing instant rigorous feedback on your quality. Automated functional regression testing is one of the most important aspects to getting this right. Focus on getting this in place. After creating the initial setup as a team, it is usually the (former) testers who fill the tooling with cases and maintain the test cases during the sprints to resolve any broken tests. When you have full regression and keep up with it, the team generally needs two testers for every four developers.
If you have this in place and have extra capacity then I suggest work that is client facing, such as developing user stories, help with backlog grooming and other tasks that require a mindset from a client perspective. Or you can of course reduce your team size.
4. I work at an outsource development company. We use Scrum with many clients. Some are successful, others are not. The projects that do not run so well are all, as Jeff Sutherland calls them, Scrumbutts. They pick and choose what practices to implement. In all those companies, it is not standard to invite the outsource team to the Sprint Retrospective if one is in place. Do you have any suggestions how I can help the team improve without going to the retrospectives?
No team is working to their full potential when they form up as a Scrum team, and that is not the point. The point is to generate quick feedback and heighten learning so that you become better rapidly, thus achieving hyper-productivity. That means team retrospectives are crucial. Before giving you more options let me say that there should be no excuse for a ScrumButt implementation. Your first priority should be to create a proper Scrum. When working with offshoring or outsourcing, that means acknowledging that you are One Team and should be treated as such. That means involving everyone in the full Scrum ceremony. This is worth fighting for and getting in trouble over, as you are all equal in a Scrum team.
If your client refuses a full retrospective with business + onsite team members + offsite team, then have your own smaller retrospective previous to the full one with the onsite + offsite team members. That way you can discuss your points and the points of the onsite team members and they can take the relevant points to their local retrospective and share the results with you afterwards. Stacking retrospectives this way might be helpful in creating a safe environment to share issues, however, it is also added inefficiency that you should try to avoid.
Should you be unable to organize this then share your unasked feedback to the onsite team members and send them a questionnaire to fill out in return.
5. Are there any situations where you find Scrum does not work, e.g., safety-critical, regulated software? Large crossteam integrated software systems? Device development where the software will have one big release and no iterations?
Managing complexity by up front design has proven not to work. We need to divide large problems into small chunks and learn rapidly about the domain and the problem at hand. Probably we also need to fail 2 or 3 times when doing something novel, as a part of that learning process. Scrum enables this learning, and combined with proper risk management enables us to fail fast in order to get it right at the lowest cost.
This means that the more complex the system, the bigger the need for an incremental approach!
There are things that you need to add both as deliverables and to your definition of done to get your quality up to 99.999% and to ensure compliancy. After implementing Scrum in mission critical projects─finance and automotive device development─I can tell you that these are in no way exclusive to doing Scrum. The tricky art is in finding out how to divide your work up in the right order, which is more an engineering and analysis problem then a methodology problem.
6. I have a situation where management (the chickens), particularly the sales team wants to keep control of functionality delivery and schedule. But they say, we have to be more agile, stop writing so much documentation and be faster. Do you have any suggestions?
First of all, our main goal is to provide maximum value to our client and /or company. That is why the product owner determines what goes into each sprint. Value however is measured not just by the output of today’s sprint, but over the lifecycle of your product.
Documentation should always have a clear identified audience and clear criteria so that you know what “just enough” is. Since creating documentation is not a favorite activity for many people I assume you have a good reason. Try to put that reason into velocity or risk numbers and make clear how much you save by doing so.
On the other hand your management might have a good reason for wanting to speed up, and the discussion about documentation could just be a symptom. Find out why they want to speed up and brainstorm with the team on ways to help reach that real goal, along with other ways to go faster (like getting managements help to finally solve some really nasty impediments that you have institutionalized).
7. I work in an offshore outsourced testing company, some clients have become seemingly very agile but demand a lot of test documentation. Test cases, bug reports, and often, test plans. This isn’t lean and I think it points to a trust problem. What can we do when the team cuts back most of their documentation, wants me to be more agile and rapid but asks for a lot of documentation?
It is quite natural for clients to ask for extensive testing documentation.
The thing to question is why they are requesting this. This comes from an understandable underlying need to validate your work. So the best way to lighten your documentation load is to be more transparent about your work in another way.
For my clients this means somehow showing a lightweight logical test plan and actual physical test cases along with test results.
This is where test automation can help you (again). By creating your functional test cases in automated tooling right away they can be witnessed later at no extra effort. Using a tool such as Fitnesse (http://fitnesse.org/) will allow you to specify both logical and physical cases in a simple wiki markup per story or scenario. To integrate GUI testing into this, have a look at Xebium (http://xebia.github.com/Xebium/).
Being smart about your tooling will save you from large additional reporting effort. The cases that you create in your tooling can be your documentation. This also lightens the regression workload considerably, and it can make for a very impressive sprint demo if you use it right.
8. I do most of the non-unit tests on my team. My team does not always value my estimates. Estimating is often difficult. I sometimes have to think about all the possible data and platforms and paths and uses—the majority of which are not captured in user stories, my story-point estimates are usually pretty different than the rest of the team. It’s an education process for them and sometimes I am way off. Do you have any suggestions about estimates including testing?
That is a tricky one and teams tend to come up with different approaches. Generally, I see two approaches being used the most:
1. Give separate estimates for each story for development and test. Then see if the amount of work matches the availability of test and development capacity in the sprint.
2. Only estimate development effort during team planning poker, and have the tester(s) remove stories from the sprint until they too can commit to the result. This is often done when there is only one tester, since planning poker across disciplines can be frustrating and does not always make sense.
My preference is the first approach, to involve the rest of the team as much as possible. If you need a sparring partner then ask one of the developers to become tester for one or two sprints. Afterwards they should be able to think with you a lot more. Alternatively, what I have seen work is to have a tester from another team sit in on your planning session and vice versa.
9. What characteristics should we look for when selecting people best suited for Scrum teams?
The most important part is to create a team that works well together. This is just as important as technical competence. I have seen a team of only top notch engineers being a total disaster, because of ego’s colliding over every decision. So look at personality types and the ability to communicate and collaborate as well as technical competences. There is no room for prima-donna developers in a team, no matter how good they are.
This comes together in team composition, so think about what makes a balanced team. For instance get a scrum master who is a good communicator and likes organizing, one or two deep thinkers for tough problems, two solid hard workers, a savvy tester and a more junior tester.
Also have a look at Tuckmans stages of Team Development if you want more structured guidance in turning a group of people into a great Scrum Team (http://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development).
10. Do you see any cultural issues implementing Scrum for teams not in the U.S. or Europe; such as self-directed teams in cultures that are more comfortable with follow-the-leader?
Scrum is about liberating the potential of all team members and for different cultures, this works in different ways. Something that helps me understand the differences is Geert Hofstede’s cultural dimensions theory (http://en.wikipedia.org/wiki/Hofstede%27s_cultural_dimensions_theory). Scrum seems to have the quickest initial adoption in countries that have a lower Power Distance Index (PDI), meaning less orientation towards hierarchy, such as the Netherlands and Scandinavian countries.
From personal experience I can say that in countries with a strong hierarchical culture, it is crucial to create a strong company and team culture of equality and openness, in order to be able to have a proper Scrum. You need an open environment without strong blame or power influences to get all valuable ideas and feedback from all team members. This is hard when team members worry “what impression will people get of me when I ask this question.”
How to most effectively enable your team members works different in every culture and therefore so does implementing a really good Scrum. Just take those specifics into account and you will be fine.
