The "One Right Way"
For those who believe there has to be one right way to do something, especially in software development - there can be. But that one way isn't likely to come from a single individual. Through collaboration and teamwork, some of the greatest single ideas have evolved.
Currently there's a discussion going around the Blogosphere and Twitterverse about whether or not driving development with acceptance tests–particularly automated acceptance tests--is a good thing. Many expert practitioners have weighed in, including Gojko Adzic, George Dinwiddie, Ron Jeffries, and James Shore.
I find value in each perspective, and I know what works for my team, because we've been experimenting with different approaches for developing software for more than six years. If your team hasn't already figured out how to make sure you develop the code the customers want--at the quality level they need, in a timely manner, and all that good stuff--how do you make sense of all these different techniques? Most importantly, if you aren't enjoying your work now, how can you find more reward in what you do?
A Learning Culture
Personally, I think it starts at the top. Is the business really committed to making changes to address pain points and improving software quality? Or, are some managers just trying the latest development fad so they can look like they're trying to take charge?
It's funny to me when I hear people use the term "waterfall" when what they really mean is "hopelessly dysfunctional process where no good practices are in place." I've worked on a waterfall team with full test automation from the unit level on up, continuous integration, and constant collaboration between the technical and customer teams. We produced some of the best-quality software I've ever seen. If people have the wrong motivations or are lazy and undisciplined, I don't care what process you follow, it's going to keep failing. So, "agile" isn't the one right way either. It just tries to put the focus where it belongs--on getting good people and letting them do their best work.
Team Values
Let's assume management is willing to implement true change and to provide the time and resources for it to happen. Change has to start with a team's soul-searching. First, who should be on the team? With the "Whole Team" approach, everyone involved in developing the software--including testers--is on the development team, and they all take responsibility for quality and testing. I've seen the most success with this approach, but it comes with a caveat: Each team member must be seen as having equal value.
Next, the team has to agree on values. It's easy to say, "We are committed to delivering the best-quality software we can," but what does that really mean? If the team is going to use excuses such as "We can't do TDD because of the architecture" or "We can't do CI because our product is too complex," the team is not really committed to quality. Every team member must take responsibility for quality and for completing the testing activities to ensure it. Developers hate touchy-feely conversations like this, but change won't happen without identifying the values and principles that will guide that change. The team has to agree that they won't get stuck–that they will find a way around every obstacle.
Value-guided Experimentation
So, let's say management values quality over speed and nurtures a learning culture where mistakes are tolerated and experimentation is expected. The team has established its values about their work and product. Now, the team can start taking baby steps to improve their development practices and processes. At every step, they look to their team values and principles to help decide what practice to implement or what tool to try.
"We're feeling rushed, but if we don't stop and refactor this test design now, we will pay for it later with higher test maintenance 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
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.
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.
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>
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>
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.
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!!!
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.
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.
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.