Spotlight Interview with Mark Levison

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 executive level to the individual developer and tester. Levison is also an Agile editor at InfoQ and has written dozens of articles on Agile topics and publishes a blog – Notes from a Tool User. Mark’s training benefits from his study and writing on the neuroscience of learning: Learning Best Approaches for Your Brain. To contact Mark Levison, please email him at mark@agilepainrelief.com.

Offshore testing teams are put between a rock and a hard place. By their very nature what they’re being asked to do isn’t Agile, at best it’s better waterfall. When work is offshored with an Agile team it would be better to have the whole team (developers, testers, ….) in one place.

Much of the magic that happens with Agile Software development comes from building quality into the code and not trying to test in after the fact. In addition, team members start to cross skill with developers learning more about testing and testers pairing with developers to complete feature work.

Much of that is beyond the control of the readers of this magazine. I won’t tell you to abandon ship or change jobs. I do suggest it’s important to have a good understanding on how this can work so you know what to advocate for. In the future, I think we will see more distributed Agile work and done well. I’m already starting to see teams at some clients with parts of the team in Canada and other parts in India. It works because everybody is working in the same body of code in the same sprint.

Testing is placed at the back of the bus but should instead be an integral part of the process. In addition, the Indians make a real effort to provide an environment where the people are well paid and want to stay with the business, reducing turnover.

1. Specific to testing, how important is it to have a process? Does testing only follow the development process?

In Agile/Scrum there isn’t a specific testing process, instead testing is part of every Sprint. The key here is to make sure that test occurs in parallel with development using techniques like Acceptance Test Driven Development (ATDD). Well done testing is really just an ongoing form of requirements elaboration.

2. Concerning “process” on testing projects, would you share with us some common mistakes & lessons learned?

As you see from the above note the most common mistake is to put testers on a separate team and try to test after the fact. The longer we wait between writing a bug/misunderstood feature, the harder it will be to fix. So efforts should first be put into the avoiding the bugs in the first place (writing tests first i.e. ATDD) and then finding bugs within minutes/hours of being written.

3. Do you see a big difference in process from in-house tested projects and outsource tested projects?

As I note above the difference isn’t so much between in-house vs. outsourcing as moving from having a combined team to separate teams working a sprint or more later. Assuming you’re working in the same cycle, there is still the additional overhead with the reduced communications bandwidth.

4. These days, in 2011, do teams commonly use or follow a formal process guideline, like TMM/TMMi or CMM/CMMi or TPI?

It seems not many companies actually use these. I’ve not seen any of these in use but that’s probably because my clients call me in to help transition them to Agile/Scrum.

5. Many companies call themselves Agile but have done nothing more than shorten the release cycles into sprints, cut documentation and thrown out process. When teams badly implement Agile, how can test teams work to implement team process improvement?

That is rapidly becoming one of the bigger problems in the Agile world, where companies think they know Agile but really its an excuse for cowboy coding. The key in this situation is to use the retrospective to ask questions. Questions that help focus on the underlying problem and not the individuals involved.

6. Sprint retrospectives have become a core practice in the Agile/Scrum world, could you share with us some retrospective techniques to make them most effective?

There are entire books devoted to Retrospectives: Agile Retrospectives: Making Good Teams Great. See also: Agile/Scrum Retrospectives–Tips and Tricks and Agile Retrospectives.

7. We know you are running some Agile testing UK user groups, could you share with us some realistic “best practices” in Agile testing process?

I’m unsure what you mean by realistic, that suggests a limitation I’m not aware of in the abilities of your team members. I’ve already listed the key areas for improvement when I mentioned development teams including testing, making testing part of the development process and ATDD. As for the “Best Practice” there are none, just good practices in the current context. (There are no Best Practices)

8. Test Measurement/metrics are often used in post-mortem meetings or for process improvement. Agile projects typically have much less measurement. How can we show or justify a need for process improvement with few or no metrics?

Agile Metrics are a difficult problem. There is really only one thing that matters, the high quality business value that we successfully put into use rapidly. That implies many things: bug free, rapid deployment (every 2-4 weeks is a good starting point). Focusing on anything else number of bugs, number of test cases, and percentage of code covered by tests will lead to behaviors that optimize for the measure not the delivery of business value. For more see: Agile Metrics and What is a Good Agile Metric?

9. Sometimes on traditional projects, test teams get a bad reputation for complaining because we are often under the harshest schedule pressure. Do you think this has changed on agile projects? Are our ”complaints” now heard as suggestions for improvement?

The key here is to use the retrospective as a conduit for issues, don’t focus on your problems. Focus on the effect on the customers. Instead of complaining “We were delivered very buggy code on Wednesday of last week” try “We spent alot of time dealing with unexpected problems on Wednesday of last week”. Change the focus from specific people to the problem and then ask your team mates to help solve the problem. Remember the goal is for the whole team to succeed in delivering a high quality application to the customer. We succeed in doing that as a team not as individuals.

In the next few weeks I will take some time to write more about the Testing on an Agile team, the item will appear on my blog.

Mark Levison

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 executive level to the individual developer and tester. Levison is also an Agile editor at InfoQ and has written dozens of articles on Agile topics and publishes a blog – Notes from a Tool User. Mark’s training benefits from his study and writing on the neuroscience of learning: Learning Best Approaches for Your Brain. To contact Mark Levison, please email him at mark@agilepainrelief.com.

LogiGear Staff
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

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 ...
Agile Automation Michael Hackett – Senior Vice President – LogiGear Corporation Michael Hackett Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the ...
To begin this article, it would be a good idea to, remember this key point: Agile Manifesto Value #1 Individuals and interactions over processes and tools Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much ...
Over the years many Agile proponents have come out strongly against offshoring some of the development team, and in particular against having a remote testing team. We made use of not one, but two separate outsourcing providers located in two distant locations. While we had many challenges, what we found was that by starting with ...
Maximize the function of your teams The Modern Agile philosophy created by the folks at Industrial Logic is one of the most exciting ideas I’ve encountered in a while. Moving beyond the pre-canned “You must do X to be Agile” mindset that I’ve seen becoming more and more prevalent.
LogiGear Magazine July 2012 Testing in Agile  
Janet Gregory draws from her own experience in helping agile teams address alternative ways to cope with roadblocks including projects without clear documentation, testers with limited domain knowledge and dealing with either black box or white box testing. For testing on projects without clear documentation, is exploratory the only method? I often make “tester errors” ...
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 ...
Application development and delivery teams are under constant pressure to release quality features as quickly as possible. CIOs rate delivering applications faster, with higher quality and with strong control on application development as their key priorities. What’s more, supporting this type of agile environment is particularly complex to IT teams that are also tasked with supporting ...
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 ...
SKILLS Agile teams need training! One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” ...
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 ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe