Spotlight Interview: Guido Schoonheim

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 ( 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 (

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 (’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 ( 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.

LogiGear Corporation

LogiGear Corporation provides global solutions for software testing, and offers public and corporate software-testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast and cost-effective results. Since 1994, LogiGear has worked with hundreds of companies from the Fortune 500 to early-stage startups, creating unique solutions to exactly meet their needs. With facilities in the US and Vietnam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

For more information, contact Joe Hughes + 01 650.572.1400

LogiGear Corporation
LogiGear Corporation provides global solutions for software testing, and offers public and corporate software testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast, cost-effective results. Since 1994, LogiGear has worked with Fortune 500 companies to early-stage start-ups in, creating unique solutions to meet their clients’ needs. With facilities in the US and Viet Nam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

The Related Post

Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al., Retrospectives are that tool.
Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations ...
Mark Levison has over twenty years experience in the IT industry, working as a developer, manager, technical lead, architect, and consultant. He discovered Agile in 2001 and is now a Certified Scrum Trainer and Agile Coach with Agile Pain Relief Consulting. Levison has introduced Scrum, Lean and other Agile methods to a number of organizations and coaches from ...
I have worked with testers on an Agile team before and it has worked very well for both the team and the customer. In my previous role at Bank of Ireland, testers who had come from a traditional testing background worked within our teams to help ensure we had quality deliverables at the end of ...
Distinguishing these terms from each other can be rather confusing. In an attempt to go back to the basics, Nadine Schaeffer explains in detail the benefits and the necessity of using realistic situations.
In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I’m a card-carrying Agile zealot, and to me its benefits are unarguable. Is your IT organization ready to be Agile, seriously? Score yourself on these ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part One of a Four Part Video on “New Roles for Traditional Testers in Agile Development” Michael shares his thoughts on “A Primer – New Roles for Traditional Testers in Agile” LogiGear Corporation LogiGear Corporation LogiGear Corporation provides global solutions for software testing, and offers ...
This is part 1 of a 2-part series. The 1st part will discuss the culture and mindset around Agile, and how Agile Quadrants are used. Part 2 will discuss how to use the Agile Quadrant, the significance of Automation in Agile Quadrants and how to use Agile Quadrants to overcome Quality Assurance headaches. Organizations aspire ...
Testing in Agile Part 1 – INTRODUCTION TO AGILE In case you missed the first part of the series in our last magazine issue from Michael Hackett, Agile’s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic.
Team collaboration is essential for testing embedded systems. Developing software for an embedded system often carries more risk than for general purpose computers, so testing is extremely critical. However, there still has to be a good balance between time spent on testing and time spent on development to keep the project on track. As consultants ...
Take our quick survey on Testing in an Agile Development Team! Agile‘s impact on software development teams is huge. For test teams it can be even more pronounced — and good, especially if your existing projects have been problematic. There are many positive things about the move to be more Agile and responsive in software ...
When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them. “He who knows to unlearn, learns best.” — Anonymous The following are some of the key aspects ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news