When you are building a team of software developers there is one important factor. They need ambition. Ambition to grow in a role, to be the best, to be better then average. There is no such ambition as working ten years for the company. Don't hire those, they start enthusiastically and turn to an immovable object in the following years.
As a developer, when you have a job interview talk about ambition, both parties have them, there are personal ambitions and company ambitions. Throw them on the table, speak open about them. What do you want to do and how do you want to achieve your goals is more important then what you did in the past. It's the future you are hired for. Therefore hiring people shouldn't go about how many years you want to work for the company, but what the company can do for you. Of course the company needs to benefit from the effort of the developer; we are living in a capitalistic society after all. So both company and employee need to know each others ambitions and goals and need to agree upon how to achieve them both. We might even consider to use a temporarily contract when both parties know that the goals are not totally compatible and both parties can benefit from each other.
Even as employee I find it more and more strange that people want to have a permanent contract. The only benefit is that such a contract is it is needed to buy a house. From a company view an employee will surprise a company announcing his leave on the last day of the month.
Playing all the cards (be transparent) and use temporary contracts makes this go away. When the employee is done, why not help an employee in finding a new job to achieve his goals? Let him work for the company for a period and use his skills to the maximum. Let him grow, train him, benefit from him and make sure he is ready for a next job (in- or outside the company).
The main question is now, will the in- and outflow of employees rise? I don't think it will; i even think developers will be attracted by this approach. We are solving a mentality problem here: the focus on keeping a job, a world ready for mischief and lies. When we play open, there is nothing to be afraid of. If an employee sees opportunities within the company coach him and make it possible for him to stay and help the company instead of finding ways to get rid of him. When employees have problems (nine out of ten times it's all communication) help them. Make it work! They will get better because you have helped and coached them. They will love you and the company more and provide better value for money.
We need not only employees, we need happy employees. We need growing employees. We need employees with ambition!
Let's make things better!
Friday 18 July 2014
Friday 11 July 2014
Nerd herding
Nerd may sound like a negative, it was the truth for two decades ago. Now nerds rule the world and most are proud to be a nerd. Nerds form the development part of a scrum team. You should be cuttled, praised and set free in their own mind boggling space.
Cal Evans wrote a long time ago about nerd herding: "The less that your herd has to worry about management’s infatuation with the latest vendor or technology, the more they can concentrate on actually getting their job done."
The article was written in 1999 and it still is true.
1) Recruit only the best Nerds
While this is true, it's not entirely accurate. We do need only the best, but we also need a mix. The best seniors cannot work all alone, this will isolate knowledge and blocks the free flow of thinking about new things. The best solution is to hire all different kinds of people: senior, medior and junior. And hire them because of different traits. Every nerd has a speciality, an ambition. A few things they excel in. Try to make up a team with different individuals. Difference makes people talk and think and discuss, difference makes the sum of the individuals bigger then the team. They are all individuals!2) Invest in your Nerds
Nerds have more needs then only to program, they have a need for knowledge and skills. If a nerd that hasn't learned anything in the last six months he should be fired, switched or decapitated. If he is not motivated to learn only the last mentioned option remains, however that will almost never be the case.The will to learn might be a bit covered up because an organisation made the nerd numb. This happens in most organisations that see the development team as an expansion of their needs and infringe all the time in the development process. A nerd needs freedom to learn and to write code, to work on brainwaves and improve existing code. He should never be blocked by people thinking that they are more important, *cough* managers *cough*.
Give a nerd time to explore new areas of programming, give them books, send them to seminars, let then expand their nerd network.
For each nerd you should find their ambition, their goals, their wishes and help them improve. Rather hire people that have high ambition and will leave the company within five years to achieve their goals then to hire people that will stick around forever. You know the first one will deliver optimal performance, the latter will probably be less effective.
3) Teach your Nerds
Share knowledge, the hunger for improvement, skills and knowledge will not be stilled in only investing in books. Let the developers share thoughts, mix different projects, let them demo what they made to other developers.Let seniors take time to teach the juniors. The juniors have speed, the seniors quality. You need them both, let them show to each other how the speed and quality can improve.
Try to involve other disciplines as well, teach each other about other programming languages, patterns, communication, processes. Bear in mind that change should be normal, the quest for the most effective development team and development process will never end. There is no holy grail, it depends on your team and your own skills of encouragement.
4) Listen to your Nerds
Listen to your nerds, challenge their thoughts and find the team view on subjects. Even if you don't agree. Your team is in the lead, you only facilitate. So listen. To be honest, don't do stuff because you think it's the right way. Do it because your team thinks it is the right way. The only way for a scrum master to go is to do what the team tells him to do. Enforce the team. Of course it's always your head on the block, but that should never be a problem. Because the developers are always right. And good wins in the end, right?
5) Feed your Nerds/Play with your Nerds
The most important thing about a team is that they should have fun, have others in the company join the fun as well. Give them food and games, join and let others join, everybody is welcome. This will make nerds happy, and close up any distances in the company. Don't ever mix work with fun. Have a fun hour or have a session. But never combined. Although sessions are needed where the team comes together for say a retrospective; which should be fun, it is not the same as doing something the team likes. Fun should not be work related. But the work should be fun.I ask the developers from time to time if they are having fun, if they are achieving their ambition. There even have been developers that openly spoke to me about getting another job to come closer to their goals. Fun and ambition are important.
Get more pizza sessions, game events, movies and so on to build up a good team and mutual understanding in the company.
"He also got visited by some of the most powerful men in the company. Not of course the managers. They weren't that important. They were merely at the top. The people who really run organisations are usually found several levels down, where it's still possible to get things done". - Therry Pratchett: Small Gods
Tuesday 8 July 2014
It never hurts to help
When I was in college there was a cartoon on tv called "Eek the Cat". People asked him for help and he always replied: "It never hurts to help", almost killing himself in the process of helping. I love cartoons, I love Eek. And he taught me a simple lesson: "We are here to help each other".
Although we are all individuals, we work in teams. We always aim to improve ourselves and the people around us do the same. To achieve improvement we need to share. We need to share knowledge to let other people learn faster, to give them an advantage. It doesn't matter if they gain more knowledge then us, it doesn't matter if they suck up all your information. It only does matter whether they share it or not. The one not sharing isn't a team player, he is what we call a leech, vermin. We don't like vermin, they suck on our information and never repay. Not everything should always be re-payed, it isn't a balance, but a little sharing is already enough.
We benefit from each other, no grudge, no payment, all the fun. When we help people we will feel good. We also know that they learn something, which makes us feel good as well. Helping is not doing something they can't do, doing it for them. Is about what they can't do yet and doing it with them. Helping is showing direction, sharing thoughts, discuss about solutions to a problem. It's better to learn somebody how to put a bandage on, then to bandage all the kids at school on your own. When we teach we learn something about ourselves, about other persons, about opinions of other people. When we teach we open our minds and learn about other cultures and other believes.
And when we learn, we find new paths, we explore the unknown, we learn to understand other beings, other thoughts, other opinions. We see endless possibilities and we become creative. When we open up our minds we create ambition and a goal.
And then there is the collective mind of the team. Never be afraid to ask the team or anybody, when questions are impossible, your team is impossible and you should find yourself a new team asap. The collective mind of the team is the hive where all knowledge resides, not all parts of the truth are stored on one spot. It is scattered around in the individual team members. So if you are confronted with a question, do think about it, do a little research, then ask and share experience. Ask smart questions, some people say there are no dumb questions; that might be true, smart questions do exist, no doubt there. The smart way of asking is important and hard, but everybody can learn it. When you want to ask a question, do research, know what you are talking about, read manuals, websites, papers and so on. Time box yourself on the research part. A small problem should have less research time spent on then a big problem. There is no real measurement, except for the team response. If you don't do your homework the team will excuse you a couple of times at max. But if you do, you will be welcomed with open arms, you will gain kudo's.
Share knowledge, gain and get knowledge; thats how it works. Don't be a leech, people don't like leeches. Gather and share, be equals and help each other to reach your teams common goal. To be helped is important, to help even more!
Although we are all individuals, we work in teams. We always aim to improve ourselves and the people around us do the same. To achieve improvement we need to share. We need to share knowledge to let other people learn faster, to give them an advantage. It doesn't matter if they gain more knowledge then us, it doesn't matter if they suck up all your information. It only does matter whether they share it or not. The one not sharing isn't a team player, he is what we call a leech, vermin. We don't like vermin, they suck on our information and never repay. Not everything should always be re-payed, it isn't a balance, but a little sharing is already enough.
We benefit from each other, no grudge, no payment, all the fun. When we help people we will feel good. We also know that they learn something, which makes us feel good as well. Helping is not doing something they can't do, doing it for them. Is about what they can't do yet and doing it with them. Helping is showing direction, sharing thoughts, discuss about solutions to a problem. It's better to learn somebody how to put a bandage on, then to bandage all the kids at school on your own. When we teach we learn something about ourselves, about other persons, about opinions of other people. When we teach we open our minds and learn about other cultures and other believes.
And when we learn, we find new paths, we explore the unknown, we learn to understand other beings, other thoughts, other opinions. We see endless possibilities and we become creative. When we open up our minds we create ambition and a goal.
And then there is the collective mind of the team. Never be afraid to ask the team or anybody, when questions are impossible, your team is impossible and you should find yourself a new team asap. The collective mind of the team is the hive where all knowledge resides, not all parts of the truth are stored on one spot. It is scattered around in the individual team members. So if you are confronted with a question, do think about it, do a little research, then ask and share experience. Ask smart questions, some people say there are no dumb questions; that might be true, smart questions do exist, no doubt there. The smart way of asking is important and hard, but everybody can learn it. When you want to ask a question, do research, know what you are talking about, read manuals, websites, papers and so on. Time box yourself on the research part. A small problem should have less research time spent on then a big problem. There is no real measurement, except for the team response. If you don't do your homework the team will excuse you a couple of times at max. But if you do, you will be welcomed with open arms, you will gain kudo's.
Share knowledge, gain and get knowledge; thats how it works. Don't be a leech, people don't like leeches. Gather and share, be equals and help each other to reach your teams common goal. To be helped is important, to help even more!
Monday 7 July 2014
Agile manifesto
The agile manifesto, one of the best improvements in software development, made up by some of the smartest people in the planet and probably misunderstood by the rest. What is it the writers of the manifesto want to tell us? Visit the page and see for yourself.
The most important rule is not one of the four they present, it's the on above that: "We are uncovering better ways of developing software by doing it and helping others do it". That is the manifesto, the four lines presented are the guidelines to support this question. Now it looks no more like a way to work, but like a quest. It is in fact my life's quest and it should be yours too. You are a software developer, are you not? You are seeking ways to develop better software in less time with a better delivery rate then ever before? Then start making it happen!
Let's have a look at the guidelines and think about it for a moment;
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Repeat;
OK, so we value people more then processes and tools. What is scrum? Correct, a process. Then why are scrum masters always try to make the method leading over the developers? First mistake almost all people make. The people in the team and the people surrounding the team are most important. Relations, making friends, talk, have fun, achieve a common goal.
We have to get our achievements and finish our stories, a better word might be quests; a nice analogy to any mmorpg. In an mmorpg people need to work together to defeat monsters and be victorious. In a development team nothing is more precious then to be victorious. We want to deliver software, not only working software, but good working software, software of good quality. That is our goal, we are no story writers, we are the players, let the dungeon master decide our faith. We are going to defeat the boss, to finish the game, to win. We make working software. We are the programming motherfuckers that deliver working software. Nothing is mandatory, no lessons there. It should work. Point.
What do they mean with customer collaboration. Thats a good one, the customer pays us in the end. We need to make what they want, but we do it as we seem fit. We make it work. Customers have strange ideas, we help them channel their ideas, turn them, crack their minds. They do the thinking, we do the building. They specify what they need, vagueness is not allowed. We don't want to negotiate every change, we need approval, we need little building blocks. We are the masters of lego. We need to gain trust, make friends and work together.
How do software developers respond to change? Bad, I can tell you. Bad, if they are not accustomed to it. One rule we need to implement fast as a scrum master is that change is normal. No changes make the system rigid and it will freeze solid, killing any agile development method. Agile, flexible and pragmatic are the key words here. A sprint in scrum is holy. Everything around it is not. Team composition, work flow, hours, colleges, even the product owner will change during the project. Not once, count on multiple changes on that side of the project. Visions change, requirements change. Everything will change, always. So the plan is to follow changes.
In my humble opinion the main question is not even closely answered by the four rules in the manifesto. It's all about the first part of the question. The second part is evenly so important. It's about helping others. Do we have any clue who the others are? Only the developers? Ow, yes it should include developers, we need to share knowledge with our comrades. Do they mean other people as well? I do think so. We are capable of creating new things, invent new ways to do something. We should involve people in the process, make them understand and learn. We make everyone better in helping them. We help them think about their problems, we even interview them if we need information. We don't wait till they tell us what they want, because other people don't know they live in another universe. We do, we know everybody has their own universe of thought, has their own guidelines and achievements. We are the people that know. We should help others, talk to them, understand their needs, build stuff to make their lives easier. We don't need spotlights, we just want to make other people feel happy, then we are happy.
Software developers are constantly improving on helping other people with their problems, and we like it!
The most important rule is not one of the four they present, it's the on above that: "We are uncovering better ways of developing software by doing it and helping others do it". That is the manifesto, the four lines presented are the guidelines to support this question. Now it looks no more like a way to work, but like a quest. It is in fact my life's quest and it should be yours too. You are a software developer, are you not? You are seeking ways to develop better software in less time with a better delivery rate then ever before? Then start making it happen!
Let's have a look at the guidelines and think about it for a moment;
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Repeat;
OK, so we value people more then processes and tools. What is scrum? Correct, a process. Then why are scrum masters always try to make the method leading over the developers? First mistake almost all people make. The people in the team and the people surrounding the team are most important. Relations, making friends, talk, have fun, achieve a common goal.
We have to get our achievements and finish our stories, a better word might be quests; a nice analogy to any mmorpg. In an mmorpg people need to work together to defeat monsters and be victorious. In a development team nothing is more precious then to be victorious. We want to deliver software, not only working software, but good working software, software of good quality. That is our goal, we are no story writers, we are the players, let the dungeon master decide our faith. We are going to defeat the boss, to finish the game, to win. We make working software. We are the programming motherfuckers that deliver working software. Nothing is mandatory, no lessons there. It should work. Point.
What do they mean with customer collaboration. Thats a good one, the customer pays us in the end. We need to make what they want, but we do it as we seem fit. We make it work. Customers have strange ideas, we help them channel their ideas, turn them, crack their minds. They do the thinking, we do the building. They specify what they need, vagueness is not allowed. We don't want to negotiate every change, we need approval, we need little building blocks. We are the masters of lego. We need to gain trust, make friends and work together.
How do software developers respond to change? Bad, I can tell you. Bad, if they are not accustomed to it. One rule we need to implement fast as a scrum master is that change is normal. No changes make the system rigid and it will freeze solid, killing any agile development method. Agile, flexible and pragmatic are the key words here. A sprint in scrum is holy. Everything around it is not. Team composition, work flow, hours, colleges, even the product owner will change during the project. Not once, count on multiple changes on that side of the project. Visions change, requirements change. Everything will change, always. So the plan is to follow changes.
In my humble opinion the main question is not even closely answered by the four rules in the manifesto. It's all about the first part of the question. The second part is evenly so important. It's about helping others. Do we have any clue who the others are? Only the developers? Ow, yes it should include developers, we need to share knowledge with our comrades. Do they mean other people as well? I do think so. We are capable of creating new things, invent new ways to do something. We should involve people in the process, make them understand and learn. We make everyone better in helping them. We help them think about their problems, we even interview them if we need information. We don't wait till they tell us what they want, because other people don't know they live in another universe. We do, we know everybody has their own universe of thought, has their own guidelines and achievements. We are the people that know. We should help others, talk to them, understand their needs, build stuff to make their lives easier. We don't need spotlights, we just want to make other people feel happy, then we are happy.
Software developers are constantly improving on helping other people with their problems, and we like it!
Welcome to tackle scrum
This blog is about the thoughts and idea's of a scrum master who is trying to dig out the Valhalla of software development.
A lot of people think scrum is the answer, well I can tell you it's not, it's a method to accomplish great things. But, and there is the big but we always hear in the end, scrum isn't holy, some people think it is an answer to all the questions, but it is not. It's only a small part of what makes up software development. And even that small part can easily be messed up.
You are not a scrum master cause are in the position, you are not a scrum master because you did a course, you are not a scrum master because somebody told you so. Chances are, you are not a scrum master after all. Ow, yes, you completed all courses cum laude, you were the best of your class. That means you know the rules, but are you agile enough to use them?
Can you stand up and guard all the processes? Can you feel your team? Can you make the whole team better then it's individual members? Do you fire people? Do you hire people? Are you in control of the software development process? Are you making people happy? Are you delivering on time? Do you make money for the company? Do you make people understand? And one of the most important one: Do you have fun?
I will elaborate on most of the questions asked before, the main question that needs to be answered is the following:
"How should I arrange my surroundings to make the best software ever?"
I guess you didn't see that one coming. But this is the only true question. It's more then only an implementation of scrum. It's about people management, communication, agreements, respect, knowledge, negotiations and the feeling of the flow; are you with me?
A lot of people think scrum is the answer, well I can tell you it's not, it's a method to accomplish great things. But, and there is the big but we always hear in the end, scrum isn't holy, some people think it is an answer to all the questions, but it is not. It's only a small part of what makes up software development. And even that small part can easily be messed up.
You are not a scrum master cause are in the position, you are not a scrum master because you did a course, you are not a scrum master because somebody told you so. Chances are, you are not a scrum master after all. Ow, yes, you completed all courses cum laude, you were the best of your class. That means you know the rules, but are you agile enough to use them?
Can you stand up and guard all the processes? Can you feel your team? Can you make the whole team better then it's individual members? Do you fire people? Do you hire people? Are you in control of the software development process? Are you making people happy? Are you delivering on time? Do you make money for the company? Do you make people understand? And one of the most important one: Do you have fun?
I will elaborate on most of the questions asked before, the main question that needs to be answered is the following:
"How should I arrange my surroundings to make the best software ever?"
I guess you didn't see that one coming. But this is the only true question. It's more then only an implementation of scrum. It's about people management, communication, agreements, respect, knowledge, negotiations and the feeling of the flow; are you with me?
Subscribe to:
Posts (Atom)