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

LogiGear Magazine – November 2010
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 ...
How to fit automated testing into scrum, and keep testers in sync with other teams One of the benefits of the approaches of agile projects is their friendliness towards testing. The testing activities, and the testers with it, are integrated into the teams, and testing and quality are redefined as team responsibilities. Automation nowadays is a must-have ...
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 ...
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 ...
If your Agile implementation is not about people, you’ve missed the boat! The most profound impact to becoming more Agile is happier teams! Agile manifesto Value #1: * Individuals and interactions over processes and tools Words like these do not show up in Waterfall or RUP SDLC process descriptions. Agile cannot get more basic than ...
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.
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 methods were developed as a response to the issues that waterfall and V-model methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed. From www.agiletesting.com.au A software tester’s role in traditional software development methodology, a.k.a waterfall & the V-model can be ...
Video narrated by MICHAEL HACKETT – Certified ScrumMaster This is Part Two 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 ...
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.” ...
Keeping an eye on the horizon in the testing world is an important part of staying in the game. Hans is no stranger to looking to the future with eyes wide and ears open. His expertise is what makes Hans valuable at the STARWEST Expo, which he recently delivered two talks to.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe