I gave a thirty-minute talk about testing in agile projects in December's Agile Dinner in Helsinki. Here are the slides.
It was nice to have so many participants from TestausOSY visiting our dinner! Too bad not many stayed for the beers (read: actual conversation) afterwards.
Wednesday, December 2, 2009
Tuesday, November 10, 2009
Dr. Deming's Management's Five Deadly Diseases
Here is an Encyclopaedia Britannica Film from 1984 featuring Dr. Deming himself: Management's Five Deadly Diseases. Awesome.
Tuesday, October 27, 2009
Open Space Session: Think!
Intro & thinking principles
This blog entry is about the open space session with similar title I held at Scan-Agile 2009. It took me a while to write since I have never actually organized my thoughts on this. My intention was not to host a session but after hearing fifteen sessions announced about tools and methods I felt compelled to since a very important ingredient was missing: thinking and the principles that guide thinking.
Photo courtesy my fellow conference organizer Ari Tikka.
I will start this blog like I started my open space session: let me share with you the three principles of the most productive Scrum team I have ever been in. These principles guided our everyday life from choosing technologies to improving our ways of working. Agile architecture absolutely requires them. But even though these principles have arisen from agile software development, they are valid for most aspects of life. I exercise them daily in my personal life.
The thinking principles are:
1) Do only what is needed
2) First the problem, then the solution
3) Challenge everything
This blog entry is about the open space session with similar title I held at Scan-Agile 2009. It took me a while to write since I have never actually organized my thoughts on this. My intention was not to host a session but after hearing fifteen sessions announced about tools and methods I felt compelled to since a very important ingredient was missing: thinking and the principles that guide thinking.
Photo courtesy my fellow conference organizer Ari Tikka.
I will start this blog like I started my open space session: let me share with you the three principles of the most productive Scrum team I have ever been in. These principles guided our everyday life from choosing technologies to improving our ways of working. Agile architecture absolutely requires them. But even though these principles have arisen from agile software development, they are valid for most aspects of life. I exercise them daily in my personal life.
The thinking principles are:
1) Do only what is needed
2) First the problem, then the solution
3) Challenge everything
Wednesday, October 14, 2009
Leadership and self-organization
"The only truly self-organizing team I know of was Apollo 13 after the pop."
(Thanks for that one, Mom!)
Teams do not spontaneously materialize out of thin air, and just by accident happen to pick a goal that by coincidence is in line with the surrounding organization's objectives. Teams need to be formed, and they need to be given a purpose. Sometimes that is done by a memeber of the team and sometimes by an external party.
I call the process of forming a team and giving it purpose leadership.
Leadership is not only vital to self-organization it is usually a pre-requisite for it. Without leadership there is no team, and without a team there is no self-organization. Apollo 13 teams who are driven by a single, overwhelming imperative pushing them to self-organize are rare in the modern corporate world.
Besides team-forming and goal-setting leadership can serve other purposes in teamwork. These can be guiding the team's daily work, keeping the team on the right course, removing team dysfunctions and in general all activities that help the team. Whether this kind of leadership is needed or not, and wheter it should be internal or external to theam depends entirely on circumstance. What is important that leadership can serve a purpose and is probably needed in one form or another during the life-span of a team.
The idea that leadership is not necessary because teams self-organize is wishful thinking at best.
It will be interesting to hear what Mary Poppendieck has to say about this subject in her keynote tomorrow at Scandinavian Agile Conference 2009.
(Thanks for that one, Mom!)
Teams do not spontaneously materialize out of thin air, and just by accident happen to pick a goal that by coincidence is in line with the surrounding organization's objectives. Teams need to be formed, and they need to be given a purpose. Sometimes that is done by a memeber of the team and sometimes by an external party.
I call the process of forming a team and giving it purpose leadership.
Leadership is not only vital to self-organization it is usually a pre-requisite for it. Without leadership there is no team, and without a team there is no self-organization. Apollo 13 teams who are driven by a single, overwhelming imperative pushing them to self-organize are rare in the modern corporate world.
Besides team-forming and goal-setting leadership can serve other purposes in teamwork. These can be guiding the team's daily work, keeping the team on the right course, removing team dysfunctions and in general all activities that help the team. Whether this kind of leadership is needed or not, and wheter it should be internal or external to theam depends entirely on circumstance. What is important that leadership can serve a purpose and is probably needed in one form or another during the life-span of a team.
The idea that leadership is not necessary because teams self-organize is wishful thinking at best.
It will be interesting to hear what Mary Poppendieck has to say about this subject in her keynote tomorrow at Scandinavian Agile Conference 2009.
Friday, September 11, 2009
The essence of leadership
I have been thinking about leadership - especially the effects of it's absence - for along while know. After exchanging a few messages with Ola Ellnestam on Twitter about it last week, I have finally decided to write down my thoughts.
Leadership is a difficult concept to define. The word is overloaded, subject to interpretation and Wikipedia alone lists over ten theories to explain it:
Types of leadership and other theories: Agentic Leadership, Coaching, Communal Leadership, Max Weber's Charismatic authority, Antonio Gramsci's theory of Cultural hegemony, Ethical leadership, Islamic leadership, Ideal leadership, Leader-Member Exchange Theory (LMX), Leadership Character Model, Leadership development, Servant leadership, Toxic Leadership, Youth leadership, Collaborative leadership, Outstanding leadership theory
Mind boggling. Surely it cannot be such a difficult concept?
What makes things more interesting is the emotional and cultural load associated with leadership. For some the word conjures up images of charismatic leaders like Patton or Winston Churchill, for others the images are of micro-managers for hell, breathing down their necks constantly.
The Finnish culture has a special antipathy towards the concept, causing people to grumble when you even mention leadership in a corporate context. For that I blame Lieutenant Lammio, the pompous, by-the-book spit and polish caricature of a career officer from the Finnish national epoch The Unknown Soldier.
I am not really interested in getting entangled in all that, rather I want to dig in to the problem that leadership solves - the reason for its existence. My interest? I believe lack of leadership is the greatest problem in the industry, and the root cause of most failures companies have. (Especially so in agile methods with their emphasis on self-organization, but I'll get to that later.)
Note that I only talk about leadership and will consciously avoid entering the "management vs. leadership" territory. Nor do I want to speculate whose primary job it is to lead in a modern organization. I merely want to point out that leadership is absolutely necessary, much neglected, and much simpler than you think. So without further ado...
The purpose of leadership is to get a bunch of people to accomplish something together.
The essence of leadership consists of three parts:
1) Organizing doers
2) Deciding objective(s), communicating to doers
3) Helping doers succeed in achieving objective
Miss one of the previous, and all the theories on motivation, fancy pep-talks by management, team building events, company parties by HR and the rest of the fluffy stuff associated with "leadership" become completely irrelevant. No amount of motivation will work on a group that has lost it's purpose of existence!
My list works at any level, by the way. Whether leading an individual, a team, department or a division. If the goal is to get something done with a bunch of individuals, all three things need to happen. The bunch must be formed, an objective chosen and - usually - the bunch need to be supported on their pursuit of the objective. Miss one of the three and likely nothing will ever get done. Simple?
Why is it, then, that so many organizations spend energy on schemes to motivate their employees while one or more of the three parts is missing? I don't know, but my bet is because they have lost the reason for their existence, and are trying to keep themselves busy earning money without no greater purpose. It is very difficult to set goals locally for a group if there is no overall strategy nor greater goals to serve.
Here is another point I want to drive home:
If a team, group or any organizational unit has lost its goal or the reason for its existence, it is not being lead. Simple as that.
Did I mention that leadership is vital for happiness and contentment? I will get to that later.
Leadership is a difficult concept to define. The word is overloaded, subject to interpretation and Wikipedia alone lists over ten theories to explain it:
Types of leadership and other theories: Agentic Leadership, Coaching, Communal Leadership, Max Weber's Charismatic authority, Antonio Gramsci's theory of Cultural hegemony, Ethical leadership, Islamic leadership, Ideal leadership, Leader-Member Exchange Theory (LMX), Leadership Character Model, Leadership development, Servant leadership, Toxic Leadership, Youth leadership, Collaborative leadership, Outstanding leadership theory
Mind boggling. Surely it cannot be such a difficult concept?
What makes things more interesting is the emotional and cultural load associated with leadership. For some the word conjures up images of charismatic leaders like Patton or Winston Churchill, for others the images are of micro-managers for hell, breathing down their necks constantly.
The Finnish culture has a special antipathy towards the concept, causing people to grumble when you even mention leadership in a corporate context. For that I blame Lieutenant Lammio, the pompous, by-the-book spit and polish caricature of a career officer from the Finnish national epoch The Unknown Soldier.
I am not really interested in getting entangled in all that, rather I want to dig in to the problem that leadership solves - the reason for its existence. My interest? I believe lack of leadership is the greatest problem in the industry, and the root cause of most failures companies have. (Especially so in agile methods with their emphasis on self-organization, but I'll get to that later.)
Note that I only talk about leadership and will consciously avoid entering the "management vs. leadership" territory. Nor do I want to speculate whose primary job it is to lead in a modern organization. I merely want to point out that leadership is absolutely necessary, much neglected, and much simpler than you think. So without further ado...
The purpose of leadership is to get a bunch of people to accomplish something together.
The essence of leadership consists of three parts:
1) Organizing doers
2) Deciding objective(s), communicating to doers
3) Helping doers succeed in achieving objective
Miss one of the previous, and all the theories on motivation, fancy pep-talks by management, team building events, company parties by HR and the rest of the fluffy stuff associated with "leadership" become completely irrelevant. No amount of motivation will work on a group that has lost it's purpose of existence!
My list works at any level, by the way. Whether leading an individual, a team, department or a division. If the goal is to get something done with a bunch of individuals, all three things need to happen. The bunch must be formed, an objective chosen and - usually - the bunch need to be supported on their pursuit of the objective. Miss one of the three and likely nothing will ever get done. Simple?
Why is it, then, that so many organizations spend energy on schemes to motivate their employees while one or more of the three parts is missing? I don't know, but my bet is because they have lost the reason for their existence, and are trying to keep themselves busy earning money without no greater purpose. It is very difficult to set goals locally for a group if there is no overall strategy nor greater goals to serve.
Here is another point I want to drive home:
If a team, group or any organizational unit has lost its goal or the reason for its existence, it is not being lead. Simple as that.
Did I mention that leadership is vital for happiness and contentment? I will get to that later.
Monday, August 24, 2009
Blog reboot
The last few months I have been busy either enjoying the sunshine or thinking about my goals in life, and trying to decide where to take my career. I haven't had time to focus on writing my blog and time has come to remedy that.
This blog initially had two purposes. It was a notebook for things I found interesting and a way to make me a smartass who supposedly knows something about agile.
The problem in writing good blog entries is the time required for making a balanced argument. If you don't take that time, you end up writing flamebait or simply repeating what others have said. Where's the fun in that?
So what's next? I will start organizing my thoughts and start writing about the things that I really find interesting, the stuff that keeps me motivated and awake at nights. Some of those things include agile, lean, software architecture, leadership, and what makes people happy.
I need a new name for this blog, though, since it won't really be about agile anymore. Suggestions?
This blog initially had two purposes. It was a notebook for things I found interesting and a way to make me a smartass who supposedly knows something about agile.
The problem in writing good blog entries is the time required for making a balanced argument. If you don't take that time, you end up writing flamebait or simply repeating what others have said. Where's the fun in that?
So what's next? I will start organizing my thoughts and start writing about the things that I really find interesting, the stuff that keeps me motivated and awake at nights. Some of those things include agile, lean, software architecture, leadership, and what makes people happy.
I need a new name for this blog, though, since it won't really be about agile anymore. Suggestions?
Monday, June 8, 2009
Specialization and generalization
This blog was inspired by Vasco Duarte's blog Why specialization in Software development is bad for business.
I maintain that specialization is crucial for software development, and that overgeneralization can be just as harmful as overspecialization. The following figure will illustrate my point.
At the top of the figure is a team of three with each having a specialty skill. Each team member happily sits in their own comfort zone and there is very little understanding of adjacent specialities. Since finishing an item of work needs all three specializations there will be handoffs and theory of constraints applies. Even if the team is working on more than one item time is wasted on waiting for bottleneck resources and so on. The good news is that since there is a lot of expertise in the team the finished product will reflect that expertise (if it ever gets finished).
Now let's look at the other extreme at the bottom of the figure. A team with nothing but generalists will work most efficiently since everyone is able to do everyone else's job. Very little time is wasted since there are no handoffs and everyone is able to support each other. The caveat is that since everyone is a generalist the team lacks mastery in any field, and thefore can build mediocre products at best. Jack of all trades, master of none applies.
In summary pure specialists produce excellent products late and pure generalists sub-standard products on-time.
How about the middle road then, the "generalizing specialists"? The guys who are specialists in their field, but know enough of their surroundings to be able to work effectively with other specialists. Perhaps they have the social and teamworking skills to also pick up new skills and broaden their specialty. Such a team should be able to work efficiently and still utilize the expertise of individuals to build good products.
A mixture of specialization and generalization is needed, though I will grant that overspecialization may be a bigger problem in the industry.
By the way, how does generalization work in a truly cross-functional team that includes other disciplines besides software development? Is it feasible to train graphic designers software design, and vice-versa? What about marketing and sales? In the long run it probably is beneficial to send all developers on a marketing crash-course but in a project environment I wonder if it is feasible?
I maintain that specialization is crucial for software development, and that overgeneralization can be just as harmful as overspecialization. The following figure will illustrate my point.
At the top of the figure is a team of three with each having a specialty skill. Each team member happily sits in their own comfort zone and there is very little understanding of adjacent specialities. Since finishing an item of work needs all three specializations there will be handoffs and theory of constraints applies. Even if the team is working on more than one item time is wasted on waiting for bottleneck resources and so on. The good news is that since there is a lot of expertise in the team the finished product will reflect that expertise (if it ever gets finished).
Now let's look at the other extreme at the bottom of the figure. A team with nothing but generalists will work most efficiently since everyone is able to do everyone else's job. Very little time is wasted since there are no handoffs and everyone is able to support each other. The caveat is that since everyone is a generalist the team lacks mastery in any field, and thefore can build mediocre products at best. Jack of all trades, master of none applies.
In summary pure specialists produce excellent products late and pure generalists sub-standard products on-time.
How about the middle road then, the "generalizing specialists"? The guys who are specialists in their field, but know enough of their surroundings to be able to work effectively with other specialists. Perhaps they have the social and teamworking skills to also pick up new skills and broaden their specialty. Such a team should be able to work efficiently and still utilize the expertise of individuals to build good products.
A mixture of specialization and generalization is needed, though I will grant that overspecialization may be a bigger problem in the industry.
By the way, how does generalization work in a truly cross-functional team that includes other disciplines besides software development? Is it feasible to train graphic designers software design, and vice-versa? What about marketing and sales? In the long run it probably is beneficial to send all developers on a marketing crash-course but in a project environment I wonder if it is feasible?
Subscribe to:
Posts (Atom)