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 development, but like so many things the devil is in the details! What Agile actually means in your organization and what practices will be implemented vary dramatically from company to company. There is a rush to be Agile these days and I see it mis-implemented more than well implemented. I believe “Agile” itself needs to be reunderstood, if not reconceived.
Here is what I mean: Agile does not equal faster. It is not Scrum, it is not XP, nor is it Lean. Agile is not an SDLC or how to manage a project or how developers write code. Agile means too many different things to many people. This series of articles in not meant to be an Intro to Agile. The discussion here centers not on what Agile is or is not. It focuses only on those aspects which directly impact software testing and how traditional testers need to be prepared to be Agile.
Most of the white papers and speakers you find these days on Agile, Scrum and XP focus on its practices. There is more than enough written about things like test-driven development, sprint retrospectives, and estimating user stories. My focus is different.
First, I will focus on software testing. And by this I mean testing in the traditional sense, not in the unit testing/user story acceptance testing sense. Secondly, I will focus on the areas of Agile development that are most overlooked but quite important to successful implementation of Agile, such as team dynamics, self-forming or self-directing teams, and tools.
Let me layout some overview themes that guide my views on agile and are critical points to be made about this movement.
1- These ideas are not new. In 1987, deMarco and Lister famously wrote about software development teams in their groundbreaking book, Peopleware:
Here is what I mean: Agile does not equal faster. It is not Scrum, it is not XP, nor is it Lean. Agile is not an SDLC or how to manage a project or how developers write code. Agile means too many different things to many people. This series of articles in not meant to be an Intro to Agile. The discussion here centers not on what Agile is or is not. It focuses only on those aspects which directly impact software testing and how traditional testers need to be prepared to be Agile.
Most of the white papers and speakers you find these days on Agile, Scrum and XP focus on its practices. There is more than enough written about things like test-driven development, sprint retrospectives, and estimating user stories. My focus is different.
First, I will focus on software testing. And by this I mean testing in the traditional sense, not in the unit testing/user story acceptance testing sense. Secondly, I will focus on the areas of Agile development that are most overlooked but quite important to successful implementation of Agile, such as team dynamics, self-forming or self-directing teams, and tools.
Let me layout some overview themes that guide my views on agile and are critical points to be made about this movement.
Things that have a strong positive effect:
-
-
Fellow team member interactions
-
-
-
Workplace physical layout
-
Protection from interruptions
-
Things that have a negative effect:
- Overtime
- Lack of closure
Agile addresses these issues like no other set of ideas in software development or project management before it. There is no Agile, whatever project management mechanism you choose, that is not based upon teams sitting together and focusing on one set of tasks with excellent, full-team, daily communication.
2- Agile is not about getting faster!
Agile is about people and interactions being more important than processes and tools, working at a sustainable pace, and self-directed teams!
People working on Agile projects should be more satisfied with their work, do it at a more sustainable pace and feel better about the quality of the released product. If not, your company has really missed the boat. If Agile at your company is about a tool, or set of tools implemented, something is very wrong.
3- Testers have recommended many Agile ideals and practices for a long time.
-
-
“Unit testing is really good- we should do more!” How long have testers been saying that?
-
-
-
“Accept the fact that we always accept late changes rather than pretend we don’t.”
-
-
-
“I [formerly known as QA] don’t own quality- we all do!”
-
-
-
“You are going to stop calling my team QA.”
-
-
-
“We need to automate more”
-
“We need to design the code for testability.”
-
The fact is that test teams have known many good Agile practices for a long, long time. In some cases, using more Agile development practices may not change the job of a traditional tester; the focus of testing may not change very much. But how the projects are managed will be a change.
The following series of topic discussions on aspects of Agile development will explore how implementing Agile development practices and values can dramatically change your job satisfaction, level of respect, and work situation for the better — if practices are implemented and not just given lip service.
The series:
1- Testing in Agile
2- Team and People issues
3- Practices and processes specific to testing
4- New skills and training for traditional testers
5- Tools
NEXT, PART 2- TEAM AND PEOPLE ISSUES
Take our quick survey on Testing in an Agile Development Team!
