Thursday 15 January 2015

Nothing beats the team

Building a scrum team is hard. It's hard because the good nerds need to be found. Multi disciplinary people, programmers at first with preferable some add-ons. Each programmer should fit in the team, add value to the team. Not one person in the team should be able to do everything, the team as a whole should be able to take on the world.

Skills

What are the skills needed in a team I wonder. First of all we need someone with programming or testing skills. We need someone to be able to perform the scrum master role to guard the scrum process. We need people that communicate. We need people that feel responsible. We need people that are honest, bloody honest. People in scrum teams should be more honest to their colleges than most people are to their partner. So some skills are important to all, some skills to some. Together they form a team that delivers excellent software in time.

One of the hardest aspects for most programmers is to manage expectations of the product owner and stakeholders. The product owner needs to be informed, and also needs to inform himself, about progression of the development of the product. Any impediments should be mentioned to the product owner as soon as they are known. Of course the product owner will suffer misfortune, but less than when he is surprised at the end of a sprint by finding out the team failed to achieve their commitment. He also has a choice when the team hits a set back. Priorities can shift, work can be altered; he can have the ability to help the team reset commitment. The team can deliver a tested part of the product rather than nothing at all.

So commitment on the backlog, responsibility about the work done and communication are main skills that programmers need to have to be able to work in a scrum team.

Forming teams

Forming scrum teams can be hard. Who is doing the interviews? When will the new programmer meet the team? When you have multiple teams, who should go where? There's a simple answer: Include the members of the teams. Some managers respond to this like I'm insane, but if I talk about trust and honesty, who better to decide to open up to than the people who should work with the new programmer? They have the last word whether or not a person joins their team.

When it all goes wrong

What? Isn't scrum the holy grail all the world is talking about? Nope, it isn't. Many people oppose scrum nowadays and ask development teams to drop scrum and go back to programming. Personally I disagree to those people. We picked up scrum to avoid being interrupted all the time and to be called into meetings whole day long. We picked up scrum to get insights in our own performance, to deliver software in time. Of course we are failing sometimes, on the other hand, we are failing way less than before we adopted scrum.