Manage to Test

I’ve been involved in one way or another on many project teams, many of which are “going Agile.” Often these teams will look to the examples of other teams inside, or outside of the organization. One such team a few years back decided to model their process against a different project that had earlier adopted Agile. On the one hand it was good, because they could tap into the project team’s processes and experiences. On the other hand, it might be bad because of the differences between them — the new project is much smaller, with different people, a different organization structure, a different user community, and a different environment. Actually, it would have been better if they came up with their own processes rather than using those from the other team.

I understand that this seems counterintuitive.

Agile teams that have been working together for a some period of time make changes. As they move through Shu-Ha-Ri they inspect and adapt; they come up with new processes to improve the workflow. That’s how it should work! But sometimes there are circumstances and contexts that limit the amount of change. Examples include org structure, upper management buy-in, off-shoring, user availability, audit concerns, and many others. If a team doesn’t have the same constraints, they would be well-served in examining any borrowed processes and practices borne out of such an environment.

Here are the chief problems I discovered when I went to help out this team.

The team isn’t together physically — One of the most important things to do on an agile project is to move all the people on the team into the same area. Communication is the key issue. It appears this team is staying in their same cube structure — testers at the end of the hall, Dev in a section over here, Management over here or in a different building, etc. It doesn’t have to be this way for this team; they can sit together.
Testers aren’t involved (yet) — I talked with the QA manager (who is trying to manage the day to day work of testers on two agile projects plus a few others…hmm) who says that the her direct reports on the project had not been invited to any analysis or design discussions. It’s still early in the project, but testers are part of the team. They need to be involved now, not just after the first build (which was due out later that week). It’s a very common pattern where each “team” – analysis, dev, test – do their bit and pass it on. And really, that’s *exactly* the type of mindset that Agile attempts to break down, but it’s one of the most difficult habits to break.
Users aren’t involved — They still don’t have any users or representatives participating in any way, save being interviewed some time ago by analysts. The other team they modeled after didn’t either, but that’s because their users were unavailable and unwilling to participate. This team’s users are close by and, from after a little questioning, quite willing to participate.

We got this team to make some changes and they continued to adapt and get better, and that’s great. Transition is difficult; moving to Agile is more than just saying “I’m going to put out a release every x weeks.” There are important aspects of real-time collaboration and constant feedback that are of crucial importance to a successful implementation. It’s a great idea to look to other teams with experience to get some ideas, but simply adopting processes without understanding context or understanding the principles behind the methodology you’re implementing will make a transition even more difficult.