"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.
Wednesday, October 14, 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?
Thursday, May 28, 2009
Theory and Practice
Experience by itself teaches nothing... Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence, without theory, there is no learning.
- W. Edwards Deming: The New Economics for Industry, Government, Education
Theory by itself teaches nothing. Application by itself teaches nothing. Learning is the result of dynamic interplay between the two.
- Peter Scholtes: The Leader’s Handbook: A Guide To Inspiring Your People and Managing the Daily Workflow
- W. Edwards Deming: The New Economics for Industry, Government, Education
Theory by itself teaches nothing. Application by itself teaches nothing. Learning is the result of dynamic interplay between the two.
- Peter Scholtes: The Leader’s Handbook: A Guide To Inspiring Your People and Managing the Daily Workflow
Monday, April 6, 2009
All about testing
Introduction
Here is a matrix from Brian Marick enhanced by Mary Poppendieck that has everything about testing in an agile context. It is simple and clarifies the intent of different kinds of tests which I have found valuable when communicating with QA people.
I have used the matrix for a couple of years and decided to blog about it since I like it so much. Others have blogged about this too, but I try to dig in a bit deeper.
The matrix has two axis. The first describes the goal of tests, whether it is to support programming or critique the end result like traditional QA. Some QA people find the idea of tests whose primary purpose is not testing but something else a bit odd, but that is a key point. Certain kinds of tests exist to allow a development team to go faster, not so much to find bugs.
The second axis describes the level and vocabulary of the tests. Business facing tests are understandable to business stakeholders and end users and operate at their abstraction level (think black box testing). Technology facing tests on the other hand are at a lower abstraction level and use technical jargon. They test either a small part of the system or some property of the system like performance.
Unit tests
Unit tests test the smallest possible units of code. In an (semi) object oriented language like Java that means individual functions/methods or classes. Some tests may involve a couple of classes, but those are the rare exception.
Actually my definition is a bit of a simplification. Unit tests test individual responsibilities of code and not the code itself. This is an important distinction as responsibilities are an abstraction level higher than code, but I digress.
Note that due to semantic diffusion unit testing can mean a variety of things. I know at least two organiations that use the for any kind of testing done by the development team themselves ("Has the database designer unit tested his database schema?"). Let's stick with the original meanings of terms, shall we? A unit test tests a unit of code responsibility, period.
The purpose of unit tests is to drive the design of the code through test-first development and refactoring. They act as regression test harness that allows developers to change the codebase with impunity. A secondary purpose is to document the developer's intent about what his code should do and how it should be used. Good unit tests can almost be used as API usage examples.
Unit tests are always automated and executed in batches (often called test suites). They should run quickly enough so that developers can run them every couple of minutes. Several frameworks exist for unit testing, most based on Kent Beck's SUnit framework. Ward's Wiki has a comprehensive list of xUnit frameworks.
Acceptance tests
Acceptance tests are functional system level black box regression tests. Traditionally the bread and butter of QA and testing departments, though agile suggests that acceptance tests shold be automated to free up testers from slavery to do more useful things like exploratory testing. Whether acceptance tests are written by end users like XP advocates or by someone else I don't really care.
The purpose of acceptance tests is to verify that the fully integrated, complete, up-and-running system works as expected from the end user's (man or machine) point of view. They communicate the business intent of the system, and document usage scenarios for the system. Like unit tests acceptance tests allow developers to change the system at will. And if unit tests drive the design of the code, then acceptance tests drive the design of the entire system.
Acceptance tests should be automated as far as possible. Several frameworks exist for testing different kinds of user interfaces from the browser-based Selenium for Web applications to OCR-based frameworks that use the mouse and keyboard like a user would. Often acceptance tests require much more work to set-up the state of the world before executing a test. Databases have to be cleaned and initialized, systems started up, and so on and so forth. Custom code is almost always needed even with fancy tools. It is not uncommon to see acceptance tests executed over an xUnit testing framework, but they are acceptance tests regardless of the tool used.
When it comes to functional testing acceptance tests are The Truth. They tell you if your system works as intended, your unit tests do not. If acceptance tests could be executed in seconds instead of minutes or hours, I wounder if we would bother with unit tests? Some even claim that unit testing is overrated.
Usability and exploratory tests
Usability testing is evaluating the usability of a system by inspecting users in the act of using the system. Usually done with a study where users carry out tasks under observation. Measured things can be the time to perform a task, number of errors, and such.
Usability testing is an art-form on its own, and needless to say impossible to automate. I will not go deep into it since it is not my specialty and since there is nothing special about usability testing in agile software development, except that it cannot be done test-first. :)
While lots of fancy things have been written about exploratory testing it basically is a bunch of ruthless, evil-minded testers running amok trying to intentionally break your system. It requires creativity and insight and, surprise surprise, cannot be automated. This is what testers should be doing instead of brainlessly executing manual test cases.
Property testing
Property testing investigates the emergent properties of a system. These can include performance, scalability, security or other SLAs. The goals of property testing can vary from ensuring that the system can cope with peak loads to ensuring that it cannot be hacked in certain ways.
Most property tests require tools of some sort to create load, set up the system and so on. Of all the kinds of testing property testing probably requires the most expertise and knowledge of the system being tested. Tools must always be accompanied by a thinking brain. Tests can be automated to an extent, but in performance testing for example analysing results and troubleshooting problems often takes the most time and those cannot be fully automated.
More information
Brian Marick's original blog entry, read the follow-ups too
Mary Poppendick: Competing On The Basis Of Speed, the testing segment starts at 18 minutes in the video
Here is a matrix from Brian Marick enhanced by Mary Poppendieck that has everything about testing in an agile context. It is simple and clarifies the intent of different kinds of tests which I have found valuable when communicating with QA people.
I have used the matrix for a couple of years and decided to blog about it since I like it so much. Others have blogged about this too, but I try to dig in a bit deeper.
The matrix has two axis. The first describes the goal of tests, whether it is to support programming or critique the end result like traditional QA. Some QA people find the idea of tests whose primary purpose is not testing but something else a bit odd, but that is a key point. Certain kinds of tests exist to allow a development team to go faster, not so much to find bugs.
The second axis describes the level and vocabulary of the tests. Business facing tests are understandable to business stakeholders and end users and operate at their abstraction level (think black box testing). Technology facing tests on the other hand are at a lower abstraction level and use technical jargon. They test either a small part of the system or some property of the system like performance.
Unit tests
Unit tests test the smallest possible units of code. In an (semi) object oriented language like Java that means individual functions/methods or classes. Some tests may involve a couple of classes, but those are the rare exception.
Actually my definition is a bit of a simplification. Unit tests test individual responsibilities of code and not the code itself. This is an important distinction as responsibilities are an abstraction level higher than code, but I digress.
Note that due to semantic diffusion unit testing can mean a variety of things. I know at least two organiations that use the for any kind of testing done by the development team themselves ("Has the database designer unit tested his database schema?"). Let's stick with the original meanings of terms, shall we? A unit test tests a unit of code responsibility, period.
The purpose of unit tests is to drive the design of the code through test-first development and refactoring. They act as regression test harness that allows developers to change the codebase with impunity. A secondary purpose is to document the developer's intent about what his code should do and how it should be used. Good unit tests can almost be used as API usage examples.
Unit tests are always automated and executed in batches (often called test suites). They should run quickly enough so that developers can run them every couple of minutes. Several frameworks exist for unit testing, most based on Kent Beck's SUnit framework. Ward's Wiki has a comprehensive list of xUnit frameworks.
Acceptance tests
Acceptance tests are functional system level black box regression tests. Traditionally the bread and butter of QA and testing departments, though agile suggests that acceptance tests shold be automated to free up testers from slavery to do more useful things like exploratory testing. Whether acceptance tests are written by end users like XP advocates or by someone else I don't really care.
The purpose of acceptance tests is to verify that the fully integrated, complete, up-and-running system works as expected from the end user's (man or machine) point of view. They communicate the business intent of the system, and document usage scenarios for the system. Like unit tests acceptance tests allow developers to change the system at will. And if unit tests drive the design of the code, then acceptance tests drive the design of the entire system.
Acceptance tests should be automated as far as possible. Several frameworks exist for testing different kinds of user interfaces from the browser-based Selenium for Web applications to OCR-based frameworks that use the mouse and keyboard like a user would. Often acceptance tests require much more work to set-up the state of the world before executing a test. Databases have to be cleaned and initialized, systems started up, and so on and so forth. Custom code is almost always needed even with fancy tools. It is not uncommon to see acceptance tests executed over an xUnit testing framework, but they are acceptance tests regardless of the tool used.
When it comes to functional testing acceptance tests are The Truth. They tell you if your system works as intended, your unit tests do not. If acceptance tests could be executed in seconds instead of minutes or hours, I wounder if we would bother with unit tests? Some even claim that unit testing is overrated.
Usability and exploratory tests
Usability testing is evaluating the usability of a system by inspecting users in the act of using the system. Usually done with a study where users carry out tasks under observation. Measured things can be the time to perform a task, number of errors, and such.
Usability testing is an art-form on its own, and needless to say impossible to automate. I will not go deep into it since it is not my specialty and since there is nothing special about usability testing in agile software development, except that it cannot be done test-first. :)
While lots of fancy things have been written about exploratory testing it basically is a bunch of ruthless, evil-minded testers running amok trying to intentionally break your system. It requires creativity and insight and, surprise surprise, cannot be automated. This is what testers should be doing instead of brainlessly executing manual test cases.
Property testing
Property testing investigates the emergent properties of a system. These can include performance, scalability, security or other SLAs. The goals of property testing can vary from ensuring that the system can cope with peak loads to ensuring that it cannot be hacked in certain ways.
Most property tests require tools of some sort to create load, set up the system and so on. Of all the kinds of testing property testing probably requires the most expertise and knowledge of the system being tested. Tools must always be accompanied by a thinking brain. Tests can be automated to an extent, but in performance testing for example analysing results and troubleshooting problems often takes the most time and those cannot be fully automated.
More information
Brian Marick's original blog entry, read the follow-ups too
Mary Poppendick: Competing On The Basis Of Speed, the testing segment starts at 18 minutes in the video
Subscribe to:
Posts (Atom)