«

»

Jun 10

Being a servant developer

Some developers think being part of a Scrum team is like paradise: you can do whatever you want, and even better: the manager is there to serve you. Wrong! Okay, I was exaggerating, developers don’t think that, but still, everything in that direction: wrong!

Scrum defines the Scrum Master as being a servant leader, and it’s true: the Scrum Master (and in fact all management) should serve the team, enabling the Product Owner and the Development Team to do their job the best way they can. And what is that job? To create and deliver, at best possible productivity, a high-value product with great quality; a product that serves the business.

Ever since I first got team leading and project leading responsibilities, I have always tried to be a servant leader, at least that´s how I like to remember it. Lately I have done a lot of thinking about the times that I failed at doing so. And it has been the same reason both times: team members that let their self-interest get in the way of serving the team and serving the product. For too long I tried to serve them anyway, rather than serving the team and openly discussing their attitude.serving

The success of a Scrum-team highly depends on the willingness of its team members to do whatever it takes to meet the sprint goal. Sometimes this means getting coffee for the rest of the team, sometimes it means spending a day of testing while your main capability is programming. If you’re not willing to do that, you have no business being in a Scrum team (or in any team, in my opinion).

For a Scrum-team that is still learning to master their self-organisation, this is probably the highest hurdle to overcome: trying to change the attitude of a colleague into being a servant developer. The retrospectives are the ideal setting to openly discuss these type of issues. Although the solution will not come in one retrospective, you must talk about it in order to create awareness and start improvement. If the team doesn’t get to this level of openness itself, the Scrum Master should initiate it. And if that doesn’t work, management should enforce changes.

So it’s actually really straightforward, and I wish I had realised this earlier in my career: management serves the team members, team members serve the team, the team serves the product and the product serves the business. If this fails at any of these levels, and self-organisation doesn’t fix it within a few sprints, management still has to enforce some changes to achieve the necessary improvement … serving the business.

Permanente koppeling naar dit artikel: http://agilethings.nl/being-a-servant-developer/