A good performance is a result, not a goal. People win championships because they prepared well, they were coached well. They win because they have the best facilities and environment to do so.
When a manager asks you to perform better, what does he or she really say? I think it's more like a question: "What should I do to make your performance better?" A manager, coach, facilitator, scrum master, whatever you call a manager these days is the only one responsible for your performance. A bit of talent helps ofcourse but without a facilitator that talent will never show.
A scrum master should always approach developers individually and try to make them better. The team should be more then the sum of the members, a good team can make outstanding performances, but only if they are coached right. Think of it as a football team, without a coach the best individuals will never win a world cup. But a mediocre team with a good coach can reach the finals. He will select individuals and put them on the right spots, he will train the team in what they do best. He can make the difference.
So as a scrum master you should find the talents of your developers and develop them. Develop the developers. Put the right developers together to make the team better then the sum of it's individuals. You need talented developers of all shapes and sizes. Train them like a football team and harvest the best result possible.
Wednesday, 1 October 2014
Monday, 22 September 2014
Think outside the box
Have you learned about thinking of solutions instead of problems? Does it feel right? Nope? I thought so. How can you think of solutions if you cannot think about the underlying problem. Solutions are sometimes hard to find, even when the problem is clear.
Einstein once said: "Solutions should be as simple as possible, but not simpler".
Almost all solutions are simple if you can understand the problem. But finding the right solution is a discipline itself. There are all kinds of laws, norms and standards that trouble our vision. We even learned at school to stick to the subject; problems should be solved within boundaries. Let's call that the framework of our thinking. The framework is build on what we learn; what we experience though learning and observation. Anything influencing us from outside the framework can cause stress. We are not used to dealing with that pattern. Except we are; we just don't want to acknowledge that.
This is were we should change and start thinking outside our framework. Understand the stress factors that are around us and use them. This can only be achieved via learning and perhaps a little acceptance. If we learn we change our framework, make it wider, narrower, bigger or smaller. It's a constant process we are barely aware of, but it happens all the time.
Learning new things every day, week, month or year keeps the mind young and makes it easier to find solutions to everyday problems. In software development time flies like the wind, progression is made in a very high pace. Therefore developers should try and keep up with new information. In my opinion a developer who only understands one programming language can be very good at his job, but never as good as he (or she) can get. Learning more programming languages will give insight into how certain programming problems are solved in other ways. This will break open the framework of thinking and create new possibilities for solutions on problems.
From yes-but.org:
Wherever we work and live, people experience problems. Things don’t go as expected. What’s our response? We say “Yes, but…”. Yes, but I can’t. Yes, but that’s not allowed. Yes, but how much will that cost?
And what happens then? Irritation, stagnation, decline. People who approach life in a yes-but way, think in terms of threats, difficulties and limitations. The glass is always half empty.
There is also another way of thinking: the ”Yes-and” posture. People who approach life in a yes-and way, think in terms of chances and opportunities. They not only see a glass of water, but also ask the question: “Where is the faucet?” This yes-and thinking we call “flipthinking”.
Thinking outside the box can be empowered by flipthinking. A yes-and approach on things. Look at solutions, try to look at problems from multiple directions. Is the before mentioned glass half empty, half full, is the glass just too big or perhaps it is full; with water and air. There are lots of ways looking into problems, try to find them, try to find a hypotheses why any of the problems might be right.
So in short: start learning, start looking around, think of other ways to solve a problem, do it with everything around you; not only work, start flipthinking and most of all have fun doing it!
More: yes-but.org
Einstein once said: "Solutions should be as simple as possible, but not simpler".
Almost all solutions are simple if you can understand the problem. But finding the right solution is a discipline itself. There are all kinds of laws, norms and standards that trouble our vision. We even learned at school to stick to the subject; problems should be solved within boundaries. Let's call that the framework of our thinking. The framework is build on what we learn; what we experience though learning and observation. Anything influencing us from outside the framework can cause stress. We are not used to dealing with that pattern. Except we are; we just don't want to acknowledge that.
This is were we should change and start thinking outside our framework. Understand the stress factors that are around us and use them. This can only be achieved via learning and perhaps a little acceptance. If we learn we change our framework, make it wider, narrower, bigger or smaller. It's a constant process we are barely aware of, but it happens all the time.
Learning new things every day, week, month or year keeps the mind young and makes it easier to find solutions to everyday problems. In software development time flies like the wind, progression is made in a very high pace. Therefore developers should try and keep up with new information. In my opinion a developer who only understands one programming language can be very good at his job, but never as good as he (or she) can get. Learning more programming languages will give insight into how certain programming problems are solved in other ways. This will break open the framework of thinking and create new possibilities for solutions on problems.
From yes-but.org:
Wherever we work and live, people experience problems. Things don’t go as expected. What’s our response? We say “Yes, but…”. Yes, but I can’t. Yes, but that’s not allowed. Yes, but how much will that cost?
And what happens then? Irritation, stagnation, decline. People who approach life in a yes-but way, think in terms of threats, difficulties and limitations. The glass is always half empty.
There is also another way of thinking: the ”Yes-and” posture. People who approach life in a yes-and way, think in terms of chances and opportunities. They not only see a glass of water, but also ask the question: “Where is the faucet?” This yes-and thinking we call “flipthinking”.
Thinking outside the box can be empowered by flipthinking. A yes-and approach on things. Look at solutions, try to look at problems from multiple directions. Is the before mentioned glass half empty, half full, is the glass just too big or perhaps it is full; with water and air. There are lots of ways looking into problems, try to find them, try to find a hypotheses why any of the problems might be right.
So in short: start learning, start looking around, think of other ways to solve a problem, do it with everything around you; not only work, start flipthinking and most of all have fun doing it!
More: yes-but.org
Monday, 15 September 2014
It's all in the use case
Let's talk about how developers would like to work. Developers love their job, they want challenge not per se competition, but a challenge to themselves. They are very qualified in thinking in how things should work and how it should be made.
There is one trade off. They almost never know what a customer wants. Most frustration in projects is in this part. Developers build what they think a customer wants, a customer thinks the developer speaks his language and doesn't need many words. Both wrong. When you find a developer who does know or a customer who can speak nerd language, call me! There must be telepathy or magic working there.
So, we can say that both the customer and the developer live in their own world, they speak there own language, have their own fun. And all in all, the don't understand each other, but say they do. The trick here is that both should stay in their own dimension and talk a language both can understand. One way I like very much is the way of the use case. It's not a perfect way, not a holy grail, but then again, nothing ever really is. It comes close though, both people can stay in their comfort zones and talk their own language but understand each other, because they understand use cases.
Goal
In a use case a customer defines what he wants, not how he wants it. The developer can make how he wants it. What now exactly should be in a use case then? Well one of the most important thing is a goal. This should be a short, SMART, sentence what the customer wants to achieve when the change requested is implemented by the developer. Erhm, a what? Glad you asked. SMART is a abbreviation of the following: Specific, Measurable, Achievable, Relevant and Time-bound. Which means a goal should be very clear and because it's measurable, there should be no debate whether or not the implementation of the change is correct or not. A goal should never be ambiguous. One of the features of a SMART goal is about achievable; can it be done; do we need extensive resources to pull this off, or is the goal realistic? Is the change relevant at all? Is it relevant to the project? And last but not least make it time-bound. There should be a timed element in a goal.
Actors
When we defined a goal we start in defining the actors which are needed to achieve the goal. We don't talk about the developer or certain persons, we talk more generic in the way of "a customer", "a sales employee", "a marketeer" and so on. All persons needed to achieve the goal are summed up. To be honest, in most cases there are one or two actors.
Scope
One of the items I like most. Scope sounds simple, but it can be so hard to define. Everything you don't mention in the scope is up for debate. So besides defining what is inside the scope, it's important as well to define what is outside of the scope. This defines the narrow barrier of what a customer thinks he will get to what he actually gets. Scope is mandatory to define, this is the point where are discussions are spawn from. When talking about software change there should be a definition here about what the change should imply on the system and what is should not do.
Preconditions
Preconditions or requisites are the elements or changes that should be in place before this change can commence. Think about version numbers, hardware capacity or even any other change that should be implemented before this change can be made.
Description
What should go in the description of a use case? Well start with the main success story (MSS). Define the happy flow through the application when this change is made. Did you finish the happy flow? Nice, work on a couple of failure scenario's now. When will the change fail? What message should the user get? A tester will use these scenario's to define if the change is successful and if all fail cases are hit.
To make sure a customer gets what he wants and to ascertain it is of a certain quality, do describe precisely how the application should work when the change is implemented.
This is about the smallest form of use case I use, or allow to be used. If a customer cannot define a use case in this form I will try to help him, interview him and educate him. If the customer understands the how's and why's of a use case he will never want to make incomplete stories anymore. He will find a quality change when he delivers a good use case. But bare in mind that he needs some help!
Template
Although I hate templates because people use them as they are, instead of pragmatically convert them for their own use, I believe in this case that it can help a bit.
More
http://alistair.cockburn.us/Use+case+fundamentals
There is one trade off. They almost never know what a customer wants. Most frustration in projects is in this part. Developers build what they think a customer wants, a customer thinks the developer speaks his language and doesn't need many words. Both wrong. When you find a developer who does know or a customer who can speak nerd language, call me! There must be telepathy or magic working there.
So, we can say that both the customer and the developer live in their own world, they speak there own language, have their own fun. And all in all, the don't understand each other, but say they do. The trick here is that both should stay in their own dimension and talk a language both can understand. One way I like very much is the way of the use case. It's not a perfect way, not a holy grail, but then again, nothing ever really is. It comes close though, both people can stay in their comfort zones and talk their own language but understand each other, because they understand use cases.
Goal
In a use case a customer defines what he wants, not how he wants it. The developer can make how he wants it. What now exactly should be in a use case then? Well one of the most important thing is a goal. This should be a short, SMART, sentence what the customer wants to achieve when the change requested is implemented by the developer. Erhm, a what? Glad you asked. SMART is a abbreviation of the following: Specific, Measurable, Achievable, Relevant and Time-bound. Which means a goal should be very clear and because it's measurable, there should be no debate whether or not the implementation of the change is correct or not. A goal should never be ambiguous. One of the features of a SMART goal is about achievable; can it be done; do we need extensive resources to pull this off, or is the goal realistic? Is the change relevant at all? Is it relevant to the project? And last but not least make it time-bound. There should be a timed element in a goal.
Actors
When we defined a goal we start in defining the actors which are needed to achieve the goal. We don't talk about the developer or certain persons, we talk more generic in the way of "a customer", "a sales employee", "a marketeer" and so on. All persons needed to achieve the goal are summed up. To be honest, in most cases there are one or two actors.
Scope
One of the items I like most. Scope sounds simple, but it can be so hard to define. Everything you don't mention in the scope is up for debate. So besides defining what is inside the scope, it's important as well to define what is outside of the scope. This defines the narrow barrier of what a customer thinks he will get to what he actually gets. Scope is mandatory to define, this is the point where are discussions are spawn from. When talking about software change there should be a definition here about what the change should imply on the system and what is should not do.
Preconditions
Preconditions or requisites are the elements or changes that should be in place before this change can commence. Think about version numbers, hardware capacity or even any other change that should be implemented before this change can be made.
Description
What should go in the description of a use case? Well start with the main success story (MSS). Define the happy flow through the application when this change is made. Did you finish the happy flow? Nice, work on a couple of failure scenario's now. When will the change fail? What message should the user get? A tester will use these scenario's to define if the change is successful and if all fail cases are hit.
To make sure a customer gets what he wants and to ascertain it is of a certain quality, do describe precisely how the application should work when the change is implemented.
This is about the smallest form of use case I use, or allow to be used. If a customer cannot define a use case in this form I will try to help him, interview him and educate him. If the customer understands the how's and why's of a use case he will never want to make incomplete stories anymore. He will find a quality change when he delivers a good use case. But bare in mind that he needs some help!
Template
Although I hate templates because people use them as they are, instead of pragmatically convert them for their own use, I believe in this case that it can help a bit.
- Number: each use case has a unique number, so it can always be referred to.
- Name: a use case has a name which uniquely identifies the use case.
- Goal: every use case should have a SMART goal
- Actors: define at least one actor. A system can also be an actor.
- Prerequisites: any law, rule, system that should be respected or interacted with.
- Description: the main success story and preferably a fail scenario.
- Exceptions: any exceptions on this use case
- Result: what is the remaining product when the use case is finished. Use this to measure if the use case is achieved.
- Trigger: describe the trigger, if any, that fires the use case.
More
http://alistair.cockburn.us/Use+case+fundamentals
Friday, 18 July 2014
Ambition is goal
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!
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, 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)