Scrum

I often find myself in situations where people mistakes “programmer” with “developer” or even “developer” with “programmer.”

Before proceeding, I should clarify that my position is to define the programmer as someone who does not specialize in something else other than coding new features based on designs received. Does not help to write or understand the specifications. Does not even occur to write automated tests. Doesn´t work to keep the build up to date. Not to mention the tests. He doesn’t help the client understand their needs or solve their problems. He’s dedicated only to write code.

The current trend in software development and agile methodologies are increasingly realizing the need for multidisciplinary teams, or in other words, people who contribute in various ways to the aim pursued, rather than people who only specialize in one part of the process and do not have a complete view of the project.

Thus, all are equally responsible for achieving the successes and learn from the failures  (if any exists.) The most reasonable solution that some organizations are finding in order to meet the changing business context is to increase their flexibility. It is even logical to deduce that the engagement of specialists in certain areas alone will create many economic losts and even higher costs of communication within the team, which can impair the successful product development.

What is expected of a developer then? The developer is basically who does EVERYTHING but not at the same time (that would be an absurdity), he knows the process from beginning to end and therefore is able to detect “on time” any “misadventure” that might arise. In other words, it would be like those new digital cameras that obtain a panoramic image providing a comprehensive view of the scene photographed.

The tasks of a developer are:

• Understand the business and the objectives that are being pursued
• Collaborate with the Product Owner to identify the user stories and acceptance criteria
• Being part player at the time of assembly and maintenance of the working environment
• Ensure agile practices for software development as continuous integration, TDD, ATDD
• Participate in the design of the solution, both logical and architectural

For a better world, the responsibilities of product development must be shared among all those involved in the project, with the exception that the Product Owner does not, in most cases, have the necessary expertise about thechnical topics. Yes, I see the next question is: what about the Scrum Master? My answer is another question: How could the Scrum Master to remove impediments and ensure an adequate team work environment if he doesn’t have the technical expertise required? Quote:

“A detailed and intimate knowledge of how something works posibilidade increases that help the team leader to discover more subtle technical issues that must be addressed” (LaFasto & Larson, When teams work best, 2001, p. 133).

At bottom, though the team is the primary caretaker of product development and of course is best known its development, the Scrum Master should not ignore the aspects of development and in some cases, who should be better known if it is want to avoid communication problems, interpretation and estimation, but above all, if we are to achieve a successful goal.

Returning to the beginning: what we need are real developers who have the tools and practices needed to achieve a successful development process and a high quality product. This does not mean that there is also need for programmers, but do not confuse a developer or “developer” with a simple timer. Even a good programmer could be a bad developer and Scrum Master who has not acquired these tools during their training could possibly be perceived by the development team as lacking the necessary skills to perform their duties.

If only we can understand these fundamental differences, we will have taken another step towards a better working world.