I've been doing agility for about 30 years, long before it was called agility. It started as a simple way to leverage feedback loops to converge on answers—it was agility with a "small a." It was a way to get better products out the door vs. waterfall. Then two things that were big happened. The Agile Manifesto, which focused on small teams—I think agile works with big teams as well—and more focus on human nature vs. process nature, which is where Scrum comes from. There is a focus on self-organized teams, letting the team be more fluid and people not playing roles. It has resonated with most developers and proven itself to allow teams to be more productive. Scrum brought in the notion that you need to be constantly trying to get better. It's the Scrum Master whose job it is to help the team get better. I don't think we saw a role like that before in software.
What gave Scrum a leg up is when they started certifying people—that upped its prominence. Scrum appealed to a lot of developers, and combined with certification, which appeals to corporations that like certificates to hang on the wall, it made Scrum become prominent. What about Extreme Programming?
If XP had offered certification, I think it would've had the same effect. Scrum as a process is very generic. XP is purely for developing high-quality code in an object-oriented environment; it knocks it out of park in that environment.
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
XP brought the notion of test-driven development and paired programming—all the technical processes of XP were a brilliant edition to software engineering, not so much for agility, but to enable agility by creating changeable code. It was a tremendous boon.
Since Scrum is for any complicated project, not just software, what most trainers/coaches believe is if you're doing agile in an object-oriented environment you should use XP practices. You can call yourself a Scrum or an XP team; the differences are in the details and the Scrum Master role. I don't think when you're following [XP] practices religiously that you're going to be very self-organizing, which is where the Scrum Master fits in. There are arguments that Scrum trainers are not pushing XP enough. So should agile teams blend Scrum and XP? best you can do right now for small team development is the Scrum process with a Scrum Master and XP practices inside the team. Scrum surrounding XP is just the right thing. The bottom line is Scrum teams not doing XP are probably hurting themselves, and they should know better. How has the agile approach to quality and testing changed the role of testers and QA?
Speaking as a Scrumist, you don't have testers, you have testing; testing is ubiquitous and done by anybody who can run a test. Since you have self-organizing teams you talk about testing and developing, but the fact is people with testing skills are different than people with development skills. You need both types on the team, Testers help developers write good code by being part of test-driven development; testers help developers figure out if they're doing the right thing. Developers tend to be boundary case challenged, so you need test heads in the room.
The first two people I hire [for an agile team] are an architect and a tester. A trained tester is used in many different ways; as a member of the team he works side by side with developers in designing tests that developers are coding and running all the time. Where testers really make their money is in exploratory testing—figuring out what's missing. You talked about metrics at Agile 2009. Why do you think the industry has such a poor track record with metrics?
Because managers use metrics for the wrong reasons; metrics are there to tell you the truth about something, and your job is to adapt to the truth. When you're [simply saying] 'be faster,' what you're really saying is 'cut corners.' [The issue is] how to make a team faster without damaging them.
Good metrics tell you how much product you're producing, how much value. A team producing product is what Scrum is, so you have to metrics about teams and products, not individuals or tasks, but units of work that produce products and stories. Is the team winning the game is the question.
I'm constantly barraged by organizations that want metrics to tell me how good individuals are, and I keep saying that's not something you can measure. They say, 'How do I know who to fire?' I say, 'Ask the team.' Ask the team how to cut costs. They know, and they know what they can do less of/more of. Every metric can be used for evil, but if you use a metric badly it will create technical debt—meaning, the viscosity of the code. How hard is this code to wade through/work with? It has nothing to do with functionality, but is it badly designed? Incomprehensibly written?
A metric tells you some truth that you have to adapt to. By showing [management] where you are, it gives management the knowledge they need to be agile on their end and modify what they have control over. It could be the release date, or modifying the scope, or adding more people. Good metrics only exist in a trusting environment. You've got to trust that [management] won't use it to beat you over head, and they've got to trust that you're doing best you can.