Friday, November 28, 2008
Agile Job Trends
The graph at indeed.com tells a lot on the reasons why there is so much debate within the agile community...
Thursday, November 27, 2008
The dark side of self-organizing teams
Agile methodologies focus on the notion of self-organizing teams, as a key to software development success. This works for a lot of reasons: talent is not constrained to follow a pre-defined process, the process is adaptive and tailored on the individuals and so on.
But it looks so beautiful and simple in books, and so hard to achieve in reality. One reason is that there are two main patterns for self-organizing team creation:
Creating a new group involves discovering common passion, is just like starting playing baseball in a small town. Maybe 2 kids are just playing with a ball and a bat. Another one joins the two, same day same hour, then later on, they discover they’re enough to form a real team. There can be some key moments in the growing phase, but many times, the original vision is shared by the majority of the team.
What is really hard, is trying to transform a team who’s always been directed from above, into a self-organizing team. There are so many things that can get in the way, that is often better to start with a newly formed group instead of turning an existing team into a self organizing one.
...not necessarily good
But the notion of self organizing team is not necessarily good in itself. Self organizing teams can be pretty nasty, (Mafia, Al-Quaeda, Ku-Klux-Klan are all examples of self organizing teams, as this interesting post says). But the question is not only tied to team ethics, it’s also related to what the team can do to achieve its goals, which involves powers and responsibilities.
If you follow soccer a bit you’ll probably know the story of Antonio Cassano. One of the most talented Italian players, he played in AS Roma for a while. After some initial success, its role (not his skills) started being questioned. AS Roma sold Cassano to Real Madrid and right after that started an impressive record of 11 victories in a row. After the embarrassing parenthesis in Spain, now Cassano is doing fine again with Sampdoria. This is a clear example of how a team can improve as a team by getting rid of some talent.
Talent is hard to manage (and this could be the subject of a dedicated post), but the key point here is that the team might decide to drop team members that don’t share the same values with the rest of the team. You need to grant this right to the team, otherwise shared vision and behavior will never emerge, but you’ll also need to be prepared to the consequences, as a manager or as a team member. And consequences can be pretty nasty: like telling a colleague that he/she is not welcome (maybe with some “unless...”).
One key point is to be sure that the most influential team members have a positive influence on the team. If you can’t guarantee that, you’re probably doomed, right from the start.
But it looks so beautiful and simple in books, and so hard to achieve in reality. One reason is that there are two main patterns for self-organizing team creation:
- being already on one
- spontaneously creating one
Creating a new group involves discovering common passion, is just like starting playing baseball in a small town. Maybe 2 kids are just playing with a ball and a bat. Another one joins the two, same day same hour, then later on, they discover they’re enough to form a real team. There can be some key moments in the growing phase, but many times, the original vision is shared by the majority of the team.
What is really hard, is trying to transform a team who’s always been directed from above, into a self-organizing team. There are so many things that can get in the way, that is often better to start with a newly formed group instead of turning an existing team into a self organizing one.
...not necessarily good
But the notion of self organizing team is not necessarily good in itself. Self organizing teams can be pretty nasty, (Mafia, Al-Quaeda, Ku-Klux-Klan are all examples of self organizing teams, as this interesting post says). But the question is not only tied to team ethics, it’s also related to what the team can do to achieve its goals, which involves powers and responsibilities.
If you follow soccer a bit you’ll probably know the story of Antonio Cassano. One of the most talented Italian players, he played in AS Roma for a while. After some initial success, its role (not his skills) started being questioned. AS Roma sold Cassano to Real Madrid and right after that started an impressive record of 11 victories in a row. After the embarrassing parenthesis in Spain, now Cassano is doing fine again with Sampdoria. This is a clear example of how a team can improve as a team by getting rid of some talent.
Talent is hard to manage (and this could be the subject of a dedicated post), but the key point here is that the team might decide to drop team members that don’t share the same values with the rest of the team. You need to grant this right to the team, otherwise shared vision and behavior will never emerge, but you’ll also need to be prepared to the consequences, as a manager or as a team member. And consequences can be pretty nasty: like telling a colleague that he/she is not welcome (maybe with some “unless...”).
One key point is to be sure that the most influential team members have a positive influence on the team. If you can’t guarantee that, you’re probably doomed, right from the start.
Wednesday, November 26, 2008
So ...where’s the fun part?
I have the feeling of having killed somebody’s dream in my last post. And also of walking on the edge of being misinterpreted. I think I’ve got to blog about it again from a different angle.
I like developing software. I think it’s fun. Even if I like solving complicated puzzles, I think the best part of software development comes from working within a team. I have some friends working for the Toro Rosso F1 Team (being from the same town makes it easy), and I know how everybody felt after winning in Monza. This is the kind of feeling a team should work for. Not every team could be so lucky, but ...you got the point.
Are we just executors?
So, are we just implementing a specification? Nope. If that was the job, pick some MDA tool and have it do the job for you. I just asserted that coding is a lot less creative than many developers think. Finding a proven solution (hopefully a good one) is often a preferable alternative to an original one. And “original solutions” often degenerate in in-house frameworks lock-in.
But being mere executors just doesn’t work either. Following specifications is a waterfall, but it’s also a waste of talent. And such a scenario will eventually lead to low motivation, and talent loss within your company.
Creativity might slip in when the puzzle is more complex than usual, or when tempting something new. In this cases, you have to fight with the creativity tools: get away from the workstation, have a (time-boxed) brainstorming session, involving somebody else, be provocative, avoid censorship. The key is to recognize which type of problem you’re facing and to use the right tool for the job.
Learn and challenge
Another area of software development where you definitely need some creativity is interaction with users and stakeholders. Understanding the problem domain is an interesting activity, which will lead you in unexplored areas of knowledge. Understanding the way users are interacting with your application, and the reasons for that, might lead you to propose some features that might come in handy, or make the difference!
Software development teams are often a concentration of pretty smart minds. Pretending that the only focus is code, is wasting talent and, often, a mess.
I like developing software. I think it’s fun. Even if I like solving complicated puzzles, I think the best part of software development comes from working within a team. I have some friends working for the Toro Rosso F1 Team (being from the same town makes it easy), and I know how everybody felt after winning in Monza. This is the kind of feeling a team should work for. Not every team could be so lucky, but ...you got the point.
Are we just executors?
So, are we just implementing a specification? Nope. If that was the job, pick some MDA tool and have it do the job for you. I just asserted that coding is a lot less creative than many developers think. Finding a proven solution (hopefully a good one) is often a preferable alternative to an original one. And “original solutions” often degenerate in in-house frameworks lock-in.
But being mere executors just doesn’t work either. Following specifications is a waterfall, but it’s also a waste of talent. And such a scenario will eventually lead to low motivation, and talent loss within your company.
Creativity might slip in when the puzzle is more complex than usual, or when tempting something new. In this cases, you have to fight with the creativity tools: get away from the workstation, have a (time-boxed) brainstorming session, involving somebody else, be provocative, avoid censorship. The key is to recognize which type of problem you’re facing and to use the right tool for the job.
Learn and challenge
Another area of software development where you definitely need some creativity is interaction with users and stakeholders. Understanding the problem domain is an interesting activity, which will lead you in unexplored areas of knowledge. Understanding the way users are interacting with your application, and the reasons for that, might lead you to propose some features that might come in handy, or make the difference!
Software development teams are often a concentration of pretty smart minds. Pretending that the only focus is code, is wasting talent and, often, a mess.
Tuesday, November 25, 2008
The alibi of creativity
One of the most intriguing parts of the discussion, that was part of my speech in IAD2008, was a question (interestingly asked by one of the few non-developers) regarding possible negative effects of time-boxing (especially in the form of “pomodoro”) on a creative activity such as developing software.
I quickly dropped my opinion, but I was more interested in making others opinion on the topic emerge. Then I had some tome to think better about it: here are my thoughts.
Coding is not a creative activity
I mean ...there’s creativity involved, but most of the time we are solving problems, in ways which are probably been explored by many others before us. So, basically, coding is a problem solving activity. Creativity slips in when the problem to solve is new, non conventional or pretty hard, or does not strictly involve coding (in this respect, the process might be far more creative than coding). Sometimes we have the luck to deal with applications which are pioneering, but many more times, this is not the case.
This doesn’t mean that we have to be mere follower’s of somebody’s else ideas. But “being creative” or pretending to be, too often has the undesirable side effect of “reinventing the wheel” which is definitely not what we want. Put in another way, “being creative” is often just an excuse for being “too lazy to study”.
Time-boxing does not constrain creativity
Ok, then there are times where the strict time constraints imposed by time-boxed activity, a pairing session, a pomodoro, a day or a sprint, is not enough to allow for the “inspired” solution. As Simone Genini pointed out, “as a manager, you don’t want to wait for developer’s inspiration”. So what you need is a repeatable attitude for this problem solving activity.
Back home I realized that this happens in creative fields too: comics are written on a monthly basis (even if not every author can fit in the schedule), ad campaigns are creative, but organized as time-boxed projects, and so on.
Even in software development, the time-box constraint is less stringent than it might be: if one of your best developers came out with what he consider a sub-optimal solution, something he doesn’t really like. You can be sure that he’ll keep thinking about it, and probably will attack the problem again, once a better solution appeared to him in his dreams or under the shower. Just allowing more coding time to be explicitly allocated to that task won’t probably get the solution any closer.
I quickly dropped my opinion, but I was more interested in making others opinion on the topic emerge. Then I had some tome to think better about it: here are my thoughts.
Coding is not a creative activity
I mean ...there’s creativity involved, but most of the time we are solving problems, in ways which are probably been explored by many others before us. So, basically, coding is a problem solving activity. Creativity slips in when the problem to solve is new, non conventional or pretty hard, or does not strictly involve coding (in this respect, the process might be far more creative than coding). Sometimes we have the luck to deal with applications which are pioneering, but many more times, this is not the case.
This doesn’t mean that we have to be mere follower’s of somebody’s else ideas. But “being creative” or pretending to be, too often has the undesirable side effect of “reinventing the wheel” which is definitely not what we want. Put in another way, “being creative” is often just an excuse for being “too lazy to study”.
Time-boxing does not constrain creativity
Ok, then there are times where the strict time constraints imposed by time-boxed activity, a pairing session, a pomodoro, a day or a sprint, is not enough to allow for the “inspired” solution. As Simone Genini pointed out, “as a manager, you don’t want to wait for developer’s inspiration”. So what you need is a repeatable attitude for this problem solving activity.
Back home I realized that this happens in creative fields too: comics are written on a monthly basis (even if not every author can fit in the schedule), ad campaigns are creative, but organized as time-boxed projects, and so on.
Even in software development, the time-box constraint is less stringent than it might be: if one of your best developers came out with what he consider a sub-optimal solution, something he doesn’t really like. You can be sure that he’ll keep thinking about it, and probably will attack the problem again, once a better solution appeared to him in his dreams or under the shower. Just allowing more coding time to be explicitly allocated to that task won’t probably get the solution any closer.
Monday, November 24, 2008
Back from the Italian Agile Day 2008
It’s been a nice and hard day. I had two presentations to lead, and I wasn’t in great shape. But I think the overall result was not that bad. I just finished uploading the slides on slideshare (but they’ll be available also on the Italian Agile community web site). Here are the links.
Agile: il Piano B
Agile vs SOA deathmatch
Anyway, many ideas emerged on the related discussions... I guess I’ll blog about them for a while.
Agile: il Piano B
Agile vs SOA deathmatch
Anyway, many ideas emerged on the related discussions... I guess I’ll blog about them for a while.
Wednesday, November 19, 2008
Getting Domain Driven
Last weeks have been especially busy, so I wasn’t able to post that much. This doesn’t mean that nothing happened to me in the meanwhile...
In September I attended to Craig Larman’s Agile Project Management training, which I am supposed to take over in 2009, together with Allan Kelly, for Skills Matter.
Wasn’t it enough, in October I certified for Eric Evans’ Domain Driven Design class, which I just co-taught last week, together with Gojko Adzic, and Eric Evans himself. As the previous experience (where I acted as an active student), this one was also really pleasant and interesting at the same time. All of the people attending where somewhat special, and questions were really interesting and let us get quite a bit of their unique perspective too. When classes are that interesting it’s hard to say who learned most, but going home satisfied after a hard work, (and a couple of beers) is definitely rewarding.
Also, we started collaborating on the training material and structure, together with Hans Dockter, who'll be joining us as a trainer in 2009, in a very open and collaborative way. It's great to be part of such a team!
At the same time I started beating the drum of DDD also in Italy with my first article on the subject, which has been published by Mokabyte some days ago. Since DDD is one of the IT related topics that I found most interesting over these years, I am pretty excited about the whole matter. By the way, writing about DDD is also extremely challenging. Eric carefully weighted every single word in hs book, which is actually a careful distillation of DDD principles. My writing style is basically the opposite: I write a lot, I digress, I make a lot of (hopefully) funny examples just to make a small point. Maybe I'll be able to deliver the message, maybe not.
I am eager for feedback anyway ;-)
In September I attended to Craig Larman’s Agile Project Management training, which I am supposed to take over in 2009, together with Allan Kelly, for Skills Matter.
Wasn’t it enough, in October I certified for Eric Evans’ Domain Driven Design class, which I just co-taught last week, together with Gojko Adzic, and Eric Evans himself. As the previous experience (where I acted as an active student), this one was also really pleasant and interesting at the same time. All of the people attending where somewhat special, and questions were really interesting and let us get quite a bit of their unique perspective too. When classes are that interesting it’s hard to say who learned most, but going home satisfied after a hard work, (and a couple of beers) is definitely rewarding.
Also, we started collaborating on the training material and structure, together with Hans Dockter, who'll be joining us as a trainer in 2009, in a very open and collaborative way. It's great to be part of such a team!
At the same time I started beating the drum of DDD also in Italy with my first article on the subject, which has been published by Mokabyte some days ago. Since DDD is one of the IT related topics that I found most interesting over these years, I am pretty excited about the whole matter. By the way, writing about DDD is also extremely challenging. Eric carefully weighted every single word in hs book, which is actually a careful distillation of DDD principles. My writing style is basically the opposite: I write a lot, I digress, I make a lot of (hopefully) funny examples just to make a small point. Maybe I'll be able to deliver the message, maybe not.
I am eager for feedback anyway ;-)
Tuesday, November 18, 2008
The scrum mother - re-explained
Honestly, I never thought my last post could have been that controversial. But I had so many diverging feedbacks: some loved the post, some demolished and told me it was terrible, and some others liked but got the meaning the other way round)... Maybe it is necessary to clarify things a little bit.
I am very convinced that authority stands in the middle of being a good Scrum Master. SM is not a leading role in Scrum, he/she just preserves the integrity of the process, without effectively taking part in it. SM could participate in a discussion, but must not take any decision. SM must ensure that the discussion terminates with a shared decision.
That’s why I came up with the analogy of the Italian mamma and the old-style Italian family. The father has the authority, and brings the money home (hopefully), the mother manages to keep everything running. Preparing the food does not deliver any value to the outside (unless you own a restaurant) but allows family member to be healthy and do their work.
But I guess the metaphor could have turned weak, because I was referring to a very specific type of family, and every single reader had his own idea of mother, and the concepts overlapped diverging a lot from my intentions.
How to raise kids
Probably, the flaw of the mother example is related to the different perception of the mother role within a family. I’ll explain what I meant, going straight to the SM role, to be as clear as possible. SM are not supposed to prevent developers from hurting themselves. SM are supposed to allow the team to grow, by letting them do and recognize mistakes, by allowing them to develop self-confidence and do something on their own. You must be around when your babies are learning to go on a bicycle, but if you keep holding them, or force them to use those small extra wheels ...they’ll learn later. The same applies to swimming, where confidence is just about everything. If you keep being always around, they’ll start crying the first time they’re alone. Delayed growth, lack of confidence and a lot of time spent just “being around” by the senior management.
I am very convinced that authority stands in the middle of being a good Scrum Master. SM is not a leading role in Scrum, he/she just preserves the integrity of the process, without effectively taking part in it. SM could participate in a discussion, but must not take any decision. SM must ensure that the discussion terminates with a shared decision.
That’s why I came up with the analogy of the Italian mamma and the old-style Italian family. The father has the authority, and brings the money home (hopefully), the mother manages to keep everything running. Preparing the food does not deliver any value to the outside (unless you own a restaurant) but allows family member to be healthy and do their work.
But I guess the metaphor could have turned weak, because I was referring to a very specific type of family, and every single reader had his own idea of mother, and the concepts overlapped diverging a lot from my intentions.
How to raise kids
Probably, the flaw of the mother example is related to the different perception of the mother role within a family. I’ll explain what I meant, going straight to the SM role, to be as clear as possible. SM are not supposed to prevent developers from hurting themselves. SM are supposed to allow the team to grow, by letting them do and recognize mistakes, by allowing them to develop self-confidence and do something on their own. You must be around when your babies are learning to go on a bicycle, but if you keep holding them, or force them to use those small extra wheels ...they’ll learn later. The same applies to swimming, where confidence is just about everything. If you keep being always around, they’ll start crying the first time they’re alone. Delayed growth, lack of confidence and a lot of time spent just “being around” by the senior management.
Friday, November 14, 2008
The Scrum Mother
It started out as a typo, then it became a joke, then I began thinking that there might have been something interesting behind the joke.
One of the common pitfalls, when applying Scrum is to choose the wrong person as a scrum master. It turns out that this is quite a common situation, for many reasons. A company willing to adopt Scrum will probably select some of its best people to take a Scrum Master Certification or a generic Scrum Training. Before knowing what Scrum is about and what the Scrum Master role is responsible for, in practice, the selection criteria that a company will adopt would very probably be based on the traditional system of values of the company itself. Which would not match some of the key values of Scrum itself.
Despite the word “master” a Scrum Master is not given any real “power” on the team, a SM is not supposed to decide anything. It’s a supporting role, which can be rotated among different members of the team. Choosing the project manager or the team leader as a SM simply won’t work because old habits and roles will keep on sneaking in, preventing the Scrum magic (making the team self-organize efficiently) to happen.
A different set of qualities
Software companies often evaluate their employees in terms of technical skills, problem solving or leadership attitudes. These are not really the most interesting skills for being a successful scrum master. A good scrum master governs the process but does not have an active role in technical decisions. So being the best coder in town does not make you the best candidate for being a scrum master, instead, it probably stands in the way.
Qualities needed are probably more related to a feminine approach rather than the typical testosterone-driven competitive approach of many coders. Unfortunately these qualities do not always appear in individual performance evaluations, because are more related to the overall team behavior, rather than individual.
The traditional Italian team
It turned out that in Italy there is a quite common team which is ruled by a similar set of practices. It’s called “family” and the mother - the “mamma” - plays a key role in keeping everything working.
Meetings (called lunch or dinner) happen every day at a given hour. Every member of the family is supposed to show up at least right before that.
Mamma’s efforts are generally targeted towards the meeting preparation. They prepare the food, fetch the ingredients and set up the meeting room.
Mammas are generally checking everybody’s look and mood, to ensure everything is right. If, for any reason, something is not right, there’s no way to escape a one-on-one meeting about that.
At the end of every week there is a larger lunch with members of other teams involved (generally called “relatives”). A little more of ceremony is involved, but the basic idea is to keep all the teams in sync.
Mammas are working hard, but many times they are not bringing home any money.
If fights arises between team members, mammas act as peacemakers, preserving team harmony ant any cost.
Ok, I guess the last part will sound like a lot of stereotypes... it is. In many places this type of family no longer exists. Also, this is at odds with women rights, so I need to make it clear that I am not advocating this type of family. I am merely trying to have some fun stating that some of the key scrum practices are not new at all, they’re probably patterns that existed long before. Some of this patterns can be found in the traditional Italian family and helped preserve the team in terms of unity and sense of membership for ages.
One of the common pitfalls, when applying Scrum is to choose the wrong person as a scrum master. It turns out that this is quite a common situation, for many reasons. A company willing to adopt Scrum will probably select some of its best people to take a Scrum Master Certification or a generic Scrum Training. Before knowing what Scrum is about and what the Scrum Master role is responsible for, in practice, the selection criteria that a company will adopt would very probably be based on the traditional system of values of the company itself. Which would not match some of the key values of Scrum itself.
Despite the word “master” a Scrum Master is not given any real “power” on the team, a SM is not supposed to decide anything. It’s a supporting role, which can be rotated among different members of the team. Choosing the project manager or the team leader as a SM simply won’t work because old habits and roles will keep on sneaking in, preventing the Scrum magic (making the team self-organize efficiently) to happen.
A different set of qualities
Software companies often evaluate their employees in terms of technical skills, problem solving or leadership attitudes. These are not really the most interesting skills for being a successful scrum master. A good scrum master governs the process but does not have an active role in technical decisions. So being the best coder in town does not make you the best candidate for being a scrum master, instead, it probably stands in the way.
Qualities needed are probably more related to a feminine approach rather than the typical testosterone-driven competitive approach of many coders. Unfortunately these qualities do not always appear in individual performance evaluations, because are more related to the overall team behavior, rather than individual.
The traditional Italian team
It turned out that in Italy there is a quite common team which is ruled by a similar set of practices. It’s called “family” and the mother - the “mamma” - plays a key role in keeping everything working.
Meetings (called lunch or dinner) happen every day at a given hour. Every member of the family is supposed to show up at least right before that.
Mamma’s efforts are generally targeted towards the meeting preparation. They prepare the food, fetch the ingredients and set up the meeting room.
Mammas are generally checking everybody’s look and mood, to ensure everything is right. If, for any reason, something is not right, there’s no way to escape a one-on-one meeting about that.
At the end of every week there is a larger lunch with members of other teams involved (generally called “relatives”). A little more of ceremony is involved, but the basic idea is to keep all the teams in sync.
Mammas are working hard, but many times they are not bringing home any money.
If fights arises between team members, mammas act as peacemakers, preserving team harmony ant any cost.
Ok, I guess the last part will sound like a lot of stereotypes... it is. In many places this type of family no longer exists. Also, this is at odds with women rights, so I need to make it clear that I am not advocating this type of family. I am merely trying to have some fun stating that some of the key scrum practices are not new at all, they’re probably patterns that existed long before. Some of this patterns can be found in the traditional Italian family and helped preserve the team in terms of unity and sense of membership for ages.
Tuesday, November 11, 2008
Subscribe to:
Posts (Atom)