The Misinterpreted Developer!

The term "developer" is not meant only for programmers. However the term developer became so popular in the last decade that it became a synonym for programmer. That's no surprise, given the way programmers welcomed the tag. However, developer has a broader sense in Scrum teams. Not only programmers but also testers focus equally to develop and deliver a quality product that provides some business value. This is the reason that in Scrum that there is only a "development team," regardless of programmers or testers. Organizations may have a separate team of testers or QAs, but the role defined in Scrum is "developer" only. Here I am only concentrating on programmers and testers. In reality, combinations of other roles, including designers, content writers, and business analysts, constitute the Scrum development team. This development team is formed with cross-functional developers with t-shaped skill sets.

 In Waterfall (command and control), it is a general practice to have different teams of programmers and testers. The higher the number of bugs found during testing, the more it is a sign of effective testing. The cubicles of testers are purposely kept at a distance from those of programmers. No casual discussions during features-functions implementation!

 Programmers used to send their tentative plan of providing builds to testers, and testers used to provide the test results as per their schedule. A cold war could be felt during this phase. Even simple bugs that could be fixed in a negligible amount of time lasted for a significant duration. This was a dark side of command and control!

 In Agile practices, the developers (programmers and testers) work toward development of a product/service and deliver some business value in a shorter duration, resulting in increased return on investment. Now, how does Scrum work to make that happen? On a Scrum team, developers work with one aim, and that is to deliver quality chunks during the timeboxed sprints. On the Scrum team, the tester is not the one who tests the tasks; the programmers or other development teammates also help in testing. Recently on one Scrum team I found tasks named "QA <task> by developer." The word developer was odd here, but the idea of sharing the load of testing was precise, and this is the only way of completing quality tasks in the timeboxed sprint.

 The role of testers becomes more interesting and challenging in Agile teams. Testers help other members of the development team understand the requirements and the different angles for testing the functionality/tasks. This helps other teammates broaden their testing skills. The same happens when programmers share some tidbits of programming.

 This is best achieved through pair testing. As pair programming is generally meant to mean two programmers working at one workstation, pair testing is carried out with one programmer sitting with one tester. The tester continuously tests the completed task with the programmer, and if any fixing needs to be done, it is done then. Again, there is not a rule that only a tester will be paired with a programmer during pair testing; in fact, any teammate can perform this role.

 So the next time we use the term developer, will we only have programmers in our minds?

Very soon we will go through CI (Continuous Integration), a very important aspect during sprints.

Stay tuned!