Context
Usage of an agile framework such as Scrum often conflicts with the paradigms present in organizations. It is not about applying new project management methods to do a little more of the same thing, a little better or a little faster, but about changing the mental models of the protagonists and transforming the vision of the organization of work.
These changes in mental models will concern all the protagonists. You already know that the Product Owner is not a new title for a Project Manager or a head of Business Analysts, and that the Scrum Master is also not a new title for a Project Manager.
But what about the Developer? Should he also change his mental models when he joins a Scrum team?
The "good" traditional Developer
The mission of the traditional developer, working in a siloed organization, is to code a computer program corresponding to a description that is often provided to him in a more or less detailed manner in the form of specifications or requirements.
Obviously, the level of detail of this "plan" is never the right one. Either the documentation goes into too much detail, to the point of describing a solution, or the documentation is considered too vague for the developer to know what he must produce. In both cases, the documentation will go back and forth among the actors many times to reach a consensus.
The good developer will then implement his technical expertise to produce computer code of the highest quality possible within the allotted time to best respect the plans. Since schedules are always very tight, it is obvious that the best option is for each developer to focus on the technology that he masters the most. Then he will hand over to another expert to continue the work before the product reaches the user's hands.
Finally, the very good developer will be the senior expert, the hero recognized by all who is called to unblock the technical problem and save the team from a risk of schedule drift.
A few months later, where are we? We have a pool of experts, each having deepened and locally optimized their subject of expertise, without much interest in the global vision of the future challenges of the product and the organization, as much in terms of functional as technological evolution.
Can't we change paradigm and move from a culture of control of a group of disciplined experts, like resources in an Excel table, towards the development of autonomous, innovative and creative collaborators?
In what way should the Developer within a Scrum team embody different behaviors?
The value creator
The user has a problem to solve. Not an "IT problem", but just a "problem" that we are trying to answer with a solution (often an IT solution), based on lines of code, Linux servers and lots of Data.
In the Scrum team, the Developer is a value creator and not just a solution manufacturer (exit the notion of "Digital Factory"). The Developer does Product Management WITH the Product Owner, and not FOR the Product Owner. He discovers and clarifies the problems to be solved with the users, imagines solutions with his peers then creates them and finally delivers and releases them to improve the daily lives of the users. In the IT field, creating solutions obviously involves developing lines of computer code, but it goes well beyond that since it is also necessary to develop models, business cases, architectures, experiments, algorithms, test scenarios, deployment scripts, etc.
We can clearly see that creating value involves mobilizing multiple skills, and that we need the Developer to contribute to solving problems and not just coding lines and lines in his favorite language.
The everyday apprentice
The world is complex, uncertain, and rapidly evolving. What is true and known today will soon no longer be true. New problems emerge; new technologies are developed daily.
The Developer's professionalism invites him to learn constantly. He must be responsible for his own path of progression, and not just limit himself to the rare training days that his employer is willing to pay for him. Depending on his tastes, he can participate in conferences with his peers (or watch the multiple replays available); read books and blogs; participate in OpenSource projects; hackathons…
And of course, he will be able to learn from the experts closest to him, even if he is not a "junior": his own teammates! What skills do his teammates have that he wants to develop in the coming weeks? Conversely, what talents will he be able and have to disseminate (by mentoring; tutoring, etc.) to his teammates, even if he is not "senior"?
Indeed, it is healthy that in a team, teammates tend to erase disparities in skills and knowledge to avoid hypertrophy or atrophy of power in one or the other, which unbalances and endangers the team.
The decision maker
The Developer in the Scrum team is not a meer cog in the machine, nor the supplier assigned to the Product Owner who would be his client. Decision-making is decentralized within the team.
The Scrum team as a whole is led to make many decisions on its processes, on the product, on the architecture, on security, on quality.
All members of the team must actively participate in the debates and decision-making, commit to keeping the team's decisions.
As a member of a self-managed team, the Developer must decide and participate in establishing the team's rules and standards, to establish and respect the team's work charter, all these elements being the basis of the team's decision-making. He must feel fully responsible for the choices made by his team.
In the sense of Transactional Analysis and its three states of Self (Parent; Adult; Child model), the paradigm shift consists of moving from Parent (embodied by the Manager, the Product Owner, the Scrum Master, etc.) to Child (embodied by the Developer) transactions to Adult to Adult transactions in which everyone is interdependent with the others.
The strength of collective intelligence and cognitive diversity in the self-managed team leads to making better decisions more quickly (reduce the Decision Latency).
The teammate
Finally, the Developer is above all a social human being, experiencing more or less strong feelings and emotions throughout his day, in particular during his interactions with the other members of his team and the people who are members of his ecosystem.
He is a member of a team in a complex ecosystem in which the quality and quantity of interactions are crucial for the team to be able to fulfill its mission.
In addition to his technical expertise and his humility to accept being "only" a small "me" in a larger "we" (his team), the Developer must also cultivate his talents as a teammate to communicate effectively with his different interlocutors.
Patrick Lencioni speaks here of the three virtues of the ideal team player, citing modesty, the thirst for success and social intelligence.
The Developer cannot be satisfied with being a simple expert, a cog in a well-oiled machine, but rather an active agent in a complex human ecosystem.
Conclusion
How can we support these paradigm shifts, particularly from the point of view of career management, personal development, the quest for meaning, and the recognition of expected talents and skills that are no longer the same?
These are vast subjects of concern for Scrum Masters, HRDs and Managers in all our organizations. In your contexts, how do they support these changes? How do they maintain an environment that is conducive to developing better Developers.
What if we discussed all this in this discussion or over a beer or during one of my trainings?