The "One Right Way"

[article]

cost."

"Testing is always squeezed to the end of the iteration. What can we as a team do to address that?"

"We misunderstood that requirement. How can we make sure we're on the same page as the customers?"

Your team values light the way.

It might take many months for the team to feel like they've turned the corner and have significantly improved their product's quality, but I bet the customers notice a difference pretty quickly.

One Right Way

I can't tell you the one right way to test and develop software. If you don't have the enlightened management I've described above, try to enlighten them. Ask them to identify the biggest pain points and work with you to experiment with ways to address those. If you don't have the motivated teammates eager to take responsibility for quality and testing, try leading by example. Show what you do with your own passion for doing good work.

The one right way for your team to code and test will continually evolve over the years. In fact, I'm sorry to tell you that you'll never find the one right way; it's a moving target, but you'll get closer and closer to it.

Please read all these blog posts and as many books as you can. Participate in as many online and local user groups as possible. Keep an open mind. Bring the ideas and techniques you learn about back to your team. If one seems likely to help your team overcome a particular obstacle, give it a try. If it doesn't work, you learned something. If it does, celebrate and move on to the next obstacle.

User Comments

9 comments
Anonymous's picture
Anonymous

Great post, Lisa!<br><br>I know Jim Shore and have complete confidence that they're doing fine. My recommendations are different. But as you say, each team has to ensure that it solves its own problems.

March 2, 2010 - 11:48pm
Anonymous's picture
Anonymous

Good day Lisa,<br><br>Great post! There is a lot that depends upon the environment around a team to support effective experimentation. Thank you for providing a great wrapper around the recommendations on "how-to" implement Agile practices effectively.

March 3, 2010 - 7:01am
Anonymous's picture
Anonymous

Valuable perspective on the debate, Lisa.<br><br>One thought; this puts a lot of emphasis on Management being the ultimate facilitators of a shift towards better quality (that's the point of your post, I realise). While that may be necessary to some degree, in your experience, how much change can be pushed up, from the team, as opposed to being pushed down from management? <br><br>Presumably, the ideal distribution is about 50/50, with management supporting the team and getting out of their way, while giving feedback and providing some quality goals that align with the business' needs. At the same time, the team are pushing up to management, doing the quality/value agreements and self-improvement while continuing to deliver.<br><br>A, seemingly, impossible scenario would be if the team were demotivated /and/ the management were only interested in paying lip-service to quality where it served their interests (e.g. payment milestones tied to customer acceptance testing).<br>

March 3, 2010 - 2:06pm
Anonymous's picture
Anonymous

Awesome post!<br>I like how you bring the attention to the manager as a facilitator and coach.<br>"If you don't have the enlightened management I've described above, try to enlighten them. "<br>The Agile team have to help create more Agile managers!<br>cheers,<br>Paulo<br><br><br>

March 3, 2010 - 5:00pm
Anonymous's picture
Anonymous

James and Paulo make good points I agree that if management is just paying lip service to quality, well, if I were on that team I'd get another job (which I have done on a couple of occasions in my career). <br><br>I have had some success with going to management and asking, "What is your biggest area of pain?" Then I ask them to discuss some options to address it. For example, one management team told me their biggest problem was requirements. Either way too much time was spent gathering requirements, so that there wasn't enough time left to code (and certainly not to test), or there were no requirements at all. I proposed trying ATDD, using test cases in place of requirements documents. They were willing to try that, and it was a big success.<br><br>I always recommend Rising and Mann's Fearless Change if you are in a situation where you need to try to get management and/or teammates to try new things.<br><br>That said, you can't always fight the culture. In the above case, developers were so often rewarded for being "heroes" by finding out why the website crashed, there wasn't a lot of incentive to get a nice steady pace of high quality development going. We testers were able to do some good work, but our impact on quality was obviously limited. For example, we had automated GUI tests, but the developers did not automate any unit tests.

March 3, 2010 - 6:36pm
Anonymous's picture
Anonymous

Good Article!!! But, it is very difficult for someone to percolate the change at the "Management" Level. Plus, in today's world and age, we live in a very FR"agile" world, and with each team implementing what they think as agile, it ends in so much of a fragile process, rather than agile!!!

March 11, 2010 - 8:36pm
Anonymous's picture
Anonymous

Great post!! As with any process, involvement from all members is important and key to sucess. As you said, there isn't a one technique that solves it all....it has to be the one that best fit to your team needs.

March 18, 2010 - 4:16pm
Anonymous's picture
Anonymous

Excellent post. You make good points about how 'The Right Way' is born out of the teams values, actual experience, consensus, culture, and must be grounded in management support. In practice, I found that neither a complete hands-off approach nor a us-versus-them (we have our priorities, it is now up to the developers and testers to deliver on that) attitude from management is productive and conducive to good quality.

March 18, 2010 - 10:31pm
Anonymous's picture
Anonymous

I can vouch that in the years (is it really about a decade since we contributed to that early IEEE website on QA and testing with XP?) I've watched Lisa's approach develop, the contents of this post really rings true as much today as it did then.<br> <br>Development teams have to <br>1. pull together, <br>2. be disciplined about how they work and handover between each other, <br>3. learn together, <br>4. have a structure for change and experiment that doesn't derail everything else, <br>5. focus on the customer requirement and meet the acceptance tests,<br>6. be professional enough to recognise that some things must be done even if the customer never sees them (examples? defensive programming to avoid array overruns, build in data security, code structured so it can be easily maintained)<br><br>Some agile advocates have claimed item 6 isn't needed, item 5 will be enough. I can't agree. I'm not asking for over-engineering (that is costly) but I do want the product to be robust enough that the customer stay satisfied. (pays on time, orders a maintenance or support contract, comes back for more work, recommends us to their friends - take your pick they are all good outcomes for the development shop)<br><br>These days, I'm less in QA and testing and more in managing business projects and programmes. As a customer, I don't want to have to specify every bit of good practice that should be in the product - I'm have plenty to do getting users to be precise about the business needs and functionality required.<br><br>The same approach is true of project planning - sometimes there are things that seem like wasted effort that need to be done so that the overall work brings benefits. My guess is that item 6 is universal - if a job is going to deliver in the longer term, it needs to be built on good foundataions and finished to a professional standard.

April 3, 2010 - 5:26pm

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01