Lesson: Agile Development with Ian McFarland

Step #5 Teams: Agile is not something that you go; it is something that you do

People talk a lot about Agile. One of the things that I see all the time that I think is a real tell that they're not on the right track is they say, "Oh, yeah, Agile. We went Agile last week or last year. Yes, we went Agile." Usually, that means that they hired a bunch of Scrum coaches to come and put a lightweight veneer of not very deep Agile ideas on top of their very waterfall, very structured organization. The thing with Agile is it isn't something you go. It's more something you do. It's something that you embody. Your whole team has to be functioning in a lightweight, trust-based, rapid iteration style in order to get all the value out of it.

One of the things that comes often too, is who should do the testing in the software development team. Traditionally you'd have this very sort of disaggregated, you'd have your designers off in one silo, your product people off in another silo, your marketing people off in another silo, you'd have your developers that the stuffs gets thrown over the wall to down here. Then eventually you'd have your QA people, and they would tell you whether or not the developers had implemented what the designers said and whether it worked. It would be this very long feedback cycle, multiple stages, weeks or months or years would happen between when somebody "solved all the problems" to when somebody implemented what they thought that person thought. Then you found out whether or not it was ready to ship to customers, and people didn't even really think about "Oh, and then user feedback," I mean, that was customer service, it was a whole different thing.

What we see in high functioning small teams, and especially start up teams, and ideally this is also true in larger organizations who just have more of these small teams, is that the developers are writing the tests, for the most part. Where there are QA people, good rigorous developer testing means that the kind of testing that you do isn't automated, isn't sort of scripted QA tester type stuff, it's more real QA analysis, like exploratory testing, "I'm a good QA person so I know that probably people didn't think about character set support, so I'm going to try typing in a bunch of Chinese stuff and a bunch of Indian stuff, Hindi or something in it and see if it breaks in interesting ways. Or probably people didn't think about this edge case." In really well functioning teams, those QA people aren't spending time on regression testing, that's all handled by the test suite.

But then they are then writing tests that are automated and whether, it's again a skill-set question, whether or not they're directly writing like selenium tests or some other, could be cucumber tests, if they're writing scripts that are directly executable or if they're pairing with developers in order to produces tests that run in the regression suite. But the idea is when you find an edge case; you want to make sure that you have test coverage for it so that it doesn't recur. And that's gotten a lot easier than it used to be, obviously with uni-code everywhere. If you just follow good practices, you don't run into these kinds of issues, but there's still security edge cases, all sorts of other edge cases that may not happen in the dev team. It really depends, again, on your dev team and what their skill sets are. So, uni-code is a character encoding standard that encodes basically all modern language character sets.

The highest functioning teams that I see are the ones where there isn't a notion of role and stage, but it's more a question of people have this skill set so they happen to be really good at QA, they happen to be really good at development, they happen to be really good at design. Those are real distinctions. You're not going to, in general, have somebody who is a brilliant designer and a brilliant engineer. Those people do occur, and often they're off running their own startups, but what you want to do is take all these different skill sets and put them into an integrated team that functions as one organism where there is mutual respect, again let's leave QA out of it because I think most early stage companies there's not really a QA stage, really it's the product owner who's going and looking at stuff, who's thinking about "does this do what it needs to do?"

Especially between design and development, it's so much more effective to have the designer sit down and pair with the developer and have that knowledge transfer happen in the space that you're actually working in. You're working on the material and you have a designer who knows enough about CSS and how it works, who knows enough about how interaction works on the web space, sitting down with the developer who knows how to implement all this stuff and really does a good job. The communication happens really naturally. The designer ends up learning a lot about how this code base operates and can make better informed decisions about what is a good, efficient way to build such and such that has meaning for end customer but is also implementable.

What happens all the time when this is done in a vacuum is people try to be people pleasers. The designer will come up with what they think is a simple to implement design that is not as good as what they wanted but they think it's going to be simpler and then it turns out that if they'd just talked to the developer, the developer would tell them "Now actually the thing you wanted to do, we have that already." I've seen this, where a designer would come up with this, not great design, but something they thought was simple and then the developer would spend all this time trying to make it just like that when ultimately if they had just talked they would have realized "We could have just used the actual built-in drop down menu and it would have been exactly what we wanted".