In this article I will present my findings about team management and successful team building as I see it. In may latest job I am tasked with some managerial stuff. Decision taken to use SCRUM and of course I gave an oath, after have suffered from incompetent managers not to be one.
SCRUM is good yet another management methodology.
This is one of the major mistakes I see it happening over and over.People tend to believe that SCRUM is just a substitution for the traditional project micromanagement. Exactly then, is when teams that were robust and successful start to fail. A major problem is that in management positions people coming from old school background(Waterfall,RUP) are now in charge of managing teams in a SCRUM way. When actually what they are doing is they violate every principle Scrum has. The are most of the time scrum masters where they demand times and judge work.
In our case we don’t do micro management. I will never ask in the planning meeting to put in JIRA tasks under stories how much time a guy would believe it will take him to finish. The sole purpose of that is simple.
- Scrum is not about micromanagement but improving the capacity of the team to deliver by evolving the team members. When someone tells me why, I make a simple question. I have a car. I want to travel from Luxembourg to Amsterdam.How much gas will I need. The typical answer is I will count the distance the consumption of the car and I am done,ok maybe I will measure some intervals because in some cases I may be able to go faster… WRONG. That’s subject to the route you will select , to the driving habits of the driver, the traffic,the wind etc. So what scrum would do, if applied correctly would be. On average if I have a random sample of 10 drivers on average it takes 4 hours. Remember the purpose is not to make an accurate estimation, but effectively reach Amsterdam.The sole target of Scrum is to evolve the team members to mature,responsible and successful persons, that will make a win team.
- If you have specific time, most of the time a person, will deliver it on time without understanding in depth the complexity or the purpose of a task. He only see’s a counter ticking. This is the route of all evil also in terms what happens in the code base of a product. People simple on the sake of delivering something they violate every principle of software engineering.
Enough said about that.I think the points are clear.
Embrace the weakest link
In many case and mostly when failures occur, people will search for the responsible. I firmly believe that in scrum teams embracing the weakest link of your team is a must strategy to follow. The reasons for it I have concluded are summarised in two major issues:
1)It makes the weakest link stronger. The person becomes more responsive and also more responsible. He doesn’t feel he is the worst person in the team with the least added value. This gives him a new brew of air and boosts his efforts to be a successful team member.
2) Team building and bonding. That’s how great teams are build, and when the team guarantees to self heal it’s weakness you know you are on the right path to build a win streak team even in the difficult times of your product.
Build a nice environment
Working in a nice environment is something that has long puzzled me. Companies and managers tend to overpass this detail. But for developers and teams, working in a nice environment where they can feel relaxed and have nice small stuff that makes them feel like they are in the comfort of their hack room at home boosts their productivity. Currently in the office with have setup a space with couches and pillows where people can move from the open space, where our offices are and relax there , have a coffee and think/read something.
The moment this corner was setup,it was evident a change of mood in the team. People started, even if we remote work on Fridays, to go to the office. They felt more focus and energy to do great things. At the begging it was ackward even for me. But talking with them it was evident. The working place NEEDS to meet the requirements of the team in the scope and budget of the company. You don’t need a full Google complex(event though it would be nice to have) but try to do small wins/things for your team members. Then they will be loyal to the team.
Remember,life is to short to be spend in a cluster of cubicals