As we saw in the first part of my two-part interview, Crispin says the Waterfall might work in some circumstances. “If your industry is slow changing and doesn’t require that software-providing new business value be delivered more frequently than every six months or a year, Waterfall could work,” she said.
“However,” she added, “few industries are like that nowadays.”
In this installment, Crispin tackles some common knocks on Agile and gives her thoughts on DevOps.
One criticism of Agile is that projects can be hard to predict in some areas, such as timelines and budgets. The reason: Agile projects supposedly lack a concrete plan up front. What are your thoughts about that?
Software projects are inherently hard to predict. The transparency of Agile projects, where any executive can understand the current progress at a glance, combined with the iterative and incremental approach, helps businesses plan more effectively. For example, I joined a company in 2003 whose software development was failing for a number of reasons. The transition to Agile was not smooth, but even in our first iteration, we were able to deliver a small new piece of functionality for the website. The business stakeholders were thrilled. They gave us time to learn the skills we needed to build a high quality product. Over time, our overall estimates for upcoming stories, combined with our average velocity, allowed the business to plan well enough for the coming quarter. The market for the product was so dynamic that it wasn’t worth trying to plan in detail farther ahead than that.
Agile doesn’t mean “no planning.” You plan just in time, you deliver minimum viable chunks to get validated learning from customers, and you shorten your feedback loops so that if you fail, you fail fast and you can adjust and go forward.
Another common knock on Agile concerns its emphasis on intense user involvement and collaboration, which supposedly can be problematic. This argument holds that this type of development is time-consuming, and that the loss of a key designer in the middle of a project can be a major issue. What are your sentiments about this?
You might invest more time developing a story together with all necessary roles on the software delivery and customer teams, but you’ll “build the right thing.” When we apply Agile values and principles correctly, we don’t waste time delivering a feature that doesn’t provide value to the customers and the business. And you build it right, so that you don’t waste time later on fixing bugs found in production. Collaborating allows us to identify issues and questions as we go along and answer them, rather than have a handoff “over the wall” and then lots of delays as separate teams send defect reports back and forth.
Here’s an example. We have designers on our team. In addition to attending the stand-up meetings for the delivery teams they’re working on, they have their own daily stand-ups so that each knows what the other is working on. We testers work closely with them on both upcoming stories and the stories we are testing. It saves us a lot of time, because we can ask questions, identify potential issues and address them right away.
What tools do you recommend for use in Agile testing?
Each team needs to first decide which tools might help them, then try them out to see what fits their context. I have to even back up further – the whole software delivery team should start by deciding the level of quality to which they are willing to commit. Then they have to make that commitment meaningful, taking on team responsibility for quality and making sure testing activities are planned and completed.
Bring up obstacles to testing in your retrospectives. Then brainstorm experiments to help chip away at those problems. Those experiments might require tools. For example, let’s say that when stories are demonstrated to customers, the customers say, “No, that isn’t what I asked for”, and stories are frequently rejected multiple times.
Your team may decide to ensure delivering what the customers want by guiding development with tests based on customer examples, a practice known as acceptance test-driven development (ATDD), specification by example (SBE) or behavior-driven development (BDD). You’ll collaborate with your business stakeholders to decide what those examples will look like and how you want your tests to look. Then you may start looking into writing your own test framework and libraries to support that, or using an open source or vendor tool.
You’ll try some of these out side-by-side to see what works best for your situation. It’s a big investment, but it will prevent a lot of waste.
Agile isn’t magic. It doesn’t make the challenges of developing software go away. Agile values and principles can be applied to help good people do their best work, and collaborate to create the maximum value for the business.
What are your thoughts on the use of DevOps as a complement to Agile development and testing?
DevOps is a popular term now, but the idea of developers doing operations work and system administrators supporting things like continuous integration is nothing new. Throughout my career as a tester, I’ve done some system administration and database work myself. I’ve also worked closely with programmers, system administrators, database experts and others to shorten our feedback loop provided by our configuration item, ensure the best return on investment for our automated tests, and build test environments that simulate production well enough for effective explorator